Over a million developers have joined DZone.

A Brief History of JavaScript (Part 3)

DZone's Guide to

A Brief History of JavaScript (Part 3)

Continuing on with his brief history of JavaScript, Sebastian Peyrott concludes the series, talking about modern JavaScript and where it's headed next.

· Web Dev Zone
Free Resource

Prove impact and reduce risk when rolling out new features. Optimizely Full Stack helps you experiment in any application.

Continuing on from parts one and two, we arrive at our conclusion to the series. Read on to hear about modern JavaScript. 

ECMAScript 5: The Rebirth Of JavaScript

After the long struggle of ECMAScript 4, from 2008 onwards, the community focused on ECMAScript 3.1. ECMAScript 4 was scrapped. In the year 2009, ECMAScript 3.1 was completed and signed-off by all involved parties. ECMAScript 4 was already recognized as a specific variant of ECMAScript even without any proper release, so the committee decided to rename ECMAScript 3.1 to ECMAScript 5 to avoid confusion.

ECMAScript 5 became one of the most supported versions of JavaScript, and also became the compiling target of many transpilers. ECMAScript 5 was wholly supported by Firefox 4 (2011), Chrome 19 (2012), Safari 6 (2012), Opera 12.10 (2012), and Internet Explorer 10 (2012).

ECMAScript 5 was a rather modest update to ECMAScript 3, it included:

  • Getter/setters
  • Trailing commas in array and object literals
  • Reserved words as property names
  • New Object methods (create, defineProperty, keys, seal, freeze, getOwnPropertyNames, etc.)
  • New Array methods (isArray, indexOf, every, some, map, filter, reduce, etc.)
  • String.prototype.trim and property access
  • New Date methods (toISOString, now, toJSON)
  • Function bind
  • JSON
  • Immutable global objects (undefined, NaN, Infinity)
  • Strict mode
  • Other minor changes (parseInt ignores leading zeroes, thrown functions have proper this values, etc.)

None of the changes required syntactic changes. Getters and setters were already unofficially supported by various browsers at the time. The new Objectmethods improve "programming in the large" by giving programmers more tools to ensure certain invariants are enforced (Object.seal, Object.freeze, Object.createProperty). Strict mode also became a strong tool in this area by preventing many common sources for errors. The additional Array methods improve certain functional patterns (map, reduce, filter, every, some). The other big change is JSON: a JavaScript-inspired data format that is now natively supported through JSON.stringify and JSON.parse. Other changes made small improvements in several areas based on practical experience. All-in-all, ECMAScript 5 was a modest improvement that helped JavaScript become a more usable language, for both small scripts and bigger projects. Still, there were many good ideas from ECMAScript 4 that got scrapped and would see a return through the ECMAScript Harmony proposal.

ECMAScript 5 saw another iteration in the year 2011 in the form of ECMAScript 5.1. This release clarified some ambiguous points in the standard but didn't provide any new features. All new features were slated for the next big release of ECMAScript.

ECMAScript 6 (2015) & 7 (2016): a General Purpose Language

The ECMAScript Harmony proposal became a hub for future improvements to JavaScript. Many ideas from ECMAScript 4 were canceled for good, but others were rehashed with a new mindset. ECMAScript 6, later renamed to ECMAScript 2015, was slated to bring big changes. Almost every change that required syntactic changes was pushed back to this version. This time, however, the committee achieved unity and ECMAScript 6 was finally released in the year 2015. Many browser vendors were already working on implementing its features, but with a big changelog, things took some time. Even today, not all browsers have complete coverage of ECMAScript 2015 (although they are very close).

The release of ECMAScript 2015 caused a big jump in the use of transpilers such as Babel or Traceur. Even before the release, as these transpilers tracked the progress of the technical committee, people were already experiencing many of the benefits of ECMAScript 2015.

Some of the big features of ECMAScript 4 were implemented in this version of ECMAScript. However, they were implemented with a different mindset. For instance, classes in ECMAScript 2015 are little more than syntactic sugar on top of prototypes. This mindset eases the transition and the development of new features.

We did an extensive overview of the new features of ECMAScript 2015 in our A Rundown of JavaScript 2015 features article. You can also take a look at the ECMAScript compatibility table to get a sense of where we stand right now in terms of implementation.

A short summary of the new features follows:

  • Let (lexical) and const (unrebindable) bindings
  • Arrow functions (shorter anonymous functions) and lexical this (enclosing scope this)
  • Classes (syntactic sugar on top of prototypes)
  • Object literal improvements (computed keys, shorter method definitions, etc.)
  • Template strings
  • Promises
  • Generators, iterables, iterators and for..of
  • Default arguments for functions and the rest operator
  • Spread syntax
  • Destructuring
  • Module syntax
  • New collections (Set, Map, WeakSet, WeakMap)
  • Proxies and Reflection
  • Symbols
  • Typed arrays
  • Support for subclassing built-ins
  • Guaranteed tail-call optimization
  • Simpler Unicode support
  • Binary and octal literals

Classes, let, const, promises, generators, iterators, modules, etc. These are all features meant to take JavaScript to a bigger audience, and to aid in programming in the large.

It may come as a surprise that so many features could get past the standardization process when ECMAScript 4 failed. In this sense, it is important to remark that many of the most invasive features of ECMAScript 4 were not reconsidered (namespaces, optional typing), while others were rethought in a way they could get past previous objections (making classes syntactic sugar on top of prototypes). Still, ECMAScript 2015 was hard work and took almost 6 years to complete (and more to fully implement). However, the fact that such an arduous task could be completed by the ECMAScript technical committee was seen as a good sign of things to come.

