In this blog post, I am going to discuss TC39 and its contribution to ECMAScript.
What is ECMAScript?
ECMA-262 is a standard published by ECMA International. It contains specifications for a general purpose scripting language known as ECMAScript.
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?
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
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.