From today on, I will publish PPK on JavaScript to this blog. PPK is one of the Web developers I admire for nothing, just because, as a JavaScript developer, he covers a range of web standards, usability, and accessibility that other developers don't care about or deliberately ignore. And, he wrote a lot of cases to test different browsers, summed up the JavaScript interface (API) compatibility, as a JavaScript developer important reference, a few years, such a study spirit is a lot of people lack.
PPK published his book This September, and I have been waiting for the book since last year. Today I got my hand and I can't wait to read the first chapter. It was full of surprises, and his skill was extraordinary. Although just a beginner, but I think I have walked on the right learning path. I think if I can share my learning experience with the people I'm learning, I can make progress together, even though I'm not sure you can get any inspiration from me, I can be sure that my notes will be more correct than the way you learn to copy and paste your code.
This book has 10 chapters, the chapters are concise and clear, respectively: purpose, background, browser, preparation, core, BOM, event, DOM, CSS change and data acquisition. No book has ever been so concise as to clarify all aspects of JavaScript, so learning won't be too much of a burden. Preface should not be too many, below starts my first chapter to study the note.
Opening Zongyi: The purpose of JavaScript is to add a special layer of usability to a Web page. It sounds simple, but the golden rule is often misunderstood. Even if you write useful JavaScript, developers may not be able to combine the right scenario: the Web Standards movement, with contemporary, barrier-free HTML pages. Even worse, some developers do not add a layer of usability to a Web page, but instead use a whole layer instead, and the result is that if the browser does not support JavaScript, the site is over.
Conceptual overview
JavaScript is a scripting language interpreted by browsers. It adds usability to the site by processing some interactions, such as form validation, on the client rather than on the server side, creating a new menu. Traditional web interaction is, the client's every move must go through the server to come back, the long wait will let users crash. JavaScript can improve the user experience by doing something (most obviously, form validation) on the client side instead of the server.
With the development of the times, JavaScript can handle more and more interactions. Problem arises, JavaScript can do so many things, whether to use more or less? There is a showdown between rich and thin. is the entire page using JavaScript to control interaction or just a little bit of javascript to increase usability? That is to say, use JavaScript as much as you can, or even sparingly.
Thin clients rely heavily on client-server communication, while rich clients limit additional data traffic to the extent possible.
Which Way is better? Although rich clients offer some usability benefits, thin clients may be a more "standard" javascript usage. The web is considered a collection of documents, not a collection of interfaces. The most obvious evidence is that browsers have the ability to move backwards so that you can jump to the interface in your document. The browser can collect (bookmark) The document and the interface is OK? Thin clients are also less prone to errors from a barrier-free perspective.
This imbalance is difficult to solve. Rich clients of course can also be in a more advanced interface to do forward back, or collection, can also achieve the perfect barrier-free. This has to require a lot of extra work, but not every project has a time or money that is beyond budget. In addition, being too focused on usability and ignoring accessibility is also a problem.
So is the purpose of JavaScript for rich clients or thin client services? The answer is: look at the situation. Depends on your site, your audience, your JavaScript level.
Technical Overview
JavaScript is divided into six areas, namely core, browser object model (BOM), event (events), Document Object Model (DOM), CSS change, and data Acquisition (XMLHttpRequest).
In ancient times, when Netscape was in the lead, NetScape3 was the standard of fact.
Contemporary is not so simple. ECMA standardized JavaScript Core, the standard DOM of the consortium, and the BOM is still in WHAT-WG standardization, the consortium has just had the first draft of XMLHttpRequest. Today, the BOM still adheres to the NetScape3 de facto standards, while XMLHttpRequest complies with Microsoft's original specifications.
The purpose of JavaScript is to increase usability for a Web site, not to break the user's privacy and security. JavaScript is therefore not allowed to read and write to the user's files (except cookies), taking a homology policy that allows only interactions from the same domain. Read history is not allowed, can not set values for the form of uploaded files, windows that are controlled by JavaScript need to be confirmed by the user, windows that are open by JavaScript cannot be less than 100x100 windows, and cannot be moved out of the screen.
The history of JavaScript
The search for history will let us know why JavaScript has been misunderstood so deeply. The creator of JavaScript is Brendan Eich, first implemented in Netscape 2. The goal is to create a simple enough language to make it easy for developers to interact with the web, just copy the code and tweak it. It's really amazing that a lot of JavaScript developers start with copy-pasting.
Unfortunately, JavaScript was born with the wrong name and the wrong grammar. Originally it was called LiveScript, but 1996 years when Java hot, Netscape wanted to hitch a ride, so a product manager (I want to know who she/he is, hehe), command renaming, command Brendan Eich let "JavaScript like java." This makes many people think that JavaScript is a low-level version of Java, can not cause serious programmers attention.
At 1996 years, NetScape 3 was king, and Microsoft could only copy it. This is a rare harmony period, of course, when the browser than now to "thin", limited to form verification, mouse rotation of some small tricks just.
The next is the far-reaching browser wars. In order to compete for the market, two of browsers have achieved different things, who want to become the fact standard. The most famous is Netscape 4 's document.layer and IE 4 's document.all (Forget them!) ）。 They make DHTML popular.
1999 Microsoft to launch a good support for CSS and Dom IE5 won, Netscape's way to finally have enough time to make a revolution, that is, CSS. Wasp started with CSS, and many experts discovered/invented many browser remedies to make this revolution possible.
In the 2003, some pioneers began to explore new JavaScript styles under the influence of the CSS revolution, focusing more on accessibility and the bad reputation of the people, that is, unobstrusive--JavaScript from the HTML structure layer, unfortunately, Programmers who survived the browser wars may not have discovered the new path.
In the 2005, the Ajax boom injected new blood into the JavaScript community. But in some ways, Ajax is too much like DHTML, no obstacle, is a lot of AJAX applications are the unspoken. This craze tends to focus on technology (how Ajax), while usability and interactivity (why Ajax) are underestimated. Finally, a variety of swollen libraries (now called frames) developed rapidly.
Ajax is still running at full speed, but it will be like a DHTML result, people are losing interest, they will fall apart.
JavaScript fall seems to have a certain "law" to dominate, can we break this cycle? In any case, JavaScript developers, looking for cool code and flashy frameworks, should adjust their actions to allow JavaScript to run on standard-compliant, barrier-free web pages.
