5 ECMAScript Proposals To Look Out For In ES2020
Tags: javascript, ecmascript, es2020
Published: 2020-01-14 22:26:01

---
title: 5 ECMAScript Proposals To Look Out For In ES2020
published: true
description:  A new year, a new ECMAScript! In 2020 many new proposals were added to the latest release of ECMAScript, called ES2020.
cover_image: https://thepracticaldev.s3.amazonaws.com/i/pvk3sxsp8vkravlj1ajy.jpg
tags: js, ECMAScript, es2020, javascript
---

A new year, a new ECMAScript! Last year 8 proposals have reached stage 4, and are now included in the release of ES2020. In this post, I'll discuss 5 of these new additions using code examples. But first, let's have a quick look at what the process of adding a new addition to ECMAScript looks like.

## The ECMAScript Process

At the very core of the specification is [TC39](https://www.ecma-international.org/memento/tc39-m.htm), the committee that evolves JavaScript, adds and reviews new proposals to ECMAScript. Proposals to the specification usually represent problems that the committee (and community) is interested in exploring solutions for. New additions have to go through five stages in which their value and feasibility are tested, before being added to ECMAScript:

- **Stage 0: Strawperson**: TC39 members can propose any idea, change, or addition that hasn't been proposed before (or wasn't completely rejected).

- **Stage 1: Proposal**: A proposal is created by a TC39 member, and discusses a concrete problem and solution. 

- **Stage 2: Draft** — The syntax (most of) and semantics of the proposal are described using the formal specification language.

- **Stage 3: Candidate** — Specifications for the proposal are completed and reviewers have signed-off on these.

- **Stage 4: Finished** — The proposal is ready to be included in an upcoming ECMAScript release.

