What to Expect from JavaScript in 2016 – Language Enhancements

This is the second part of a 3 part series on what to expect from JavaScript in 2016 taken from our whitepaper, “The Future of JavaScript: 2016 and Beyond“. Today’s post focuses on the future of the JavaScript language itself. Part 1, which covered the future of JavaScript frameworks, can be found here. Part 3 covers JavaScript in environments beyond the browser and can be found here.

If you have had anything to do with software development (even non-web developer) in recent years you are likely familiar with the evolution of JavaScript and the fact that it is eating the world. I guess I’m not saying anything surprising here. And, in fact, I assume most readers have already heard, ad nauseam, the historical details about the creation, life span, and success of JavaScript.

In this article, I am not going talk about what has already happened or how we got to where we are today. Hooray, right?! This is old news. Instead, in this article I’m going to talk about the future and make a few predictions about what might happen with the JavaScript language, and the community, as we look forward into 2016.

In order to make a reasonable prediction about the future, I polled the JavaScript community with a couple of questions in order to springboard this article with more than just my own personal thoughts. What follows is a summary of the questions asked with a mixture of answers, containing both my thoughts and the thoughts of those who answered.

Many thanks to those who took the time to answer my questionnaire about the future of JavaScript. My thoughts were challenged and enlightened on several topics. You are:

@aortiz, rodneyrehm, @softwarefloyd, @sergiopereira, Kitson Kelly, Zackargyle, bahmutov, runspired, Nicholas C. Zakas, @getify, js_dev, hemanth, Brendan, Alex, Chernov, @rlsix, @briankardell, codekult, @alexbrbr, @dfkaye, @christosmatskas, @dfernandeza, github:spaced, @assaf, @BrianDukes

Which New Language Feature from 2015 Will Be Most Critical in 2016?

A native module system may be new to JavaScript, but it is neither flashy or new to programming languages. Modules, dependency management and loading are, in fact, what most developers would consider a basic requirement. In 2016, I believe modules will be deemed the most important feature added to the language.

Of course, due to its lack of native support, it might take all of 2016 for developers to actually realize it. Most of the participants in my questionnaire agreed that modules were the most critical addition, but a few did not. Promises were right behind modules as a vital addition as well. According to Diego Calderón, promises are the most vital addition to the language.

“Promises, because it is the base or the perfect pairing for several other updates: generators, async functions, observables, fetch, service worker, and so on.” – codekult

Modules might not blow your hair back like a concise usage of an arrow function or the simplicity of a returned promise, but the addition of native modules is like adding that fourth leg to a three legged chair that many non-Node developers have been sitting on in a strained and unbalanced position.

Learning the new module syntax will be easy, given that the concepts are similar to CommonJS. However, making use of JavaScript modules in production is a bit more complicated. To use ES2015 module syntax, you’ll have to use a transpiler such as Babel or a tool that uses a transpiler like webpack or systemJS.

If you think about it, the addition of a native module system brings the browser in line with Node and the possibility of using a single, native, module syntax on both the client and the server. I’m hoping to see this materialize to some degree in 2016 so that we can stop “pretending” with things like CommonJS and Browserify. Browser vendors appear to be in a holding pattern with things like HTML imports until the impact of ES2015 modules are seen on the developer community.

One day, in the future, the native JavaScript module syntax will work everywhere and the non-native module formats (e.g. commonJS, AMD, UMD) along with the non-native loaders (Browserify, webpack, systemJS) will be seen as an unnecessary complexity from the past. In 2016, this will start to materialize, but the ideal is still many years away from being fully realized. Thus, in 2016 solutions like webpack and systemJS will still be the stopgap used to deliver the ideal of tomorrow.

I believe developers that haven’t used the ES2015 module syntax yet will most likely begin to adopt it in 2016. This is mainly because the syntax is being used by several popular front-end tools (e.g Angular 2 and Aurelia) and this will have a massive trickle down effect.

What Will Be the Most Used ES2015 Feature in 2016?

Of all the features added to the language in 2015, which one will become the most used in 2016? I’ve been asking developers this question for over a year and there does not seem to be a mass consensus. Some say promises. Others say generators. Many assert a pet syntactical feature.

I predict that the most used feature from ES2015 in 2016 will be the module syntax and, close behind that, will be promises. This would make sense if the module syntax is the most important feature, as I just asserted.

Of course, some people think modules could have been left out entirely. In 2016, we’ll still see a lot of developers holding on very tightly to the CommonJS ways of doing things.

“Modules could have been left out for something simpler like CommonJS” – assaf

But, eventually, I believe most developers will accept JavaScript modules and move past CommonJS.

Will JS to JS Transpilers Thrive in 2016?

JavaScript-to-JavaScript transpilers are here to stay and it seems that almost everyone from the questionnaire unanimously agreed that Babel is the best option. In fact some, like Floyd May, were even fearful of anything that did more than Babel.

“I like transpilers to a point. I think ES6 and ES7 transpilers are great, but I get nervous when the type system is significantly different between the source language and the transpiled target language. TypeScript, for instance, really seems icky to me.” – @softwarefloyd

