TC39, ECMA-262, ECMAScript

Do you ever have a situation where you can find the latest specifications for a particular technology or language? Are these specifications supported? To what extent? It’s completely clueless.

For JavaScript, the ES6 specification has brought many new features since its release, and the ES specification is constantly tweaking and adding content as we digest this vast amount of knowledge. However, we don’t have a specific process and channel to access the latest information, which in turn will fall further and further behind the cutting-edge technology.

So, here is a summary of JavaScript knowledge:

  • TC39, ECMA-262, ECMAScript

    • What is the relationship between ECMA, TC39, ECMA-262, ISO/IEC 16262, ECMAScript and JavaScript?
    • What is the history (timeline) of the ECMAScript version?

    • What is the new process of TC39 specification?

      • Tip: Consider individual features and phases, not ECMAScript versions
    • Why is the ES7 (ES2016) edition so small?
    • Where can you go to view the process of TC39 standard commonly?
    • How do we apply these new features in our programs?
    • Backward compatibility principle

    • The ES standard differs from the browser implementation

      • The new API is an extension of the existing object
      • The new syntax, like let, is an extension of functionality.
    • Where to check the compatibility of ECMAScript features in the runtime environment?
    • What is Babel?
    • How to use the latest features with TC39 and Babel?
    • recommended
  • Reference:

  • Social information/Social Links:

    • 1, Welcome to pay attention to our work.

<! — /TOC –>

As usual, let’s introduce the knowledge to you through questions and answers.

What is the relationship between ECMA, TC39, ECMA-262, ISO/IEC 16262, ECMAScript and JavaScript?

ECMA: ECMA International (formerly known as ECMA – European Computer Manufacturers Association – European Computer Manufacturers Association) is an industry standards organization. The standards it passes are all numbered like ECMA-NNN.

TC39: ECMA International Organization Technical Committee No. 39, it is a Committee to promote the development of JavaScript. It is part of ECMA, the body that standardizes the JavaScript language under the “ECMAScript” specification.

TC39 is made up of representatives from major browser manufacturers, although some of China’s largest technology companies, such as Alibaba and Byte, have already joined the TC39. Their main job is to develop the ECMAScript standard, the standard generation process, and implement it.

Every two months, TC39 holds meetings attended by its members’ appointed representatives and invited experts. The minutes of these meetings are in
Making the repositoryIn the public.

In addition to TC39, ECMA International also has many other technical committees, such as TC43 Universal 3D (U3D), TC45 Office Open XML Formats and so on. For details, please refer to ECMA Template for minutes — ECMA International

ECMA-262 is a standard specified by ECMA. The ECMA-262 standard is a standard specified by ECMA. The ECMA-262 standard is an ECMA standard.

Then there is the standardization of JavaScript languages :(ECMA-262 and ISO/IEC 16262 are involved)

