A brief history of javascript. Part 3
The third and final part of the translation of articles from the blog service Auth0 A Brief History of JavaScript . Key points: transpilers and ECMAScript 2015, a little about the new process of preparing updates, what to expect in the future and how Asm.js and WebAssembly will affect it. The translation was prepared by the Front Typing department of the company.
A brief history of javascript. Part 1
A brief history of javascript. Part 2
The ECMAScript Harmony plan became the basis for further JavaScript enhancements. Many of the ideas from ECMAScript 4 have sunk into oblivion for the benefit of all, but some have been revised. ECMAScript 6, later renamed ECMAScript 2015, should have brought great change. Almost all updates that somehow influenced the syntax were postponed specifically for this version. By 2015, the committee was finally able to overcome all internal differences, and ECMAScript 6 saw the light. Most browser manufacturers have already worked on supporting this version, but so far not all browsers are fully compatible with ECMAScript 2015.
')
The release of ECMAScript 2015 caused a sharp increase in the popularity of transporters, such as Babel or Traceur. Due to the fact that the manufacturers of these transpilers followed the work of the technical committee, many people had the opportunity to experience the benefits of ECMAScript 2015 long before its release.
Some of the main features of ECMAScript 4 were implemented in this version with a slightly different approach. For example, classes in ECMAScript 2015 are more than just syntactic sugar on top of prototypes. This approach facilitates the development and implementation of new features.
We (the editors of the Auth0 blog - approx. Lane) did a detailed review of the new features of ECMAScript 2015 in our article “A summary of the possibilities of JavaScript . ” You can also read the ECMAScript compatibility table to get an idea of ​​how the implementation process is going.
A short list of new features includes:
All these features opened JavaScript for an even greater number of programmers and made a significant contribution to a lot of programming.
It may surprise some people how so many new opportunities could have slipped past the standardization process, during which ECMAScript 4 was ruined. I would like to note that most of the most aggressive ECMAScript 4 innovations, such as namespaces or optional typing, were forgotten and more did not return, while others were rethought with regard to the objections. Work on ECMAScript 2015 was very hard and took almost six years (and even more, given the time required for implementation). But the very fact that the ECMAScript technical committee was able to cope with such a difficult task became a good sign.
In 2016, a small ECMAScript update was released. This version is the result of a new preparation process adopted in TC-39. All new proposals must go through four stages. A proposal that has reached the fourth stage has every chance of being included in the next version of ECMAScript (however, the committee has the right to postpone it for a later version). Thus, each proposal is developed individually (of course, taking into account its interaction with other proposals), without slowing down the development of ECMAScript.
If the proposal is ready for inclusion in the standard, and a sufficient number of other proposals have reached the fourth stage, a new version of ECMAScript will be released.
The version released in 2016 was very small. It included:
Nevertheless, several interesting proposals have already reached the fourth stage in 2016. What does ECMAScript prepare for us?
The most important proposal, reached the fourth stage, is async / await. This is an extension of JavaScript syntax that makes working with promises more enjoyable. For example, consider the ECMAScript 2015 code:
And compare it with the code that uses async / await:
Other proposals that have reached the fourth stage are quite small:
All these proposals are intended for the release of 2017, but the committee has the right to postpone them until the next release. But even the addition of async / await will be awesome.
The future does not end there. Let's look at some other suggestions to get an idea of ​​what lies ahead. Here are some of the most interesting:
JavaScript is becoming more and more like a general purpose language. But there is another big detail in the future of javascript that will make its own adjustments.
If you have not heard of WebAssembly, you should read about it . A huge number of libraries and frameworks that appeared after the release of ECMAScript 5, as well as the general development of the language, made JavaScript an interesting target for other languages. For large code structures, interoperability is a key need. Take, for example, games. The most common language in which games are written is C ++, so they can be ported to a large number of architectures. Nevertheless, porting to the Windows browser or console game was considered an impossible task. However, this was made possible thanks to the rapid development and unprecedented efficiency of today's JavaScript virtual machines. Tools like Emscripten were born to perform such tasks.
Orienting the situation quickly, Mozilla began work on making JavaScript a suitable target for compilers. This is how Asm.js came into being - a subset of JavaScript that is ideally suited as a similar target. JavaScript virtual machines can be optimized to recognize this subset and produce code that is much better than the one that the current virtual machines generate. Thanks to JavaScript, browsers are slowly becoming a new target for compilers.
Yet there are huge limitations that even Asm.js cannot overcome. In JavaScript, you must make such changes that differ from its current purpose. Something completely different is needed to make the web a worthy target for other programming languages. And that’s what WebAssembly is for — a low-level programming language for the web. Any program can be compiled into WebAssembly using a suitable compiler and then run in a suitable virtual machine (JavaScript virtual machines can provide the necessary level of semantics). The first versions of WebAssembly are 100% compatible with the Web.js specification. WebAssembly promises not only faster loading time (bytecode is processed faster than text), but also the possibility of optimization not available in Asm.js. Imagine a web with perfect interoperability between JavaScript and your programming language.
At first glance, this may hinder the growth of JavaScript, but in reality everything is completely different. Due to the fact that other languages ​​and frameworks will get interoperability with JavaScript, it will be able to continue its development as a general-purpose language. And WebAssembly is a necessary tool for this.
Currently, dev versions of Chrome, Firefox and Microsoft Edge have initial support for WebAssembly and are capable of playing demo applications .
We at Auth0 use JavaScript very tightly , which is the main programming language everywhere, from the Lock library to backends. Its asynchronous nature and ultimate simplicity for new developers are key to our success. We are watching with interest the development of the language and its influence on the entire ecosystem.
Sign up for free with Auth0 and get acquainted with the ecosystem written entirely in JavaScript. Do not worry, we have client libraries for all popular frameworks and platforms .
JavaScript history is long and full of unexpected turns. Initially proposed as a “Scheme for the Web,” he borrowed its syntax from Java. Its first prototype was developed in a few weeks. Adjusting to the requirements of the market, he changed three names in less than two years, after which he was standardized and got a name more suitable for skin disease . After three successful releases, the language has been cooking in hellish cauldrons for almost eight years. Then, thanks to the success of a single technology (AJAX), the community was able to overcome controversy and resume development. Version 4 was abandoned, and a small update known as version 3.1 was renamed to version 5. Version 6 spent many years in development (again), but this time the committee successfully completed the work, changing the number in the title to 2015. It was a very big update, and its implementation took a lot of time. As a result, JavaScript got a second wind. The community has revived as never before. Thanks to Node.js, V8 and other JavaScript projects, it rose to heights that the developers of the first version didn’t even think about, and thanks to Asm.js and WebAssembly it will fly even higher. Active proposals, which are in different stages, make the future of JavaScript clean and bright. Having come a long way, full of unexpected turns and obstacles, JavaScript remains one of the most successful languages ​​in programming history. And this is the best proof of its reliability. Always put on javascript.
A brief history of javascript. Part 1
A brief history of javascript. Part 2
ECMAScript 6 (2015) and 7 (2016): a universal programming language
The ECMAScript Harmony plan became the basis for further JavaScript enhancements. Many of the ideas from ECMAScript 4 have sunk into oblivion for the benefit of all, but some have been revised. ECMAScript 6, later renamed ECMAScript 2015, should have brought great change. Almost all updates that somehow influenced the syntax were postponed specifically for this version. By 2015, the committee was finally able to overcome all internal differences, and ECMAScript 6 saw the light. Most browser manufacturers have already worked on supporting this version, but so far not all browsers are fully compatible with ECMAScript 2015.
')
The release of ECMAScript 2015 caused a sharp increase in the popularity of transporters, such as Babel or Traceur. Due to the fact that the manufacturers of these transpilers followed the work of the technical committee, many people had the opportunity to experience the benefits of ECMAScript 2015 long before its release.
Some of the main features of ECMAScript 4 were implemented in this version with a slightly different approach. For example, classes in ECMAScript 2015 are more than just syntactic sugar on top of prototypes. This approach facilitates the development and implementation of new features.
We (the editors of the Auth0 blog - approx. Lane) did a detailed review of the new features of ECMAScript 2015 in our article “A summary of the possibilities of JavaScript . ” You can also read the ECMAScript compatibility table to get an idea of ​​how the implementation process is going.
A short list of new features includes:
- Let (lexical) and const (unchangeable) bindings
- Arrow functions (short anonymous functions) and lexical this
- Classes (syntactic sugar over prototypes)
- Object literal improvements (computed keys, shortened method definitions, etc.)
- Pattern lines
- Promises
- Generators, iterable objects, iterators and for..of
- The default function parameters and rest statement
- Spread syntakis
- Destructuring
- Modular syntax
- New collections (Set, Map, WeakSet, WeakMap)
- Proxy and Reflect
- Symbols data type
- Typed Arrays
- Class inheritance
- Tail recursion optimization
- Simplified Unicode Support
- Binary and octal literals
All these features opened JavaScript for an even greater number of programmers and made a significant contribution to a lot of programming.
It may surprise some people how so many new opportunities could have slipped past the standardization process, during which ECMAScript 4 was ruined. I would like to note that most of the most aggressive ECMAScript 4 innovations, such as namespaces or optional typing, were forgotten and more did not return, while others were rethought with regard to the objections. Work on ECMAScript 2015 was very hard and took almost six years (and even more, given the time required for implementation). But the very fact that the ECMAScript technical committee was able to cope with such a difficult task became a good sign.
In 2016, a small ECMAScript update was released. This version is the result of a new preparation process adopted in TC-39. All new proposals must go through four stages. A proposal that has reached the fourth stage has every chance of being included in the next version of ECMAScript (however, the committee has the right to postpone it for a later version). Thus, each proposal is developed individually (of course, taking into account its interaction with other proposals), without slowing down the development of ECMAScript.
If the proposal is ready for inclusion in the standard, and a sufficient number of other proposals have reached the fourth stage, a new version of ECMAScript will be released.
The version released in 2016 was very small. It included:
- Exponentiation operator (**)
- Array.prototype.includes
- A few minor corrections (generators cannot be used with new, etc.)
Nevertheless, several interesting proposals have already reached the fourth stage in 2016. What does ECMAScript prepare for us?
The future is close and not very: ECMAScript 2017 and the following versions
The most important proposal, reached the fourth stage, is async / await. This is an extension of JavaScript syntax that makes working with promises more enjoyable. For example, consider the ECMAScript 2015 code:
function apiDoSomethingMoreComplex(withThis) { const urlA = '...'; const urlB = '...'; httpLib.request(urlA, withThis).then(result => { const parsed = parseResult(result); return new Promise((resolve, reject) => { database.update(updateStatement, parsed).then(() => { resolve(parsed); }, error => { reject(error); }); }); }).then(result => { return httpLib.request(urlB, result); }).then(result => { return worker.processData(result); }).then(result => { logger.info(`apiDoSomethingMoreComplex success (${result})`); }, error => { logger.error(error); }); } And compare it with the code that uses async / await:
async function apiDoSomethingMoreComplex(withThis) { const urlA = '...'; const urlB = '...'; try { let result = await httpLib.request(urlA, withThis); const parsed = parseResult(result); await database.update(updateStatement, parsed); result = await httpLib.request(urlB, parsed); result = await worker.processData(result); logger.info(`apiDoSomethingMoreComplex success (${result})`); } catch(e) { logger.error(e); } } Other proposals that have reached the fourth stage are quite small:
- Object.values ​​and Object.entries
- Line alignment
- Object.getOwnPropertyDescriptors
- Comma delimiters in function parameters
All these proposals are intended for the release of 2017, but the committee has the right to postpone them until the next release. But even the addition of async / await will be awesome.
The future does not end there. Let's look at some other suggestions to get an idea of ​​what lies ahead. Here are some of the most interesting:
- SIMD API
- Asynchronous iterators (async / await + iteration)
- Switch generators
- Operations with 64-bit integers
- Areas (isolation states)
- Shared Memory and Atomics
JavaScript is becoming more and more like a general purpose language. But there is another big detail in the future of javascript that will make its own adjustments.
WebAssembly
If you have not heard of WebAssembly, you should read about it . A huge number of libraries and frameworks that appeared after the release of ECMAScript 5, as well as the general development of the language, made JavaScript an interesting target for other languages. For large code structures, interoperability is a key need. Take, for example, games. The most common language in which games are written is C ++, so they can be ported to a large number of architectures. Nevertheless, porting to the Windows browser or console game was considered an impossible task. However, this was made possible thanks to the rapid development and unprecedented efficiency of today's JavaScript virtual machines. Tools like Emscripten were born to perform such tasks.
Orienting the situation quickly, Mozilla began work on making JavaScript a suitable target for compilers. This is how Asm.js came into being - a subset of JavaScript that is ideally suited as a similar target. JavaScript virtual machines can be optimized to recognize this subset and produce code that is much better than the one that the current virtual machines generate. Thanks to JavaScript, browsers are slowly becoming a new target for compilers.
Yet there are huge limitations that even Asm.js cannot overcome. In JavaScript, you must make such changes that differ from its current purpose. Something completely different is needed to make the web a worthy target for other programming languages. And that’s what WebAssembly is for — a low-level programming language for the web. Any program can be compiled into WebAssembly using a suitable compiler and then run in a suitable virtual machine (JavaScript virtual machines can provide the necessary level of semantics). The first versions of WebAssembly are 100% compatible with the Web.js specification. WebAssembly promises not only faster loading time (bytecode is processed faster than text), but also the possibility of optimization not available in Asm.js. Imagine a web with perfect interoperability between JavaScript and your programming language.
At first glance, this may hinder the growth of JavaScript, but in reality everything is completely different. Due to the fact that other languages ​​and frameworks will get interoperability with JavaScript, it will be able to continue its development as a general-purpose language. And WebAssembly is a necessary tool for this.
Currently, dev versions of Chrome, Firefox and Microsoft Edge have initial support for WebAssembly and are capable of playing demo applications .
Using JavaScript in Auth0
We at Auth0 use JavaScript very tightly , which is the main programming language everywhere, from the Lock library to backends. Its asynchronous nature and ultimate simplicity for new developers are key to our success. We are watching with interest the development of the language and its influence on the entire ecosystem.
Sign up for free with Auth0 and get acquainted with the ecosystem written entirely in JavaScript. Do not worry, we have client libraries for all popular frameworks and platforms .
Conclusion
JavaScript history is long and full of unexpected turns. Initially proposed as a “Scheme for the Web,” he borrowed its syntax from Java. Its first prototype was developed in a few weeks. Adjusting to the requirements of the market, he changed three names in less than two years, after which he was standardized and got a name more suitable for skin disease . After three successful releases, the language has been cooking in hellish cauldrons for almost eight years. Then, thanks to the success of a single technology (AJAX), the community was able to overcome controversy and resume development. Version 4 was abandoned, and a small update known as version 3.1 was renamed to version 5. Version 6 spent many years in development (again), but this time the committee successfully completed the work, changing the number in the title to 2015. It was a very big update, and its implementation took a lot of time. As a result, JavaScript got a second wind. The community has revived as never before. Thanks to Node.js, V8 and other JavaScript projects, it rose to heights that the developers of the first version didn’t even think about, and thanks to Asm.js and WebAssembly it will fly even higher. Active proposals, which are in different stages, make the future of JavaScript clean and bright. Having come a long way, full of unexpected turns and obstacles, JavaScript remains one of the most successful languages ​​in programming history. And this is the best proof of its reliability. Always put on javascript.
Source: https://habr.com/ru/post/324908/
All Articles