Analysis of the purpose of JavaScript_Basic knowledge

From today on, I will continue to post my ppk on JavaScript reading experience to this blog. ppk is a web developer that I admire, for no other reason than that as a JavaScript developer, he covers areas such as web standards, usability, accessibility, etc., which other developers do not pay attention to or Deliberately ignored. Moreover, he wrote many cases to test different browsers and summarized the compatibility of JavaScript interfaces (APIs), which became an important reference for JavaScript developers. For several years, this kind of research spirit is lacking in many people.
ppk published his book in September this year, the book I have been waiting for since last year. I got it today and couldn’t wait to read the first chapter. It is indeed full of surprises, his skills are extraordinary. Although I am just a beginner, I think I am already on the right learning path. I think if I can share my learning experience, people who are studying can see it and we can communicate and make progress together. Although I can’t guarantee that you can get any inspiration from me, I can be sure that these notes of mine will be better than Your copy and paste code learning method is more correct.

This book has ten chapters, and the chapter names are concise and clear, namely: purpose, background, browser, preparation, core, BOM, events, DOM, CSS changes and data acquisition. There has never been a book that clarified all aspects of JavaScript so concisely, so learning will not be too burdensome. There shouldn’t be too much preface, so let’s start with my study notes for the first chapter.

Opening Principle: The purpose of JavaScript is to add a special layer of usability to web pages. Sounds simple, but this golden rule is often misunderstood. Even if they write useful JavaScript, developers may still fail to contextualize it appropriately: the development of the Web standards movement and the modern accessibility of HTML pages. What's even worse is that instead of adding a layer of usability to the web page, some developers replace it with an entire layer. The consequence is that if the browser does not support JavaScript, the website is ruined.

Concept Overview
JavaScript is a scripting language interpreted by the browser. It adds usability to the website by handling certain interactions, such as form validation and creating new menus, on the client side instead of the server side. In traditional web page interaction, every move made by the client must be fed back through the server. The long wait will cause the user to crash. JavaScript can do certain things on the client side instead of the server side (most obviously, form validation), thus improving the user experience.

With the development of the times, JavaScript can handle more and more interactions. The question arises, JavaScript can do so many things, should it be used more or less? This is the showdown between rich and thin. Should the entire page use JavaScript to control interactivity or just add some JavaScript to enhance usability? That is, use JavaScript as much as possible or sparingly or even not using it?

Thin clients rely heavily on client-server communication, while rich clients limit additional data communication as much as possible.

Which way is better? While rich clients bring some usability benefits, thin clients are probably the more "standard" usage of JavaScript. The Web is considered a collection of documents, not a collection of interfaces. The most obvious evidence is that the browser has a back and forward function that allows you to jump in the document and the interface will be there? Can the browser bookmark (bookmark) documents but the interface can? In terms of accessibility, thin clients are also less error-prone.

This kind of imbalance is difficult to solve. Of course, the rich client can also move forward, backward, or collect in a more advanced interface, and can also achieve perfect accessibility. This must require a lot of extra work, but not every project has the time or money to go over budget. Additionally, focusing too much on usability and neglecting accessibility is a problem.

So is JavaScript designed to serve rich clients or thin clients? The answer is: it depends. It depends on your website, your audience, and your JavaScript level.

Technical Overview
JavaScript is divided into six aspects, namely Core, Browser Object Model (BOM), Events, Document Object Model (DOM), CSS changes and data acquisition (XMLHttpRequest).

In ancient times, when NetScape took the lead, NetScape3 was the de facto standard.

Contemporary times are not so simple. ECMA standardizes JavaScript Core, W3C standardizes DOM, and BOM is still in the process of standardization by WHAT-WG, and W3C has just released the first draft of XMLHttpRequest. Today, BOM still follows the de facto standard of NetScape3, and XMLHttpRequest still follows Microsoft's original specification.

The purpose of JavaScript is to increase the usability of the website, not to undermine the privacy and security of the user. Therefore, JavaScript does not allow reading or writing the user's files (except cookies), adopts the same-origin policy, and only allows interactions from the same domain. Reading of history is not allowed, values ​​cannot be set for the form for uploading files, closing of windows controlled by JavaScript requires user confirmation, windows opened by JavaScript cannot be smaller than a 100×100 window, and cannot be moved off the screen.

History of JavaScript
Exploring history can help us understand why JavaScript is so misunderstood.JavaScript was created by Brendan Eich and was first implemented in NetScape 2. Its purpose is to create a language that is simple enough so that developers can easily add interactivity to web pages by simply copying the code and adjusting it. This is really impressive, as many JavaScript developers start by copying and pasting.

Unfortunately, JavaScript has the wrong name and wrong syntax. Originally it was called LiveScript, but in 1996, Java was hot, and NetScape wanted to ride on it, so a certain product manager (I wonder who she/he was, haha), ordered the name to be changed, and ordered Brendan Eich to make "Javascript like Java". This makes many people mistakenly believe that JavaScript is a low-level version of Java and cannot attract the attention of serious programmers.

In 1996, NetScape 3 was king and Microsoft could only copy it. This was a rare period of harmony. Of course, browsers at that time were "thinner" than they are now, limited to form validation and some small tricks like mouse rotation.

The next step is the far-reaching browser war. In order to compete for the market, the two browsers have implemented different things, and each wants to become the de facto standard. The most famous ones are NetScape 4's document.layer and IE 4's document.all (forget them!). They made DHTML popular.

In 1999, Microsoft won with the launch of IE5 that had good support for CSS and DOM. NetScape gave way and finally had enough time for a revolution to happen, that is CSS. WaSP started with CSS, and many experts discovered/invented many browser workarounds to make this revolution possible.

In 2003, some pioneers began to explore new JavaScript styles under the influence of the CSS revolution, paying more attention to accessibility and changing people's bad reputation, that is, unobstrusive - changing JavaScript from HTML structure Layers are separated. Unfortunately, those programmers who survived the browser wars may not have discovered this new path.

In 2005, the Ajax craze injected new blood into the JavaScript community. But in some aspects, Ajax is too much like DHTML. Accessibility is an unspeakable secret of many Ajax applications. The craze tends to focus on technology (how to Ajax), while usability and interactivity (why Ajax) are undervalued. Eventually, various bloated libraries (now called frameworks) quickly evolved.

Ajax is still moving full steam ahead, but this will end up like DHTML, people will gradually lose interest and they will fall apart.

The rise and fall of JavaScript seems to be governed by a certain "law". Can we break this vicious circle? No matter what, JavaScript developers, in addition to looking for all kinds of cool code and flashy frameworks, should adjust their actions to let JavaScript run in: standards-compliant and barrier-free web pages.​