Many people get confused what is JavaScript and what is ECMAScript. It is sometimes difficult to tell how they are related to each other and what role ECMA International and TC39 play in standardizing JavaScript.

In this blog post, I am going to discuss TC39 and its contribution to ECMAScript.

Let’s start with all the basic terminology used when talking about JavaScript and ECMAScript.

What is ECMAScript?

ECMAScript is a standard script language, developed in collaboration with Netscape and Microsoft and derived primarily from Netscape’s JavaScript. JavaScript is a widely used scripting language used in web pages to influence how they look or behave to the user.

ECMA-262 is a standard published by ECMA International. It contains specifications for a general purpose scripting language known as ECMAScript.

A little more about JavaScript
JavaScript is a scripting language that enables you to create dynamically updating content, control multimedia, animate images, and pretty much everything else. (Okay, not everything, but it’s amazing what you can achieve with just a few lines of JavaScript code.)

What is ECMA?

ECMA is a standards organization for information and communication systems. The objective of ECMA is to develop standards and technical reports to facilitate and standardize the use of information communication technology and consumer electronics.

It encourages the correct use of standards by influencing the environment in which they apply, and it publishes these standards and reports in electronic and printed form.

And now, let’s introduce the hardworking people behind ECMAScript: TC39.

What is TC 39?

TC39 stands for Technical Committee No. 39. It is part of ECMA, the organization that standardizes the JavaScript language under the “ECMAScript” specification.

It works on standardization of general purpose, cross platform, vendor-neutral programming language i.e. ECMAScript. It includes language syntax, semantics, libraries, and complementary technologies supporting the language.

Since ES6 came out, TC 39 has streamlined the proposal prediction process to meet modern expectations. The new process uses a superset of HTML to format proposals.

They use GitHub pull requests, which helped increase participation from the community. The number of proposals is also increasing.

The specification is now a higher than life standard, which means proposals are rapidly adopted, and we don’t wait years for a new version of the specification to come out.

a more general view

By reading the ECMAScript specification, you learn how to build a scripting language. By reading JavaScript documentation, you learn to use that scripting language.

Stage 0: Strawman
Any discussion, idea, change, or addition that has not yet been presented as a formal proposal is considered a “Strowman” motion at this stage. Only members of TC39 can make these proposals, and today there are over a dozen active Strawman proposals.

Step 1: Proposal
At this stage, a proposal is formalized and is expected to address cross-cutting concerns, negotiation with other proposals, and implementation concerns. Proposals in this step identify a discrete problem and offer a concrete solution to that problem.

At this stage, the proposal often includes a high-level API description, examples of usage, and a discussion of internal semantics and algorithms. These proposals are likely to change significantly as they make their way through the process.

Step 2: Draft
Proposals at this stage should present a preliminary draft of the specification.

At this point, it is appropriate for implementers to start experimenting with actual implementations at runtime. Implementation can come in many forms: a polyfill, user code that controls the runtime to follow the proposal, an engine implementation (which basically provides support for the proposal), or it can be a build-time compiler such as Babel. can be supported by

Step 3: Candidates
The proposals at this stage are the recommendations of the candidate. In this advanced stage, the specification editor and designated reviewers will sign the final specification. A Phase 3 proposal is unlikely to change beyond addressing the issues identified in the wild.

Implementers should have expressed interest in the proposal as well – a proposal without the support of the implementers is dead in the water. In practice, proposals are up to this level at least by a browser implementation, a high-fidelity polyfill, or when supported by a build-time transpiler such as Babel.

Leave a Reply

Your email address will not be published. Required fields are marked *