There were originally two standards for the JavaScript language:

  • ECMA – 262: ECMAScript is the master standard, managed by ECMA International (ECMAScript was created so that the original JavaScript and the original JScript could evolve according to the same set of standards). The ECMA-262 number was obtained because it was in line with the ECMA standard 262.
  • ISO/IEC 16262: Is the second standard, by the International Organization for Standardization (ISO, International Organization for Standardization) and the International Electronic Technology Committee (IEC, International Electrotechnical Commission

The specification calls the language ECMAScript for trademark and copyright reasons, so in principle JavaScript and ECMAScript refer to the same thing, but sometimes they are distinguished:

  • JavaScript: Refers to the language and its implementation
  • ECMAScript: Refers to language standards and language versions, such as ES6 presentation language (standard) version 6

What is the history (timeline) of the ECMAScript version?

Here’s a brief timeline of ECMAScript release development:

  • ECMAScript 1 (June 1997) : The first release of the standard
  • ECMAScript 2 (June 1998) : A minor update to bring ECMA-262 in sync with the ISO standard
  • ECMAScript 3 (December 1999) : Added regular expressions, string handling, control statements (do-while, switch), try-catch handling, and many other core features
  • ECMAScript 4 (repealed in July 2008) : It was supposed to be a major upgrade (static types, modules, namespaces, etc.), but it got too far, splits, and didn’t make it to the market
  • ECMAScript 5 (December 2009) : Some minor improvements, including some library features and strict schemas
  • ECMAScript 5.1 (June 2011) : A minor update to bring ECMA and ISO standards in sync
  • ECMAScript 6 (June 2015) : A major update that implements many of the assumptions of ECMAScript 4. From this version, name the specification version by year – ECMAScript 2015
  • ECMAScript 2016 (June 2016) : The first annual release, with a shorter release cycle and fewer new features compared to ES6

  • ECMAScript 2017 (June 2017) : Second annual release

    Subsequent versions of ECMAScript (ES2018, etc.) are always approved in June.

As an aside, the specifications that haven’t been released yet, i.e. the features that are still in the customization stage, are called ESNext.

What is the new process of TC39 specification?

Yi… , why do you use the process? Was there any other process before?

Yes, it used to be, but there were two things that weren’t so good about the previous process, so it was scrapped.

What’s the problem? Let’s take a look:

Knowing the release timeline above, we know that after ES3 came out, it took them 10 years with almost no changes to get it up to specification. After that, ES6 took another four years to come to fruition. There are two problems with a long release cycle:

  1. The time span between releases is too long, and features finalized early have to wait a very long time for the specification to be officially released, while features finalized late in the release cycle tend to be finalized well before the release deadline, which can be risky
  2. The gap between the design and implementation and use of language features is so long that it is too late to discover the design defects in the implementation and use stages

In response to these problems, TC39 has developed a new TC39 process (The TC39 Process) :

  • ECMAScript functionality is designed independently and goes through phases starting at 0 (” scarecrow “) and ending at 4 (” done “).
  • In particular, the late stages require prototyping and actual testing so that there is a feedback loop between design and implementation.
  • The ECMAScript version is released annually and includes all functionality that reached phase 4 by the release deadline.

Using the new TC39 process, each release is a smaller incremental release, and the functionality is field-tested.

The specific TC39 flow chart is as follows:

Each ECMAScript feature proposal goes through numbered stages from 0 to 4.Test 262Is a set of tests that check if the JavaScript engine conforms to the language specification.

  • Stage0 Strawman: This is the stage where any discussions, ideas, changes, or features that have not been added to the proposal. Only TC39 members can submit.

  • stage1 proposal:

    • (1) To produce a formal proposal.
    • (2) Discover potential problems, such as relationships with other features, implementation challenges.
    • (3) The proposal includes a detailed description of the API, usage examples, and relevant semantics and algorithms.

  • stage2 draft:

    • (1) Provide an initial draft specification that is not significantly different from the features contained in the final standard. After the draft, only incremental changes are accepted in principle.
    • (2) Start experimenting with how to implement it, either in the form of polyfill, an implementation engine (which provides local support for draft execution), or a compiled transformation (e.g. Babel).

  • stage3 candidate:

    • (1) In the candidate stage, specific implementation and user feedback were obtained. Thereafter, changes are made only if significant problems arise during implementation and use.
    • (2) The specification document must be complete and signed off by reviewers and ECMAScript editors.
    • (3) It should be implemented in at least one browser, with polyfill or Babel plugins.

  • stage4 finished:

    • (1) This feature is ready for the next version of the ECMAScript specification.
    • (2) It is necessary to have two independent implementations and pass acceptance tests in order to gain important practical experience in the use process.

The new process uses a superset of HTML to format proposals and a pattern of GitHub pull Requests to increase community engagement

Since ES2016 (since the implementation of the new TC39 process), the concept of the ES version has been greatly weakened. What matters is where the feature proposal is at, as long as it gets to phase 4, it is considered a standard feature

Tip: Consider individual features and phases, not ECMAScript versions

Up until and including ES6, it was most common to think about JavaScript in terms of the ECMAScript version — for example, “Does this browser support ES6?”

Starting with ES2016(that is, ES7), it’s about thinking about a single feature: Once a feature reaches Phase 4, you can safely use it (if the JavaScript engine you’re targeting supports it). You don’t have to wait for the next ECMAScript release.

Why is the ES7 (ES2016) edition so small?

Feature proposals can be made at any time, multi-line parallel review is advanced, but the release cycle is fixed:

  • February 1: Candidate Draft for output
  • February-March: Royalty-free opt-out period of 60 days
  • March TC39: incorporate Stage 4 (vetted) proposals, calibrate final semantics, and move out of the new specification version from the main branch, then accept only editorial changes
  • April – June: ECMA CC and ECMA GA review period
  • July: New standards are approved by ECMA General Assembly

The July release brings new reviewed feature proposals up, so the number of new features included in a release depends on how many features were reviewed that year

On the one hand, it can ensure that the features released by the specification have been widely reviewed and confirmed. On the other hand, it can maintain the frequent rhythm of one edition per year, so as to avoid the occurrence of large versions like ES2015 (one edition in 6 years).

Where can you go to view the process of TC39 standard commonly?

  • Abandoned proposals: https://github.com/tc39/propo…
  • stage0: https://github.com/tc39/propo…
  • Stage1 ~ 3: https://github.com/tc39/propo…
  • Stage4 and included into the draft: https://github.com/tc39/propo…

In addition,
TC39It has a lot of warehouses, one of which
ecma262The repository mainly maintains ECMAScript specification documents

How do we apply these new features in our programs?

Babel Plugins:

  • babel-presets-stage-0
  • babel-presets-stage-1
  • babel-presets-stage-2
  • babel-presets-stage-3
  • babel-presets-stage-4

Backward compatibility principle

We found that each version of the ES specification was fully compatible with all of the previous features. For example, ES6 introduced let and const but did not eliminate var because of the problems that would occur if a new version of the ES specification was released that was not compatible:

  1. JavaScript engines, IDEs, and build tools all become bloated as they support both the old and new versions of the specification
  2. Developers need to be aware and constantly aware of the differences between versions
  3. Refactoring can become cumbersome if you either migrate all existing code to a new version, or mix multiple versions (on different projects)
  4. Even marking the version that each piece of code belonged to, as ES5 did by hand in strict mode, was not popular at the time because it was cumbersome to add instructions at the beginning of files or functions

To avoid these problems, ES6 uses a strategy called One JavaScript:

  1. New versions are always fully backward compatible (but occasionally there may be slight, unobvious cleanups)
  2. Old features are not removed or fixed, but better versions are introduced, such as let, which is an improved version of var
  3. If some aspect of the language is changed, it only takes effect within the new syntax structure, which is implicit selection. For example, yield only in the generator is the default for all code in keywords, modules, and classes to turn on strict mode

The ES standard differs from the browser implementation

The rapid evolution of features has also created problems for JavaScript developers. The new features allow for more efficient and robust code to be written, but our site runs on older browsers that do not support these new features. The problem is even more acute in the context of rapidly evolving features.

Here’s an example:

The differences between ECMAScript features and browser-supported features are shown in green in the figure above. The differences can be broken down into two main parts: the new API and the new syntax.

The new API is an extension of the existing object

For example, Array. Includes is an extension of Array objects. It is usually a solution to some legacy problem or a encapsulation of common code logic.

For example, Object.is() is a new interface that checks whether two values are exactly equal. === = There is a subtle ambiguity when dealing with values such as NaN and -0, and Object.is() is used to solve this problem.

NaN === NaN; // false
Object.is(NaN, NaN) // true

There is often a pattern called polyfill or shim to smooth out the differences between specification features and browser features introduced by API extensions. These two words mean putty and gasket respectively, from the meaning of the word can describe their function very vividly.

Polyfill can implement these new APIs using ES5 code, such as Object.is() with the following code:

if (! Object.is) { Object.is = function(x, y) { // SameValue algorithm if (x === y) { // Steps 1-5, 7-10 // Steps 6.b-6.e: + 0! = -0 return x ! == 0 || 1 / x === 1 / y; } else { // Step 6.a: NaN == NaN return x ! == x && y ! == y; }}; }

The new syntax, like let, is an extension of functionality.

To use unsupported syntax in older browsers, you must use a “transform + compile” technique, using specialized tools to convert the code into equivalent (or approximate) code that will work in an ES5 environment.

Where to check the compatibility of ECMAScript features in the runtime environment?

There is a website dedicated to viewing compatibility tables. Includes browser, mobile and server side.

A brief introduction is the compatibility of a feature [2] in a certain version [1] with a certain compiler or browser [3].

What is Babel?

Babel is a JavaScript compiler designed to compile ECMAScript 6+ code for browser or runtime compatibility. It can transform syntax and supplement APIs. reference

How to use the latest features with TC39 and Babel?

What should you do if you find a new JS syntax in someone else’s code or on the Internet?

First you should try to find the formal name of the syntax through a search engine.

Then you can go to TC39’s GitHub, you can find it in the ECMA-262 official document (but it’s too long) or in the RFPs, Don’t omit the Finished Proposals and Inactive Proposals lists, and eventually you will find an introduction to this syntax and use cases.

Then you’ll want to see how well this syntax is supported in different environments, so you’ll need to go to the compatibility table query page to look for this syntax.

Then you may want to try to write a use case and run it, but you’ll need to check the plugins list on Babel’s website to see if the syntax is supported, or the core-js list if it’s a new API.

Then you can configure Babel and write use cases, compile them into browser-compatible code, and run them in the browser.

recommended

The JavaScript Chinese Interest Group is dedicated to providing a platform to enhance the participation of the Chinese JavaScript community in the work of the JavaScript Language Standard (ECMAScript)

The JSCIG is mainly focused on identifying the needs of Chinese JavaScript developers, helping Chinese members of ECMA familiarize themselves with the TC39 standard process, discussing possible proposals to be submitted to TC39, testing of the standard, implementation of the standard, and standardization opportunities related to JavaScript. At the same time, I will assist the Chinese JavaScript community to participate in and contribute to the development of the JavaScript language.

Reference:

  • History and evolution of JavaScript
  • The TC39 Process
  • Intensive reading of TC39, ECMAScript, and the Future of JavaScript
  • 2019 JavaScript features study guide | Denver annual essay
  • D2 Front-End Technology Forum: Revealing TC39: ES2020 and ES2021
  • The Real Story Behind ECMAScript 4
  • A list of syntax plug-ins supported by Babel
  • A list of APIs supported in Babel Polyfill
  • Online learning JS website author pretty cow
  • ES News Feed