8 JavaScript proposals you need to know
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 private
keyword. 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 user
and user.address
values 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 null
or 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 logged
is 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 @bound
decorator 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.