In 2016 I think you’ll see more and more developers choosing to transpile source code for the following reasons:

  1. They probably already have a build step in place and adding in a transpilation step is trivial in return for usage of newer ES2015 features.
  2. New tools are making use of ES2015 features (e.g. Angular 2, Aurelia, etc.) and to use these tools you’ll likely need to accept a transpilation step.
  3. Web developers will want to make use of the new language features in the browser. To do this in 2016, they will still have to transpile ES2015 source code to ES5 production code. (Keep in mind that Node developers using 5.x+ get a lot of ES2015 features without transpiling)

There does seem to be a small faction of developers who don’t want to transpile code and would prefer to wait for proper support, believing that ES5 is enough. In 2016, the nudging from tools using ES2015 and the usage of ES2015 features in npm modules should negate some of this thinking.

Will Runtimes Fully Support ES2015 in 2016?

Realistically, complete ES2015 support could take between two and three years given the module loading hurdle. However, modern browsers and Node might just reach 90% to 95% support by the end of 2016 given the rate of change in 2015.

Most of the people in the questionnaire had a similar opinion. I believe this is due to the faster than normal rate of change provided by modern browsers and transpilers supporting proposed experimental features before they land.

The thing to note here is that the most important feature from ES2015, module syntax, will likely be the feature that takes years to become widely supported due to the loader. Of course, this is the exact reason that large numbers of developers will be turning to a transpiler in 2016 using a loader polyfill.

Which Feature from ES2015 Will Developers Wish Hadn’t Been Added?

Given the gap between ES5 and ES6, it would seem the developer community generally believes that the new additions to the language were mostly all (badly) needed. The only exception here that seems contentious and, I believe, will remain contentious is the class syntax.

JavaScript does not have classes. And, it arguably doesn’t need classes. You knew that right? However, the class syntax was added in 2015 and it is essentially syntactical sugar over the top the prototype-based inheritance that has always existed.

In other words, the class syntax is mostly just short cut code. Its inclusion and purpose is to provide a simpler and clearer syntax for creating objects and dealing with their inheritance for those who want it. So, what’s the big deal? Take it or leave it, right? It benefits to those who come to JavaScript from a traditional OOP language. So, why is it contentious?

There’s a tug-of-war at work here that won’t be settled in 2016. This is because not everyone approaches the design of a program with the same principles. Those who don’t think like an “OOP” developer will continue to think this way. And those who do, will continue to think in terms of strict encapsulation and internal state. And, well, everything will be ok. Good software will still result from both camps.

In 2016, grumbles about the addition of class syntax will continue. And these anti-class developers will continue to lobby that it shouldn’t be used. But, if this is the most contentious part of the massive update in 2015, I think the outlook for 2016 is good. Mostly because I think this points to the fact that those developing the language crafted an almost perfect update. The addition of the class syntax is a principled disagreement that is larger than JavaScript itself. If this is the only issue with the update from 2015, then we are in a really good spot.

And consider that even if one can’t stand the addition of a class syntax to the language, its value as a “gateway drug” is, in my opinion, obvious. In other words, by providing class syntax, the JS hook can be set so those who abstain from classes will have a captive audience (i.e. actual users) in order to mount a case against them. But, again, the addition of it could just lead to a mass migration to JavaScript in 2016. In fact, I predict we’ll see the usage of JavaScript continue to rise in part to additions to the language like class syntax. Once JavaScript is adopted the normal debates of course will continue.

What is the Most Important ES2016 Proposal to be Finalized This Year?

Well, if you haven’t heard it won’t be Object.observe. Apparently, that proposal cooked too long and burnt itself out of existence. To date the proposals that are likely to be added to the language next are:

The first thing you should notice is that ES2016 will not bring the same scale of changes that 2015 did. In fact, from 2016 onward, TC39 is only planning on evolving the language yearly with slight changes.

Before the news that the Object.observe proposal would be withdrawn, many believed that this addition would be the most important. In 2016, I imagine this will continue to be debated to a degree. With Object.observe out of the running, the next critical proposal is the Async Functions proposal.

For the majority of developers, most of 2016 will be spent learning the additions made in 2015 and how not to get "ninja stupid" with so many changes to the language. If any time is left in the coming year, I predict that most people will be learning and using async functions and promises.

Will One JavaScript Package Manager Rise?

A topic of discussion in 2015 that will bleed over into 2016 (and likely into 2017) will be that of a single package manager for JavaScript. In some ways this is a debate over the viability of a single package manager that could service both Node developers and front-end developers. Many believe that everyone should just use npm and abandon things like Bower. I find the perspective very narrow and lacking concern for a large group of web developers who don't build complex applications.

I think this single package manager, if it's even possible, would first have to settle on a single module format for JavaScript. I'm not convinced a single package manger is ideal, but if it was, there would have to be an agreement on the syntax used to construct the modules contained in the packages. This is why many have jumped on the CommonJS and Browserify bandwagon. Of course, the native syntax is the only logical path forward. I believe the quicker we can burn the CommonJS wagon down, the faster we can get on to the native solution.

