Understanding TC39 Process and Stage 3 Specifications

Ecma TC39, the committee which handles making ECMAScript better and easy to use; has come up with many specifications that help JS community to evolve.

TC39 process has five different stages to get the specification live.

• Stage 0: Strawperson — to allow input into specifications
• Stage 1: Proposal — make the case for the addition, describe the solution and identify the potential challenges
• Stage 2: Draft — describe the syntax and semantics using formal spec language
• Stage 3: Candidate — states that further refinement will need feedback from implementations and users
• Stage 4: Finished — states that the addition is ready for inclusion in the formal ECMAScript standard

Let us discuss some of the Stage 3 Specifications from TC39 (as of Aug 2019).

1. globalThis : globalThis maintains its identity even after page navigation.

In HTML, the global object is separated into the Window and the WindowProxy. New attributes are set on the Window, but top-level this has the identity of the WindowProxy. The WindowProxy forwards all object operations to the underlying Window, but as the page changes, globalThis maintains the same identity while the underlying Window is swapped out.

For Example,

page-one.html

page-two.html

index.html

2. BigInt : BigInt is a new primitive that provides a way to represent whole numbers larger than 2 power 53, which is the largest number Javascript can represent with the Number primitive.

That means, maxIntPlusOne === maxIntPlusTwo !!

To solve this, BigInt was created by adding n at the end or by calling the constructor.

For Example:

3. JS Classes with Private methods and Getter/Setters: Yes, there was a proposal from 2017 to define private methods, get {} and set {} in Javascript Classes.

If we have to write a JS counter, in ES2015 it will be

In ESnext after private method implementation, the above code will look like

• # is added for all the private methods
• number1Value and number2Value are initiated at the top as a private method and not in the constructor
• By adding # to getter/setters, now they are private methods

The main objective here is, With all its implementation kept internal to the class, this custom element can present an interface which is like a built-in HTML element. Users of the custom element don’t have the power to mess around with any of its internals

Fun Facts about this proposal,

• This proposal reached Stage 3 in September 2017
• TC39 had a lot of discussions over this and considered many other alternatives like using keyword private, static private and even Private Symbols

You can experiment with the class fields proposal using the following complete implementations:

• Babel 7.0+
• Node 12
• Public fields are enabled by default in Chrome 72 / V8 7.2
• Private fields are enabled by default in Chrome 74 / V8 7.4
• Partial, in-progress support in Firefox 67

Further implementations are on the way:

• In progress in TypeScript
• Out for review in Safari/JSC
• In progress in Firefox/SpiderMonkey

4. Numeric Separators: Creating a visual separation in digits to make it more readable.

The motivation for the proposal,

5. Promise.allSettled: Promise is settled when it is not in pending, i.e, it’s either resolved or rejected.Promise.allSettled as the name suggest, will give out information from an array of promises like Promise.all but does not short-circuit when the input values are rejected

Example,

6. Top-level await: Top-level await enables modules to act as big async functions: With top-level await, ECMAScript Modules (ESM) can await resources, causing other modules who import them to wait before they start evaluating their body.

Example code

Issues with this Proposal,

• Limitation on IIAFE (Immediately Invoked Async Function Expression)
• Learning the right protocol to find the Promise to wait on the module being loaded
• Inconsistency of app load, if the protocol is incorrect
• main will have to be threaded correctly since it's a promise

7. Optional Chaining for JavaScript: Yes, you heard it right. Javascript will soon have optional chaining like C#, TS, etc..

Optional Chaining - ? is checking the existence of intermediate nodes within an object. We do this check too often in JS.

How will it look after Optional Chaining reaches stage 4

8. Nullish Coalescing for JavaScript (??): When performing property accesses, it is often desired to provide a default value if the result of that property access is null or undefined. At present, a typical way to express this intent in JavaScript is by using the || operator.

Example

const undefinedValue = response.undefinedValue || 'some other default';

With Nullish Coalescing in place, the above line of code will look like,

const undefinedValue = response.undefinedValue ?? 'some other default';

this proposal calls out null and undefined values.

That’s it for now and Thanks for the read, I hope this article helps. Comments and Feedbacks are appreciated! :)

Reference:

1. https://tc39.es/

Want to learn more about me?

www.prashanthpnaika.com

https://www.linkedin.com/in/prashanthnaika

https://github.com/pnaika