A small revision to ECMAScript was released in the year 2016. This small revision was the consequence of a new release process implemented by TC-39. All new proposals must go through a four stage process. Every proposal that reaches stage 4 has a strong chance of getting included in the next version of ECMAScript (though the committee may still opt to push back its inclusion). This way proposals are developed almost on their own (though interaction with other proposals must be taken into account). Proposals do not stop the development of ECMAScript. If a proposal is ready for inclusion, and enough proposals have reached stage 4, a new ECMAScript version can be released.

The version released in year 2016 was a rather small one. It included:

  • The exponentiation operator (**)
  • Array.prototype.includes
  • A few minor corrections (generators can't be used with new, etc.)

However, certain interesting proposals have already reached stage 4 in 2016, so what lies ahead for ECMAScript?

The Future and Beyond: ECMAScript 2017 and Later

Perhaps the most important stage 4 proposal currently in the works is async/await. Async/await are a syntactic extension to JavaScript that make working with promises much more palatable. For instance, take the following 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(() => {
            }, error => {
    }).then(result => {
        return httpLib.request(urlB, result);
    }).then(result => {
        return worker.processData(result);
    }).then(result => {
        logger.info(`apiDoSomethingMoreComplex success (${result})`);
    }, error => {

And compare it to the following async/await enabled code:

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) {

Other stage 4 proposals are minor in scope:

  • Object.values and Object.entries
  • String padding
  • Object.getOwnPropertyDescriptors
  • Trailing commas if function parameters

These proposals are all slated for release in the year 2017, however the committee may choose to push them back at their discretion. Just having async/await would be an exciting change, however.

But the future does not end there! We can take a look at some of the other proposals to get a sense of what lies further ahead. Some interesting ones are:

  • Asynchronous iteration (async/await + iteration)
  • Generator arrow functions
  • 64-bit integer operations
  • Realms (state separation/isolation)
  • Shared memory and atomics

JavaScript is looking more and more like a general purpose language. But there is one more big thing in JavaScript's future that will make a big difference.


If you have not heard about WebAssembly, you should read about it. The explosion of libraries, frameworks, and general development that was sparked since ECMAScript 5 was released has made JavaScript an interesting target for other languages. For big codebases, interoperability is key. Take games for instance. The lingua-franca for game development is still C++, and it is portable to many architectures. Porting a Windows or console game to the browser was seen as an insurmountable task. However, the incredible performance of current JIT JavaScript virtual machines made this possible. Thus things like Emscripten, a LLVM-to-JavaScript compiler, were born.

Mozilla saw this and started working on making JavaScript a suitable target for compilers. Asm.js was born. Asm.js is a strict subset of JavaScript that is ideal as a target for compilers. JavaScript virtual machines can be optimized to recognize this subset and produce even better code than is currently possible in normal JavaScript code. The browser is slowly becoming a whole new target for compiling apps, and JavaScript is at the center of it.

However, there are certain limitations that not even Asm.js can resolve. It would be necessary to make changes to JavaScript that have nothing to do with its purpose. To make the web a proper target for other languages something different is needed, and that is exactly what WebAssembly is. WebAssembly is a bytecode for the web. Any program with a suitable compiler can be compiled to WebAssembly and run on a suitable virtual machine (JavaScript virtual machines can provide the necessary semantics). In fact, the first versions of WebAssembly aims at 1-on-1 compatibility with the Asm.js specification. WebAssembly not only brings the promise of faster load times (bytecode can be parsed faster than text), but possible optimizations not available at the moment in Asm.js. Imagine a web of perfect interoperability between JavaScript and your existing code.

At first sight, this might appear to compromise the growth of JavaScript, but in fact it is quite the contrary. By making it easier for other languages and frameworks to be interoperable with JavaScript, JavaScript can continue its growth as a general purpose language. And, WebAssembly is the necessary tool for that.

At the moment, development versions of Chrome, Firefox, and Microsoft Edge support a draft of the WebAssembly specification and are capable of running demo apps.

Aside: JavaScript Use at Auth0

At Auth0 we are heavy users of JavaScript. From our Lock library to our backend, JavaScript powers the core of our operations. We find its asynchronous nature and the low entry barrier for new developers essential to our success. We are eager to see where the language is headed and the impact it will have in its ecosystem.

and take a first-hand look at a production ready ecosystem written in JavaScript. And don't worry, we have client libraries for all popular frameworks and platforms!


The history of JavaScript has been long and full of bumps. It was proposed as a "Scheme for the web." Early on it got Java-like syntax strapped on. Its first prototype was developed in a matter of weeks. It suffered the perils of marketing and got three names in less than two years. It was then standardized and got a name that sounded like a skin disease. After three successful releases, the fourth got caught up in development hell for almost 8 years. Fingers got pointed around. Then, by the sheer success of a single feature (AJAX), the community got its act back together and development was resumed. Version 4 was scrapped and a minor revision, known by everyone as version 3.1, got renamed to version 5. Version 6 spent many years in development (again) but this time the committee succeeded, but nonetheless decided to change the name again, this time to 2015. This revision was big and took a lot of time to get implemented. But finally, new air was breathed into JavaScript. The community is as active as ever. Node.js, V8, and other projects have brought JavaScript to places it was never intended to go. Asm.js and WebAssembly are about to take it even further. And the active proposals in different stages are all making JavaScript's future as bright as ever. It's been a long road, full of bumps, and JavaScript is still one of the most successful languages ever. That's a testament in itself. Always bet on JavaScript.

"JavaScript is still one of the most successful languages ever, always bet on JavaScript"


If you missed parts 1 or 2, check them out.

With SDKs for all major client and server side platforms, you can experiment on any platform with Optimizely Full Stack.


Published at DZone with permission of Sebastián Peyrott, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}