5 History and evolution of JavaScript

5.1 How JavaScript was created

JavaScript was created in May 1995 in 10 days, by Brendan Eich. Eich worked at Netscape and implemented JavaScript for their web browser, Netscape Navigator.

The idea was that major interactive parts of the client-side web were to be implemented in Java. JavaScript was supposed to be a glue language for those parts and to also make HTML slightly more interactive. Given its role of assisting Java, JavaScript had to look like Java. That ruled out existing solutions such as Perl, Python, TCL, and others.

Initially, JavaScript’s name changed several times:

• Its code name was Mocha.
• In the Netscape Navigator 2.0 betas (September 1995), it was called LiveScript.
• In Netscape Navigator 2.0 beta 3 (December 1995), it got its final name, JavaScript.

5.2 Standardization: JavaScript vs. ECMAScript

There are two standards for JavaScript:

• ECMA-262 is hosted by Ecma International. It is the primary standard.
• ISO/IEC 16262 is hosted by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). This is a secondary standard.

The language described by these standards is called ECMAScript, not JavaScript. A different name was chosen because Sun (now Oracle) had a trademark for the latter name. The “ECMA” in “ECMAScript” comes from the organization that hosts the primary standard.

The original name of that organization was ECMA, an acronym for European Computer Manufacturers Association. It was later changed to Ecma International (with “Ecma” being a proper name, not an acronym) because the organization’s activities had expanded beyond Europe. The initial all-caps acronym explains the spelling of ECMAScript.

Often, JavaScript and ECMAScript mean the same thing. Sometimes the following distinction is made:

• The term JavaScript refers to the language and its implementations.
• The term ECMAScript refers to the language standard and language versions.

Therefore, ECMAScript 6 is a version of the language (its 6th edition).

5.3 Timeline of ECMAScript versions

This is a brief timeline of ECMAScript versions:

• ECMAScript 1 (June 1997): First version of the standard.
• ECMAScript 2 (June 1998): Small update to keep ECMA-262 in sync with the ISO standard.
• ECMAScript 3 (December 1999): Adds many core features – “[…] regular expressions, better string handling, new control statements [do-while, switch], try/catch exception handling, […]”
• ECMAScript 4 (abandoned in July 2008): Would have been a massive upgrade (with static typing, modules, namespaces, and more), but ended up being too ambitious and dividing the language’s stewards.
• ECMAScript 5 (December 2009): Brought minor improvements – a few standard library features and strict mode.
• ECMAScript 5.1 (June 2011): Another small update to keep Ecma and ISO standards in sync.
• ECMAScript 6 (June 2015): A large update that fulfilled many of the promises of ECMAScript 4. This version is the first one whose official name – ECMAScript 2015 – is based on the year of publication.
• ECMAScript 2016 (June 2016): First yearly release. The shorter release life cycle resulted in fewer new features compared to the large ES6.
• ECMAScript 2017 (June 2017). Second yearly release.
• Subsequent ECMAScript versions (ES2018, etc.) are always ratified in June.

5.4 Evolving JavaScript: TC39 (Ecma Technical Committee 39)

TC39 is the committee that evolves JavaScript. Its members are, strictly speaking, companies: Adobe, Apple, Facebook, Google, Microsoft, Mozilla, Opera, Twitter, and others. That is, companies that are usually competitors are working together on JavaScript.

Every two months, TC39 has meetings that member-appointed delegates and invited experts attend. The minutes of those meetings are public in a GitHub repository.

Outside of meetings, TC39 also collaborates with various members and groups of the JavaScript community.

5.5 The TC39 process for proposed ECMAScript features

With ECMAScript 6, two issues with the release process used at that time became obvious:

• If too much time passes between releases then features that are ready early, have to wait a long time until they can be released. And features that are ready late, risk being rushed to make the deadline.

• Features were often designed long before they were implemented and used. Design deficiencies related to implementation and use were therefore discovered too late.

In response to these issues, TC39 instituted the new TC39 process:

• ECMAScript features are designed independently and go through six stages: a strawperson stage 0 and five “maturity” stages (1, 2, 2.7, 3, 4).
• Especially the later stages require prototype implementations and real-world testing, leading to feedback loops between designs and implementations.
• ECMAScript versions are released once per year and include all features that have reached stage 4 prior to a release deadline.

The result: smaller, incremental releases, whose features have already been field-tested.

ES2016 was the first ECMAScript version that was designed according to the TC39 process.

5.5.1 Tip: Think in individual features and stages, not ECMAScript versions

Up to and including ES6, it was most common to think about JavaScript in terms of ECMAScript versions – for example, “Does this browser support ES6 yet?”

Starting with ES2016, it’s better to think in individual features: once a feature reaches stage 4, we can safely use it (if it’s supported by the JavaScript engines we are targeting). We don’t have to wait until the next ECMAScript release.

5.5.2 The details of the TC39 process (advanced)

ECMAScript features are designed via proposals that go through the so-called TC39 process. That process comprises six stages:

• Stage 0 means a proposal has yet to enter the actual process. This is where most proposals start.

• Then the proposal goes through the five maturity stages 1, 2, 2.7, 3 and 4. If it reaches stage 4, it is complete and ready for inclusion in the ECMAScript standard.

5.5.2.1 Artifacts associated with an ECMAScript proposal

The following artifacts are associated with an ECMAScript proposal:

• Proposal document: Describes the proposal to JavaScript programmers, with English prose and code examples. Usually the readme of a GitHub repository.

