8 JavaScript proposals you need to know

Jakub Leszczyński
Liki Blog
Published in
6 min readMay 20, 2020

Introduction

Every programming language has a way to introduce new additions. TC39 is a committee that designs ECMAScript. This group developed a process that allows for easy and frequent releases of the specification. Each feature has to go through 5 maturity stages named as following:

  • stage 0 (strawperson)
  • stage 1 (proposal)
  • stage 2 (draft)
  • stage 3 (candidate)
  • stage 4 (finished)

Strawperson is the entry stage. Everyone can submit ideas and if they are not rejected immediately by the committee, they appear on the first stage.

As a new feature develops maturity, it goes through 4 more stages. Each one of them has strictly defined purposes, entrance criteria, acceptance signifies, spec quality, etc. Once a proposal gets to stage 4, the feature will be included in the nearest release of ECMAScript.

You can use unreleased features today by using transpiling tools like babel. All you have to do is to include a plugin for the corresponding proposal. You have to be careful though, remember that proposals might not make it to core specification or the API might change during the process.

The complete list of proposals is available to everyone on the TC39 website. I would like to cherry-pick the ones that I find the most interesting.

1. do Expressions

do is a new JavaScript keyword that is currently in stage 1 of the process. Its main motivation is to increase the readability of the code. Let’s see how the implementation looks like.

do expressions can be also combined with JSX

do expression is a nice tool for JavaScript developers. It focuses on expression-oriented programming which is a great advantage of functional programming. This stage 1 feature helps to maintain code and keeps variables as locally as possible. All of that leads to greater readability.

2. Private methods and setters/getters for JavaScript classes

Have you ever wanted to write a private field inside ES6 classes? You’ve learned that it’s not possible and your best shot so far is to use a convention for naming private fields. You’ve probably encountered property names prefixed with underscores like _calculateCost to distinguish private from public properties. It isn’t a perfect solution because it doesn’t provide any control.

TC39 members are fully aware of that problem. There is a proposal that includes private fields and it’s currently in stage 3.

Let’s take a look at the proposed syntax

In the proposed syntax, creating private fields is as simple as prefixing field name with #

This proposal was moved to stage 3 in September 2017. The committee is yet to decide on the final version of the implementation of the private field. There is an ongoing discussion about alternatives and additions. One of them introduces a privatekeyword. The other one relies on creating a new Symbol that allows us to specify private fields.

This leads to the conclusion that we should probably see private fields in the future of JavaScript, though the final syntax is not yet agreed on.

3. Promise.any

Another nice addition in stage 3 is Primise.any which is new Promise combinator. It short-circuits when an input value is fulfilled.

Note that we already have similar Promise combinator Promise.race. The difference is that Promise.race returns the first value that is being fulfilled or rejected while Promise.any continues resolving Promises until one of them is fulfilled, meaning that it won’t stop on rejected Promises.

4. Temporal

Did you know that JavaScript was released in 10 days? It isn’t the best thing. It sounds impressive considering that it’s the world’s most widely used language, but there are some things that we have to deal with these days. The built-in Date object is one of the ugly children of our favorite programming language.

There are many reasons that many developers tend to skip using the native Date object and include libraries like moment.js or date-fns in their projects. Current API is not the greatest, we don’t have support for time zones, etc. However, there is a light in the tunnel.

The proposed solution is currently in stage 2 and if everything goes according to the plan it should revolutionize how we approach dealing with dates in JavaScript. Its’ API is not yet finalized and it’s changing constantly, so it wouldn’t be included in a project just yet.

We talk about Temporal. Temporal is a global Object that acts like a top-level namespace (f.e. Math). I highly recommend looking at the documentation of Temporal as it’s a topic large enough for a separate article.

Temporal API greatly extends currently available date API and is being built on solid foundations with best practices in mind.

Being able to calculate the difference between dates:

or adding/subtracting units of time from dates:

without the necessity to import the external library sounds really good and it’s just a tip of the mountain as Temporal allows for much much more.

5. Map.prototype.upsert

Currently there are no prototype methods for updating and adding value to a map.

The proposed method allows for much more readable code that shows the developer’s intentions. Let’s see how upsert would look like with and without the proposed function.

without upsert:

with upsert:

or:

It’s a basic example. You can see other more complex ones on this proposal’s GitHub page.

6. Optional Chaining

Optional chaining is the feature that many of you might have already heard of. Currently being in stage 4, optional chaining is expected to be released in the nearest version of ECMAScript in 2020. Let’s take a look at why it makes it to this list.

JavaScript developers often have to deal with code like this:

This might often be a major problem when parsing large JSON files. People often include libraries like lodash to overcome this issue. It works great, but soon we will have a native solution.

Optional chaining checks if userand user.addressvalues exist. If they don’t, undefined value is returned. If we didn’t use optional chaining we would get an error.

The usage extends for interfaces with optional methods:

7. Nullish Coalescing Operator

Another operator that will be included in the next version of JavaScript is nullish coalescing operator. It tests against null and undefined values.

You can achieve a similar effect by using logical OR operator ||.

It has been with us since the beginning, so why is TC39 concerned and reinvents the wheel?

The answer is — they work differently. OR operator tests if a given value is falsy. As we know, empty strings and 0 values are considered falsy. It often leads to unexpected bugs if you wanted to keep falsy values.

Nullish coalescing operator tests if a given value is either nullor undefined.

It can also be combined with optional chaining:

This kind of code seems distant but will be a part of the specification in 2020.

8. Decorators

Decorators made it to stage 2 meaning there is a very high probability they will be included in future specifications. Many JavaScript developers already use decorators, because they are widely used through many libraries and frameworks.

Let me briefly introduce you to decorators if you haven’t heard about them yet. Decorators are declarations that can be attached to the class declaration, method, or property. They “decorate” our properties by adding new functionality or changing existing ones. Decorators use the naming convention of @logged, where loggedis the name of the decorator.

Proposed specification includes 4 built-it decorators that are used to compose custom decorators.

  • @wrap: Replace a method or the entire class with the return value of a given function
  • @register: Call a callback after the class is created
  • @expose: Call a callback given functions to access private fields or methods after the class is created
  • @initialize: Run a given callback when creating an instance of the class

Let’s build and use @bounddecorator as an example

To declare a decorator we use decorator keyword and built-in @initialize decorator

It’s one of many examples that were included in a proposal, if you want to learn more I highly encourage you to visit the TC39 GitHub page.

Conclusion

That’s it. I hope you found something interesting on the list. I recommend visiting the TC39 website and GitHub page if you want to read more about the proposals. There are many more that are worth checking out.

--

--

Jakub Leszczyński
Liki Blog

I’m a frontend developer. I like cooking and sharing my knowledge.