In 2019 some proposals [made it to stage 4](https://github.com/tc39/proposals/blob/master/finished-proposals.md), including the 5 new additions listed in the next section!

## Finished Proposals

As mentioned before, a proposal is finished when it reaches stage 4. At this point the proposal is complete and the syntax and semantics match the criteria of TC39. For this post I've selected 5 of these proposals that interested me the most:

### 1. Optional Chaining ([Github](https://github.com/tc39/proposal-optional-chaining))

This is probably the proposal that got the most attention of all proposals on this list. Optional chaining helps you to get rid of writing code to validate if you're able to read values by chaining. Instead of throwing an error when you use the chaining operator `.` to reach a value that doesn't exist, the optional chaining operator `.?` will return `undefined`. Suppose you have a variable called `post` with the following form:

```js
const post = {
 title: 'My post',
 description: 'Lorem Ipsum...',
 meta: {
  title: 'My Post'
 }
}
```

If you want to get the value for the `title` field from `meta`, you can use the chaining operator `.` to get that value:

```js
console.log(post.meta.title)
// My Post
```

But when you're not sure if the field `meta` will exists, you need to add a check for that field otherwise you'll get a `TypeError` when running your code:

```js
const post = {
 title: 'My post',
 description: 'Lorem Ipsum...',
}

console.log(post.meta && post.meta.title)
// undefined

console.log(post.meta.title)
// Uncaught TypeError: Cannot read property 'title' of undefined 
```

With the optional chaining parameter `.?` you can leave out the validation for the existence of the field `meta` like this:


```js
console.log(post.meta?.title)
// undefined
```

🚀 [Play with the code on CodePen](https://codepen.io/gethackteam/pen/wvBxJyB)


### 2. Dynamic `import()` ([Github](https://github.com/tc39/proposal-dynamic-import))

Developers that use web frameworks or libraries to write applications are probably already familiar with dynamic imports. Dynamically importing modules in your application can help you with improving the performance of your application, like [`React.lazy`](https://reactjs.org/docs/code-splitting.html#reactlazy) does for React applications. With the dynamic `import()` statement you can also use this feature in any JavaScript application, so instead of a static import:

```js
import { getPosts } from './utils';

console.log(getPosts());
// Array of posts
```

You can now dynamically import this function into your application:

```js
import("./utils").then(utils => {
 console.log(utils.getPosts());
 // Array of posts
});
```

And even destructure the `getPosts` function while doing so:

```js

let posts = []

import("./utils").then(({ getPosts }) => {
 console.log(getPosts());
 // Array of posts
});
```

By dynamically importing code you can reduce the time that your applications take to load, and focus on returning something to the user as fast as possible.  

### 3. `Promise.allSettled` ([Github](https://github.com/tc39/proposal-promise-allSettled))

In recent releases of ECMAScript, there have been multiple additions that improved the `Promise` constructor, which are `Promise.all`, `Promise.race`, and `Promise.any`. These methods (or also called [Promise combinators](https://v8.dev/features/promise-combinators)) help you tying multiple Promises together, like using the `Promise.all` method to combine the results of multiple Promises (or in example `fetch` requests):

```js
const promises = [
 Promise.resolve(1),
 Promise.resolve(2),
 Promise.resolve(3)
];
  
Promise.all(promises)
 .then(responses => console.log(responses)) // [1, 2, 3]
 .catch(e => console.log(e))
```

As all Promises resolve, the response will be the combined results of all Promises. The downside is that when one of your Promises rejects, the results don't get returned:

```js
const promises = [
 Promise.resolve(1),
 Promise.resolve(2),
 Promise.reject('error')
];
  
Promise.all(promises)
 .then(responses => console.log(responses))
 .catch(e => console.log(e)) // "error"
```

Instead of returning the combined results of all Promises, only the results of the rejected Promise will be returned. The `Promise.allSettled` method fixes this by returning a status for all the Promises:

```js
Promise.allSettled(promises)
 .then(responses => console.log(responses.map(response => response.status))) // ["fulfilled", "fulfilled", "rejected"]
```

And also the values if the Promise resolved, or the reason for rejecting the Promise:

```js
Promise.allSettled(promises)
 .then(responses => console.log(responses.map(response => response.value || response.reason))) // [1, 2, "error"]
```

🚀 [Play with the code on CodePen](https://codepen.io/gethackteam/pen/abzjWyM)


### 4. Nullish coalescing Operator ([Github](https://github.com/tc39/proposal-nullish-coalescing))

This last addition I'd like to mention is somewhat similar to the optional chaining operator `.?`, as both additions help you to skip writing code for validating values. In the case of the nullish coalescing operator `??`, it saves you time checking for values that are falsy null, like an empty string:

```js
const post = {
 title: 'My post',
 description: 'Lorem Ipsum...',
 meta: {
  title: ''
 }
}

console.log(post.meta.title || 'Not found')
// Not found
```

Above you can see that the value for `title` in `meta` is an empty string, which is seen as `false` by the `||` operator. However, with the nullish coalescing operator `??` the value for `metaTitle` will be the empty string:

```js
console.log(post.meta.title ?? 'Not found')
// ''
```

🚀 [Play with the code on CodePen](https://codepen.io/gethackteam/pen/NWPBjoy)

### 5. `BigInt` ([Github](https://github.com/tc39/proposal-bigint))

This last one might not be an addition that you'll use, but I'm pretty sure it will show up in technical interviews. With the `BigInt` primitive, the biggest `Number` that can be represented in JavaScript is no longer _9007199254740991_. If you look at the maximum value of `Number`, you'll see the following:

```js
const maxNumber = Number.MAX_SAFE_INTEGER

console.log(maxNumber) // 9007199254740991

console.log(maxNumber + 1) // 9007199254740992
console.log(maxNumber + 2) // 9007199254740992
```

As _9007199254740992_ is the maximum value `Number` can represent in JavaScript, you can't exceed this number. However, with `BigInt` you can get a higher value:

```js
const maxNumber = Number.MAX_SAFE_INTEGER

const biggerNumber = BigInt(maxNumber) + 2n
console.log(biggerNumber) // 9007199254740993n
```

Notice, you can't add the value `2` to the `BigInt`, instead, you need to add the value `2n`. To display the value of the `BigInt` you need to use the method `toString()` or `toLocaleString()`, as the value can only be used for calculations

```js
console.log(biggerNumber.toString()) // "9007199254740993"
```

🚀 [Play with the code on CodePen](https://codepen.io/gethackteam/pen/mdyjwqp)

## What else?

In this post, I've shared my favorite new additions to the ECMAScript specification, but more have been released in ES2020. For the full list of finished (and released) proposals, you can have a look [here](https://github.com/tc39/proposals/blob/master/finished-proposals.md). Missing a new addition that you like on this list? Use the comments section or [Twitter](https://twitter.com/gethackteam) to let me know!

_Photo by SpaceX on [Unsplash](https://unsplash.com/photos/OHOU-5UVIYQ)_