• Specification: Written in Ecmarkup, an HTML and Markdown dialect that is supported by a toolchain. That toolchain checks Ecmarkup and renders it to HTML with features tailored to reading specifications (cross-references, highlighting of variable occurrences, etc.).

  • The HTML can also be printed to a PDF.
  • If a proposal makes it to stage 4, its specification is integrated into the full ECMAScript specification (which is also written in Ecmarkup).

• Tests: Written in JavaScript that check if an implementation conforms to the specification.

  • If a proposal makes it to stage 4, its tests are integrated into Test262, the official ECMAScript conformance test suite.

• Implementations: The functionality of the proposal, implemented in engines and transpilers (such as Babel and TypeScript).

Each stage has entrance criteria regarding the state of the artifacts:

5.5.2.2 Roles of the people that manage a proposal

• Author: A proposal is written by one or more authors.
• Champion: Each proposal has one or more TC39 delegates that guide the proposal through the TC39 process. This is especially important if an author has no experience with the process.
• Reviewer: Reviewers give feedback for the specification during stage 2 and must sign off on it before the proposal can reach stage 2.7. They are appointed by TC39 (excluding the authors and champions of the proposal).
• Editor: Someone in charge of managing the ECMAScript specification. The current editors are listed at the beginning of the ECMAScript specification.

5.5.2.3 The stages of a proposal

• Stage 0: ideation and exploration

  • Not part of the usual advancement process. Any author can create a draft proposal and assign it stage 0.

• Stage 1: designing a solution

  • Entrance criteria:
    • Pick champions
    • Repository with proposal
  • Status:
    • Proposal is under consideration.

• Stage 2: refining the solution

  • Entrance criteria:
    • Proposal is complete.
    • Draft of specification.
  • Status:
    • Proposal is likely (but not guaranteed) to be standardized.

• Stage 2.7: testing and validation

  • Entrance criteria:
    • Specification is complete and approved by reviewers and editors.
  • Status:
    • The specification is finished. It’s time to validate it through tests and spec-compliant prototypes.
    • No more changes, aside from issues discovered through validation.

• Stage 3: gaining implementation experience

  • Entrance criteria:
    • Tests are finished.
  • Status:
    • The proposal is ready to be implemented.
    • No changes except if web incompatibilities are discovered.

• Stage 4: integration into draft specification and eventual inclusion in standard

  • Entrance criteria:
    • Two implementation that pass the tests
    • Significant in-the-field experience with shipping implementations
    • Pull request for TC39 repository, approved by editors
  • Status:
    • Proposed feature is complete:
      • Its specification is ready to be included in the ECMAScript specification.
      • Its tests are ready to be included in the ECMAScript conformance test suite Test262.

Figure 5.1 illustrates the TC39 process.

Sources of this section:

• “The TC39 Process” (official document by TC39)
• The TC39 GitHub repository how-we-work, especially the document that explains the work of a proposal champion.
• The colophon of the ECMAScript specification. A colophon is content at the end of a book. It usually contains information about the book’s production.

5.6 How to not break the web while changing JavaScript

One idea that occasionally comes up is to clean up JavaScript by removing old features and quirks. While the appeal of that idea is obvious, it has significant downsides.

Let’s assume we create a new version of JavaScript that is not backward compatible and fixes all of its flaws. As a result, we’d encounter the following problems:

• JavaScript engines become bloated: they need to support both the old and the new version. The same is true for tools such as IDEs and build tools.
• Programmers need to know, and be continually conscious of, the differences between the versions.
• We can either migrate all of an existing code base to the new version (which can be a lot of work). Or we can mix versions and refactoring becomes harder because we can’t move code between versions without changing it.
• We somehow have to specify per piece of code – be it a file or code embedded in a web page – what version it is written in. Every conceivable solution has pros and cons. For example, strict mode is a slightly cleaner version of ES5. One of the reasons why it wasn’t as popular as it should have been: it was a hassle to opt in via a directive at the beginning of a file or a function.

So what is the solution? This is how JavaScript is evolved:

• New versions are always completely backward compatible (but there may occasionally be minor, hardly noticeable clean-ups).

• Old features aren’t removed or fixed. Instead, better versions of them are introduced. One example is declaring variables via let – which is an improved version of var.

• If aspects of the language are changed, it is done inside new syntactic constructs. That is, we opt in implicitly – for example:

  • yield is only a keyword inside generators (which were introduced in ES6).
  • All code inside modules and classes (both introduced in ES6) is implicitly in strict mode.

5.7 FAQ: ECMAScript and TC39

5.7.1 Where can I look up which features were added in a given ECMAScript version?

There are several places where you can look up what’s new in each ECMAScript version:

• In this book, there is a chapter that lists what’s new in each ECMAScript version. It also links to explanations.

• The TC39 repository has a table with finished proposals that states in which ECMAScript versions they were (or will be) introduced.

• Section “Introduction” of the ECMAScript language specification lists the new features of each ECMAScript version.

• The ECMA-262 repository has a page with releases.

5.7.2 How is [my favorite proposed JavaScript feature] doing?

If you are wondering what stages various proposed features are in, consult the GitHub repository proposals.

5.7.3 Why does stage 2.7 have such a peculiar number?

Stage 2.7 was added in late 2023, after stages 0, 1, 2, 3, 4 had already been in use for years.

• Q: Why not renumber the stages?
  • A: Renumbering was not in the cards because it would have made old documents difficult to read.
• Q: Why not another number such as 2.5?
  • The .7 reflects that stage 2.7 is closer to stage 3 than to stage 2.
• Q: How about 3a for the new stage and 3b for the old stage 3?
  • A: If you read “stage 3” in an old document, it can be confusing as to whether this refers to the new stage 3a or the new stage 3b.

Source: TC39 discussion on 2023-11-30