Jared the Nerd

Jared the Nerd

CTO, IT Advisor, Software Engineer, Public Speaker, Traveler, and 100% Nerd

Where The Web Is Going In 2016

The web is a strange place governed by multiple standards that together define how things work. Alongside the committees, browser vendors are both innovating to win new users and collaborating to push these standards forward.

There is no traditional vendor-driven versioning here. There are web standards like ECMAScript 2015 but they aren’t supported the same across browsers. Features from the next version of the standard (Array.prototype.include from ES2016) get implemented before features from the previous (default function parameters). Sometimes, there are even two standards for the same thing like HTML5 vs HTML5

At any given time, it’s impossible to say what is and what is not in the current version of the web.

This post aims to talk about the stuff that should be on your radar that you may get to use soon. We’ll talk about:

_ This post is also available on the Telerik Developer Network and you can listen to my related podcast interview on SoundCloud._

ECMAScript 2015 - Modules

ECMAScript 2015 may be last year’s huge release (after 15 years of planning), and it’s not fully implemented yet. To me, the big thing missing is module support.

If you look at compatibility table, you won’t even see modules listed. According to discussions on GitHub, this is because they really don’t exist yet in any meaningful way.

One key thing that has to exist for modules to be useful is a way to load them. This wasn’t resolved in ECMAScript 2015, but it is being worked on by WHATWG. This new standard is either under consideration, or in development, by all of the major browser vendors. This may not ship in 2016 across platforms, but let’s hope!

Bonus note: I love the fact that the pre-processor for spec documents is called Bikeshed. I didn’t realize that until researching for this post.

ECMAScript 2016

With ECMAScript 2016, TC39 (the standards committee behind ES) has shifted from a model of delivering big releases “when they’re ready”, to delivering a release each year with whatever is finished in time. This is often known as the “train model”. Specifically, any TC39 proposal in stage 4 on their cutoff date goes into the next release. You can read more about the process here.

For ECMAScript 2016, only two features made it:

Exponentiation Operator **

The exponentiation operator ** is shorthand for Math.pow. You use it to raise one number to the power of another.

// New way
2**3 === 8; // true

// Old way
Math.pow(2,3) === 8 // true;

Yeah, that’s what it does. You can find more details here, if you insist.

These are available as of last week in Edge’s Insider build and will be out in Chrome 52 as well.


This one isn’t much more complex, but it has an interesting story. Here is the syntax.

var myArray = [1, 2, 3, 4];

myArray.includes(3); // true

myArray.includes(5); // false

This is just an easy way to check whether an item is in an array or not. It has an optional index parameter if you want to start searching from somewhere other than the beginning.

This replaces the ugly indexOf way of checking:

var myArray = [1, 2, 3, 4];

myArray.indexOf(3) !== -1; // true

myArray.indexOf(5) !== -1; // false

This is already supported in Chrome and Firefox and is in the Edge Insider build as well.

It’s All In The Name

The interesting story here is how this got named. “Includes” was originally going to be named “contains”. This name was suggested by volunteers to TC39 and generally well liked. It also matches many other languages.

Unfortunately, it breaks the web. In a long thread that I highly recommend you read, Jason Orendorff (a Mozilla engineer) said this:

Either way, you're telling me I should ship a browser that chokes on thousands of web sites that work fine today. That would be bad for our users, so I'm not planning on doing that.

The 6.5% of existing web sites using JS libraries that use MooTools have not been “already patched”. Patching 3.5 million web sites is not a “small fix” in any relevant sense. It simply will not be done thoroughly or soon.

You see, unfortunately for everyone, Array.prototype.contains was used by Mootools in a way that caused this to be a breaking change. If you don’t remember Mootools, at one point it was a pretty popular framework. It’s not heavily used now, but a ton of sites on the web were built with it and have used it for years without active maintenance. Abandoned but valuable. This would break them overnight.

Patching 3.5 million web sites is not a "small fix"

The standards committee decided to prioritize a functional web over the perfect syntax, and instead changed “contains” to “includes” to preserve functionality that everyone expected to just keep working. While I think this was the right decision, reasonable people disagree. The web is an odd place where breaking changes can’t just be hidden behind a version.

But enough about that. Let’s talk about some happier stuff.

Fetch API

The Fetch API is a standard put out by WHATWG and it removes your last excuse for using jQuery. The new Fetch protocol creates a standard for all the requests a browser makes: images, scripts, JSON, etc. It also defines an API that you can use to call RESTful APIs for data.

The fetch() method takes a URI and returns a promise that you can then chain new behavior onto. It’s pretty awesome. It looks like this:

var myPromise = fetch("http://someurl/stuff")
    .then(function() { // do stuff })
    .catch(function() { // handle error });

Fetch is supported by Chrome and Firefox and is in the next release of Edge. More details can be found on CanIUse which you should bookmark.

But wait, there’s more! Fetch is missing a key component right now which is the ability to cancel a request. This isn’t a Fetch issue though. Currently in JavaScript, there is no way to cancel a promise. They either finish or don’t. Thankfully, a feature has been proposed to TC39 to support Cancelable Promises. This should allow the ability to cancel requests with Fetch.

Service Workers

Another feature that should be on your radar is Service Workers. Service Workers come from a W3C spec and allow you to push your network requests to a background process. They give you the ability to cache network requests or otherwise make intelligent choices about what to load outside the main execution path.

They are under development in Edge, and have partial support in Chrome and Firefox.


Finally, and I’ll be brief because this is a long post, HTTP/2 should be on your radar. HTTP/2 is based on Google’s SPDY standard and allows all sorts of cool things in HTTP requests. There are two big features I’m excited about:

You can find out a lot more about HTTP/2 here.

Final Thoughts

If you’re still reading this post, thanks! Even with the smaller list of features included in ECMAScript 2016, this year is turning out to be another exciting one for web developers. Happy coding!