What’s New in ES2022? 4 Latest JavaScript Features | by Jose Granja | Jul, 2022

An overview of the new ES13 specs

Image by the author.

The new ES12 specs are finally released. Specs? JavaScript is indeed not an open-source language. It’s a language written following the ECMAScript standard specifications. The TC39 committee is in charge of discussing and approving new features. Who are they?

“ECMA International’s TC39 is a group of JavaScript developers, implementers, academics, and more, collaborating with the community to maintain and evolve the definition of JavaScript.” —

Their release process is composed of five stages. Since 2015, they have been doing yearly releases. They normally happen around springtime. The next proposal date for approval is on June.

There are two ways to refer to any ECMAScript release:

  • By its year: this new release will be ES2022.
  • By its iteration number: This new release will be the 13th iteration, so it can be referred to as ES13.

So what is new in this release? What features can we get excited about?

Currently, the start index of a match is returned when using the JavaScript Regex API in JavaScript. However, that is not enough for some special advanced scenarios.

As part of these specs, a special flag d was added. By using it the regex API will return a two-dimensional array indices with the start and end for each match. If there was any named group captured in the regex it will show in the indices.groups object, with the name of the group being the key.

See the original proposal here.

Before this proposal, it was not accepted to have top level awaits. There were some workarounds to kind of simulate the behaviour but all hard their drawbacks.

The top-level await feature let us rely on the module to handle these promises. It will have consequences for the execution of the modules depending on those you use top-level await.

Let’s see an example:

In the above example, the engine will wait for the users to be fulfilled prior to executing the code on the usage.js module. This feature is not to be abused and needs to be handled with care.

See the original proposal here.

For a long time, there has been the request of JavaScript providing a firstly Python like array accessing. Instead of doing array[array.length-1] to do simply array[-1]. That is simply not possible because the [] notation is also used on objects.

The accepted proposals take a more practical approach. The Array object will now have a method at that will mimic the above behaviour.

Btw, now that we are speaking about arrays, do you know you can deconstruct the array position?

See the original proposal here.

The following is just a nice to have simplification. There is already the hasOwnProperty. However, that needs to be called within the instance of the lookup we want to do. Therefore it was common for many developers to end up doing this:

With these new specs a hasOwn method was added to the Object prototype. We can now do simply:

See the original proposal here.

Errors help us identify and react to unexpected behavior of our application. However, it can become challenging to understand the root cause of deeply nested errors or even to handle them properly. We lose the stack trace info when catching them and rethrowing. The task of augmenting that error fell into our hands. There was no clear agreement on how to handle that.

As part of these new specs, there is now one property that we can pass to {clause: err} property that we can pass to the Error constructor. It all becomes simpler, standard and easy to understand deeply nested errors

You can find out more about the proposal here.

Before this spec release, there was not a proper way to create private fields. There were some ways around hoisting but it was not a proper private field. Now it is simple. We just need to prepend the # character to our variable declaration.

Having private fields means we have a strong encapsulation boundary. It is not possible to access the class variable from outside it. This showcases the class keyword is not anymore just sugar syntax.

We can also create private methods:

The feature is related to the Class Static Block and Ergonomic checks for Private Classes which we will see below.

You can find out more about the proposal here.

As part of the new specs, we can now include static blocks inside any class. They will run just once and are a great way to decorate or perform some per-field initialization of the static side of a class.

We are not limited to using one block, we can have as many as we need.

They have a nice bonus. They get privileged access to private fields. You can use them to do some interesting patterns.

If we tried from the outside scope of the instance object we would get Cannot read private member #privateField from an object whose class did not declare it.

You can find out more about the proposal here.

The new private fields are a great feature. However, it might become handy to check if a field is private or not in some static methods for example. Trying to invoke this in outside the class scope will result in the same error we have seen previously.

You can find out more about the proposal here.

This is an interesting release that provides a lot of small, useful features like at, private fields and error cause. Surely error clause will bring a lot of clarity to our daily bug tracking tasks.

Some advanced features like top-level await need to be well understood prior to using them. They might have unwanted side-effect in your code execution

I hope this article got you as excited as I am about the new ES2022 specs.

News Credit

%d bloggers like this: