This comic doesn't do anything new.
ES2015 Compatibility chart from kangax
Currently, Firefox 50 is supporting 92% of the ES2015 features, Chrome 55+ and Node 6.5+ are at 97%, while Safari 10 and iOS 10 are at 100%! The only feature holding back the 97%-ers is the optimisation feature of ES2015, proper tail calls. This is great news for developers who want to use these features without transpilers.
Although there are some features of ES2016+ already being supported (Firefox 52+ is already at 91%) there is still a lot of red.
ES2016+ Compatibility chart from kangax
So far though, this feature list is shorter than ES2015 and the only "large feature" is async functions (which is already supported on Firefox 52+ and Chrome 55+). With the success of the browser support for ES2015 it looks very likely that we will again get close to 100% compatibility with the main browsers for the ES2016+ features.
Last year we proclaimed that ES6 modules would be the most important addition and that still seems to be ringing true. As predicted, a lot of developers have taken advantage of the ES6 module syntax in their code thanks to transpilers like Babel or Traceur. It's hard to gather numbers to back this up but if you read all the articles on the "top" or "favorite" new features from ES2015, modules is almost always listed.
We were hoping for a native module system in 2016 so that commonJS, AMD, UMD, and non-native loaders like browserify, webpack and systemJS were no longer necessary. So far, it looks like we're going to have to keep waiting because tackling the loading process for modules is proving to be quite a feat. There does seem to be a lot interest and work going into this feature though. There is a great recap from James Snell about a TC-39 meeting he attended to get info on the feature.
"There is a proposal being put before TC-39 that would introduce a new import() function. > >The import() function...is processed at evaluation. It also imports an ESM (or CommonJS module) but, like the require() method in Node.js currently, operates completely during evaluation. Unlike require(), however, import() returns a Promise, allowing (but not requiring) the loading of the underlying module to be performed fully asynchronously."
This would also allow us to make calls like await import('foo'). To be clear, this may still be a long way off but it is currently in stage 3! Here's a breakdown of their process to explain what 'stage 3' actually means: TC-39 Process. Based on the amount of interest in this feature, I have faith that it will get released in 2017.
The brave ECMA TC-39 https://github.com/tc39
Following ES6 modules, we predicted that the other stand-out feature of the year would be Promises. No one likes callback hell or the pyramid of doom, so native promises was a very welcomed feature. Developers have covered Promises a lot in posts and tutorials, likely because they seem complex when you begin to use them.
As developers get used to the new syntax changes and the benefits they yield, I think we will see more openness to adding new features. I'm seeing more and more tutorials pop up incorporating the ES2015 syntax without mention or explanation of ES2015. This makes me believe that it is becoming the new normal and that this trend will continue into 2017.
There were many discussions and strongly-held views about the inclusion of ES2015 Classes. Thankfully, people have made their points and the debate has seemed to die down.
As predicted, people stay steadfast in their preference to Object-Oriented Programming, Functional Programming, etc. The biggest point made about ES6 Classes was to specify that they were mostly syntactical sugar for prototypes and not to be confused with traditional classes like those from Java.
Last year we decided the proposals likely to be added to the language were Exponential Operator, Array.protoype.inlcludes, SIMD.JS - SIMD APIs + polyfill and Async Functions. Let's see how far we've come with each of these Additional Features.
Array.prototype.includes - this feature is still considered a ES2016 feature and is actually supported on Edge 14, Firefox 45+, Chrome 55+, Safari 10, Node 6.5+ and iOS 10.
SIMD - is listed as a "Candidate" at stage 3 but will be a large feature.
Async Functions - are the only "large" feature on the list for ES2017 features and are already supported by Firefox 52+ and chrome 55+.
Going into 2016 we suggested using systemJS and jspm.io. This is still a solid option. Just in 2016 systemjs has been downloaded over 4.4 million times, ~520,000 in the past month.
systemJS weekly npm downloads from January 2016 to December from https://npm-stat.com/
jspm is coming in at ~2.2 million for the year and ~200,000 for the month.
jspm's weekly npm downloads from January 2016 to December from https://npm-stat.com/
It seemed that people were leaning towards making npm the go-to package manager for both front and back-end. This still seems to be the case, especially with npm being paired with webpack and browserify.
The npm registry is still at the top, after all it provides access to over 300,000 packages and there are more than 4 million people using the registry. There is an advantage to using the same package manager if you are using Node.js as your backend.
Looking back on last year's predictions, we did not take into account the option of a new package manager coming onto the scene. Yet, that's exactly what happened when Facebook introduced yarn in October.
Facebook had been using npm but once their codebase and engineering team grew they started running into problems and decided to create their own package manager. yarn gained a lot of interest right when it came out thanks to the big names involoved: Google & Facebook. Based on the npm download stats, yarn took a dip while the US was on Thanksgiving break and hasn't surpassed it's ~160,000 download mark from November. We'll have to keep an eye on yarn but so far its November downloads (~538,000) aren't even coming close to npm's (~3.6 million).
yarn's weekly npm downloads from October to December from https://npm-stat.com/
npm's weekly npm downloads from October to December from https://npm-stat.com/
To be clear, yarn is not a replacement for npm. It is a CLI client that fetches the modules from the npm registry. I would immediately assume that we would not see another package manager in 2017 but Facebook may have opened the field up for more contenders. Even with snafus like the left-pad situation, npm feels very reliable.
Slant.co created a survey for their users to be able to rate and explain the pros and cons of different front-end package managers.
A snippet of the Slant survey results
So far the top 3 products are npm + Browserify with a total of 51 upvotes and 3 downvotes, Bower with 30 upvotes and 5 downvotes and JSPM with 15 upvotes and 2 downvotes. There are only 169 votes, this is a small pool of developers but it is still interesting feedback and should grow more over time.
We touched on a few key issues that we believed needed to be resolved in 2016, here's the update on each of those.
As we touched on a bit before, this is still a work in progress. The good news is that this is something the technical committee is working on. The implementation has not happened but it seems that it is on track for 2017.
Promises are supported on all major browsers and async functions are set to be a 2017 feature.
The TC39 are considering multithreading but it is hard to say when that will start making its way through the pipeline. There is a proposal for parallelism with web workers, running scripts in background threads. It is a very complicated issue to work through but it would increase performance using multicore processors.
I'm not hearing much on this conversation presently but it seems to boil down to what programming paradigm you subscribe to. If you are truly using functional programming you never attempt to mutate state. Therefore, it should not matter if the state is technically mutable. If you are using object-oriented programming, immutability is an odd fit because immutability is technically about data-structures. That being said, there are ways to make it work, if you're up for it. Here is a thorough article discussing just that.
Unfortunately, looking back at the ECMA Compatibility Table, it seems no one has been paid off. iOS has 100% compatibility but Android seems to be falling behind at mere 25% for Android 5.1. With Google's recent push for Progressive Web Apps and focus on cell phone and tablet usage, I believe all mobile browsers will have to catch up fast. Maybe then, the only ones getting a payoff will be us, the users!
The results for ES2015 compatibility on mobile.
How could you not want to search for these amazing creatures?!
It looks like a great year for WebAssembly
Other articles in this series:
Subscribe to be the first to get our expert-written articles and tutorials for developers!