ECMAScript Updation and Implementation Cycle

ECMAScript is the specification of JavaScript and there are updates to this which come in the form of ES updates. Most of us are familiar with the ES6 update as it brought most of the modern JavaScript features that we know about. Part of the reason why the ES6 update was so big was that it was 6 years prior to the ES5 update coming out.

ES6 changed the way JavaScript was updated instead of being updated once in a while they changed it so the update could come on a yearly basis that is why the name of these updates has changed for the most part people use the year to represent the ES updates. These updates don't actually update the language itself all these updates do is update the ECMAScript. The ECMAScript basically describes how JavaScript should work and function. It's then up to the browser to implement these updates and changes. This is why sometimes a  feature could be in JavaScript officially announced and released but a browser still doesn't support it because they might not have implemented this feature yet and vice-versa.

The TC39 process defines how an implementation of a feature goes from a proposal to actually getting implemented by the browsers. And it goes through multiple different stages.

Changes to the language are developed by way of a process that provides guidelines for evolving an addition from an idea to a fully specified feature, complete with acceptance tests and multiple implementations. There are five stages: a strawperson stage, and 4 “maturity” stages. The TC39 committee must approve acceptance for each stage. 

Here are some of the most promising proposals 

Class static initialization blocks: This proposal is currently at stage 4 of the process. Class static blocks provide a mechanism for additional static initialization during class definition evaluation. Declare block inside the body of a class allows you to write code that will run at the class setup time and set up the static fields. It allows us the flexibility to access the private fields.

Note: As of now, this feature has not been implemented by Safari, IE, or Opera and has a global usage percentage of 74.14%.

Syntax:

class C {
     static {
           // Statements
     }
}

Let us look at the example below: 

class GFG{
    static #dateNow = new Date()
    static time
    static{
        GFG.time = GFG.#dateNow.toISOString()
    }
}
GFG.time

Output:

'2022-07-25T20:30:15.558Z'

Ergonomic brand checks for Private Fields: This proposal is currently at stage 4 of the process. To check if an object has a private field, and if that object doesn't have a private field, we can have some fallback behavior which might even be throwing a custom exception. This allows us to test if a private field exists in a certain class or not. We can use a try/catch block for resolving this issue, but doing so is not very intuitive:

class GFG {
      #code;

      static isGFG(obj) {
        try {
             obj.#code;
              return true;
        } catch {
              return false;
        }
      }
}

Output:

undefined

This problem can be resolved by using the "in" keyword, like this:

class GFG {
    #code
     isGFG(gfg){
        return #code in gfg;
     }
}

Output:

undefined

RegExp Match Indices: This allows us to find the offsets of any match that happened on the RegExp substring. In simple terms it allows us to find the positions of the starting and ending points of each match in a RegExp substring. The results point to the input string.

Let us look at the example below for Numbered groups: 

const match = /(e+)/d.exec('geeks');
match.indices[1];

Output:

(2) [1, 3]

Let us look at the example below for Named groups: 

const match = /(?<gs>g+)(?<es>e+)/d.exec('ggggeeks');

match.indices.groups.gs;
match.indices.groups.es;

Output:

(2) [4, 6]

tusharchoudhary8051

Follow

Improve

Article Tags :

• JavaScript
• Web Technologies