ES6 and beyond. Chapter 1: ES? Present and Future

I want to pay attention to the book that Kyle Simpson wrote - "ES6 and beyond" (eng. "ES6 & Beyond"). Of course, the contribution was made not only by him, but by many wonderful contributors. Thanks
At the moment, it has the status - completed draft.

Table of contents:

• Chapter 1: ES? Present & Future
• Chapter 2: Syntax
• Chapter 3: Organization
• Chapter 4: Asynchronous Flow Control
• Chapter 5: Collections
• Chapter 6: API Add-ons
• Chapter 7: Meta Programming
• Chapter 8: Beyond ES6

Before you start reading this book, I believe that you already have a solid knowledge of JavaScript right up to the most popular standard (at the time of writing this book), which is usually called ES5 (technically, this is ES5.1). Here we will talk about the upcoming standard ES6 and try to understand the further development of JS.

ES6 is not just a modest set of new APIs added to the language, as was the case with ES5. It includes a lot of new syntactic forms, the understanding of which can take time before they become a habit. There are also several new organizational forms and a new API with many helpers for existing data types.
')
ES6 is a radical leap forward. Even if you think you know JS (ES5), then ES6 is full of new things that you still have to learn. So get ready! This book will cover all the main topics of ES6, which will help you quickly get used to it and even more - look into the future to be ready for new changes.

Warning: all the code in this book requires an ES6 environment.

Versioning

JavaScript is officially called “ECMAScript” (abbreviation “ES”) and, until recently, the version was an integer (that is, “5”, “5th edition”).

Earlier versions of ES1 and ES2 were not so widely implemented, but ES3 was the first widely accepted basis for JavaScript. ES3 is a JavaScript standard for browsers such as IE6-8 and older mobile browsers on Android 2.x systems. We will not consider ES4 for “political” reasons. This standard has been dropped.

In 2009, ES5 was officially finished (later ES5.1 in 2011), and became a widespread standard for a whole heap of browsers such as Firefox, Chrome, Opera, Safari, and many others.

Waiting for the next version of JS (in 2013, then in 2014, and then in 2015), the most talked about new tag was ES6.
However, later in the ES6 specification sheet, suggestions emerged that the versioning model should have an annual mark at the base. For example, ES2016 (ES7), meaning that the standard was completed at the end of 2016. Many disagree with this and in any case it is too late to rename ES6. But as a matter of fact, a similar version model can be.

Also, thanks to simple observation, we can say that the evolution of JS is proceeding at a faster pace than annual versioning. As soon as the idea for a new standard begins to progress in discussions, browsers begin to prototype features (functions, API) and adapt them earlier for experiments with code (we all know the experimental flags).

Usually, before the official stamp of approval is put, the peculiarities of the de facto language go through the standardization stage due to early prototyping. Therefore, it is worth talking about the future JS versioning model which will be based on new pre-functions rather than on the annual model or the model of the pre-annual-collection of basic functions that is currently in use.

I’ll introduce the fact that version labels like ES6 are no longer important, and JavaScript must be a kind of evergreen living standard. The best way to overcome labels is to stop thinking that your code depends on the “ES6 version” in favor of the “feature-by-feature” for further support.

Transpiling

For developers who want to use the new features of the language, there is the problem of supporting applications / sites in older browsers that do not support them.
The main thinking was to expect the adoption of ES5 until most or even all of the surroundings fall out of the support spectrum. As a result, many recently just started to independently implement things, such as, for example, strict mode, which took root in ES5 many years ago.

Many would agree that this approach of waiting and tampering down the specification is detrimental to the JS ecosystem. Those people who are responsible for the development of a language want the developers to use the new features of the language and its patterns as soon as they have been stabilized in the specification; browsers have a chance to implement them.

So how do we solve this slight contradiction? The answer is tuling, namely, this technique is called transpiling (transformation + compilation).

For example, consider an abbreviated parameter declaration (Object literals will be discussed in Chapter 2). Here’s how it looks in ES6:

var foo = [1,2,3]; var obj = { foo //   `foo: foo` }; obj.foo; // [1,2,3] 

And this is how it will look like after transpiling:

 var foo = [1,2,3]; var obj = { foo: foo }; obj.foo; // [1,2,3] 

This is not a significant, but pleasant transformation, which allows us to reduce foo: foo in the description of the object literal. Using only foo if the names are the same.

Transpiling usually takes place in the process of development on a level with lingting, minification, etc.

Shima / Polyphile

Not all new features of ES6 require transpiling. Polyphilous (Shima) is such a pattern that determines the equivalent behavior of the new environment in the older, of course, when it is possible. The syntax may not be polyphilic, but the API may.

For example, Object.is (..) is a new utility for checking the strict equivalence of two values, but with no exceptions, which has === for NaN and -0. The polyphyl of the Object.is (..) method is fairly simple:

 if (!Object.is) { Object.is = function(v1, v2) { // test for `-0` if (v1 === 0 && v2 === 0) { return 1 / v1 === 1 / v2; } //    `NaN` if (v1 !== v1) { return v2 !== v2; } //    return v1 === v2; }; } 

Pay attention to the outer wrapper around the polyphile - if. This is an important detail, which means that the snippet is defined only for the old environment where this API has not yet been implemented. You rarely need to override existing APIs.
There is an excellent collection of ES6 shims called ES6 Shims , which you can use as part of your new project.

Obviously, JS will consistently evolve with browsers that will roll out new features gradually, rather than in large chunks. Therefore, the best strategy to keep up with the updates and the evolution of the language is to introduce polyfiles into your basic code and add transpiling to the development process and thereby get used to the new reality.

If you decide to keep the status quo and just wait until all browsers fully support the capabilities of the language, you will be far behind. You risk missing those innovations that were invented to write JavaScript more efficiently and reliably.

Review

It is important to tune your thinking to the new way that JavaScript will evolve. You should not wait for years until the new standard is approved. At the moment, new features of JavaScript are being introduced into browsers as far as possible, whether you are ready to use them now or wait - it only depends on you.

No matter what labels future JavaScript gets, language development will be much faster than it was before. Transpiling and polyphiles are important tools to help you keep up with the development and emergence of new features.