Additionally, a single package manager would have to treat both the front-end developer and the Node developer as a first class citizens. Is that even possible? By combining the needs of both into a single tool, do we not risk causing more confusion and problems than fragmentation itself?

The questions I am raising will continue to be asked and answered in different ways for much of 2016 and likely remain unresolved until the module syntax and loading gets natively implemented.

So, the question that is left is this: what should one do in 2016 while this is all in flux?

Personally, I think the path forward is to use something like systemJS and jspm.io. Why? Because systemJS is biased towards and tracking with the native module syntax and loading progress. Layer on jspm.io and you have a stop gap package manager that will allow the loading of packages from npm, GitHub, and even Bower (with a plugin).

I favor jspm.io because I don't think we know what the future holds for JavaScript package managers and jspm.io is teh most future-friendly to whatever is to come. So will npm win or will Bower win? I say, "who cares?" - just use jspm.io and pull from both if you need too. This alleviates some of the duplication that some developers have said convinced them to only use npm.

However, my opinion on this matter appears to be in the minority. A lot of people seem agree with the sentiment express by Chris T.:

"Yes. Npm has won. It's not perfect, but there's a path to get it there, and we should work on improving npm instead of starting over." - runspired

Developers are flocking to webpack and shaming developers into using npm alone. Both webpack and systemJS solve the same core problem. I'd suggest you stay clear of dogma and simply pick whichever one makes the most sense to you and then use it to write ES2015 modules.

As for using npm alone, I say do what works best for you but don't dogmatically push a subjective mantra of npm alone onto others. Many developers don't even need a package manager, they just need a simple tool to install third party tools/code/plugins.

I've found that between systemJS and jsmp.io, there is nothing lacking (except it's a stopgap) in terms of module syntax, packaging, and loading. However, some will argue that webpack does more. And it does, in fact, do more. And, if you want more, use it. For me, personally, if I need another tool to do another job, like serving and reloading my development code, I'll go get a focused tool that is not tightly-coupled to my loader/dependency manager.

What Issues Will Remain in 2016 that Future JavaScript Updates Will Need to Resolve?

It's clear that even with the major update in 2015, 2016 will continue to be a year where we fill gaps in the language. In no particular order, the unresolved topics in 2016 will be:

  • How native modules are loaded in a browser will need to be ironed out and an initial implementation will need to commence.
  • We haven't fully scratched the async itch. While, await functions will help, the journey is far from complete. Promises and eventually streams will need to be used throughout (e.g. HTTP promises). And, oh yeah, canceling a promise - that might be a good idea.
  • Concurrency and parallelism (i.e. parallel processing) in JavaScript will need to be addressed and Web Workers will have to step up or step aside.
  • The should we or shouldn't we debate about immutable native objects will hopefully conclude.
  • Lastly, pay off whoever we need to so that all browser manufactures to treat the JavaScript runtimes in a mobile browser with the same status as a regular desktop browser.

As you can see we have more work to get done in 2016.

The last thing I'd like to note is that, in 2016, we might also start to experience feature overload that could result in significantly different styles used for constructing JavaScript applications. Thus, we'll need to update our thinking and education on several variations of styles that facilitate best practices.

I'm not alone in this observation, Brendan shares the same concern:

"My concern is that there are now even more ways of doing things, so it is not as easy to squint at some code and know the layout and style." - Brendan

With more ways of doing things correctly, it won't be as easy for JavaScript developers to jump from project to project. In 2016, we'll have to address this potential issue.

Will JavaScript Continue to Rise?

I don't have and I can't find a persuasive reason or opinion that would lead me to believe that JavaScript's popularity and usage will dwindle in 2016. It would seem that in terms of the immediate future, the consensus from the questionnaire concludes that JavaScript will remain on the center stage and in the spotlight in 2016. Beyond 2016 some, like Nicholas C. Zakas, were willing to forecast a potential decline.

"I think WebAssembly, once available in all browsers, will start freeing people up to think about alternatives to JavaScript. The ability to compile down to WebAssembly and deliver that to the browser means we'll see people experimenting with Python, Java, Ruby, and more, being written directly for the browser. Once that happens, all bets are off on the future of JavaScript." - Nicholas C. Zakas

The reality is that most people believe JavaScript will continue its dominating march towards becoming the most used programming language in the world. I should, however, note that, as Zakas mentions, that there are whispers that web assembly could potentially cause a major disruption. Keep an eye on this!

Most believe as I do that, in 2016, JavaScript will further its ubiquitousness by replacing more and more languages that in the past have been used to create native applications. My prediction is developers will turn to solutions like NativeScript, React Native, and Electron to create native applications precisely because they want to write JavaScript alone.

JavaScript is the language of the web. What if in 2016 JavaScript became the language of native applications? If you find that to be an impossibility I'd suggest you start wrapping your head around things like NativeScript.