@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
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.
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.
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.
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
“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:
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.
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.
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.
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.
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.
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).
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.
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:
awaitfunctions 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.
As you can see we have more work to get done in 2016.
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