JS.next: A Manager's Guide

Chapter 5. Watching for ES7

As of March 2013, the list of possible features for ES6 has been frozen. Only the proposals that are already on the list may be included in ES6. Any additional proposed features to ECMAScript will have to wait in hopes of being included in ES7. Potential features for ES7 have already begun to appear.

Note

JS.next refers to the next version of the JS API. Currently JS.next refers to ES6. Once the ES6 release is live, JS.next will refer to the ES7 release. JS.next will always refer to next update to the language.

Several of the potential features have the possibility of really changing the way we think about app development in JavaScript. Taking an initial look at those features now can give us some time to digest them while the ES7 release is being prepared over the next few years.

Everything in this section is partially speculation. None of the proposed features mentioned below have been officially accepted into the final ES7 release. Additionally, only Object.observe has been officially approved as a Harmony proposal.

Object.observe

A popular feature in modern frontend JavaScript frameworks is two-way databinding. Having two-way databinding makes life easier on your developers. It allows them to focus on writing new code rather than worry about keeping all the data in sync. Object.observe makes two-way databinding easier than ever before.

On any given JavaScript-assembled web page, the values on the page represent some JavaScript variable in your code. Keeping those two values (the page value and your variable’s value) in sync is important. Any time your users update the values on the page, your variables are updated as well. Additionally, if you change the value of your variables, you want the page to be updated with your changes. That is two-way databinding in a nutshell.

We have already seen a handful of frameworks implement Object.observe, each reporting huge performance increases. In late 2012, Chromium, the open source browser project on which Google Chrome is based, released Object.observe functionality in their Canary channel. A few of the modern frameworks then updated their two-way databinding to use Object.observe. Those frameworks saw their performance increase. The AngularJS team reported that their code ran 20-40 times faster than it had previously. This means that once Object.observe is released into the Web, most libraries and frameworks that switch to it will see increased efficiency and optimization.

Multi-Threading

One of the best things about JavaScript is that it runs in a single-threaded nature. Because you can write code without worrying about multiple threads, application development tends to be easier. While this is a huge plus, it also present limitations. For example, if any of your JavaScript code runs too long, your entire app will appear to be frozen. Things like intense graphics can easily bring your code to a halt. If JavaScript apps had a good option for running code in parallel, on different threads, it would be a much more powerful language.

Intel Labs has a research project called RiverTrail. Together with Mozilla, Intel aims to allow JavaScript applications to run using multiple threads. This means that your browser would be able to utilize all your computer’s processors. As shown in their demos, RiverTrail allows things like intense graphics processing to happen right inside the browser.

With any luck, the RiverTrail project will yield some conclusions of sorts that can be integrated into the ECMAScript specification and then implemented in JavaScript. Having the ability to easily program in parallel would be a great addition to the language. Maybe your average JavaScript developer wouldn’t use this type of low-level functionality, but your framework developers would. This means that once you implement the frameworks, they will take care of the lower-level stuff like improved optimization.

Traits

In many object-oriented languages, your objects share functionality by inheriting it from parent classes. One of the alternatives to class-based inheritance is Traits. By using Traits, you define the functionality to be shared as a Trait and then add the desired traits onto your object. By adding a trait to your object, your object will absorb the functionality of your defined Trait.

Implementing traits provides another powerful way of sharing functionality. It can also reduce the risk of over-architecting traditional class-based inheritance models.

Additional Potential Proposals

Here is a list of additional items to watch for in ES7. I am sure this list will grow before the ES7 approval process is over.

• Precise Math
• Improved Garbage Collection
• Cross-site Security Enhancements
• Typed, Low-level JavaScript
• Internationalization Support
• Digital Electronic Rights
• Additional Data Structures

Invite your teams to keep their ears to the ground, listening for more cutting-edge features that may appear in JavaScript.

Acknowledgements

Writing this book was extremely fun and proved to be a helpful exercise. Researching and describing each topic was a process that lasted about two-and-a-half months. When Simon (@simonstl) and Mike (@mikeloukides) approached me about the idea, I wasn’t sure that I would be able to deliver what they were asking for. Their vision was to explain ECMAScript 6 in a way that non-developers would understand it. Additionally, they wanted to help everyone understand the importance of adopting the new syntax into their current projects, as opposed to waiting years for certain parts of the Web to catch up. Much like steering a donkey with a carrot on a stick, Simon and Mike helped steer my efforts. Without them, much of what was written wouldn’t be. I appreciate all of their mentoring and guidance.

Once I finally understood the direction in which we needed to go, I simply needed time. A special thanks goes to my wonderfully understanding wife (Sarai) and to my three children (Naomi, Joceline, and Ryan). Family life is already a lot of work. Having a husband/dad that is busy writing a book only adds to it. Each of them helped me race to get this finished in time for FluentConf 2013.

Everyone made a very serious effort to disguise how sleep deprived I was when finishing this. A special thanks to the inventors/makers/distributors of Diet Mountain Dew. While the ideas are my own, many of the words used to spell out my ideas were heavily fueled by Diet Dew fumes.

To my friends and colleagues who helped out, you know who you are, thank you! Chad “the knife” (@chadmaughan) and Tom (@tvalletta), thank you for mentoring me and helping my solidify some of the ideas expressed here. Mom (@marlli53), Neal (@NealMidgley), Steveo (@steveolyo), Ted “the Head” (@jsbalrog), and Tayler (@tayler). These are my people who read the pages when they were fresh off the press. Each of them took part in ensuring the quality of the text.

And a very special thanks to each of the members of the TC39. This book is only possible because of their efforts. While the JavaScript community eagerly await the ES6 updates, the members of the TC39 remain focused, as they continue their daily effort of solidifying the ES6 specification. I feel lucky that I have been able to work directly with a handful of them. While I want to thank each of them, the following are the members who have directly had a hand in helping my efforts: Dave Herman (@littlecalculist), Allen Wirfs-Brock (@awbjs), Brendan Eich (@BrendanEich), Rafael Weinstein (@rzweinstein), and Alex Russell (@slightlylate). Note to whomever is running the @FakeAlexRussell account: you’re brilliant!