ES6 and other extensions to JavaScript are exciting, but they have the problem that they are not backwards compatible. How can we deal with that issue? Or is it really one?
6. Locking people out is
not an option.
The success of
JavaScript was and is
based on its
availability on the web
across browsers.
7. The problem is that
once something is on
the web, it is
impossible to remove
and we can’t force
everyone to stay up to
date.
8. 'use strict';
strict mode is a way to opt in to a restricted variant of
JavaScript. Strict mode isn't just a subset: it
intentionally has different semantics from normal
code.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode/Transitioning_to_strict_mode
12. 'use the force';
A version that allows for smooth and exciting 60fps
animations by moving things magically around.
Canvas only.
13. 'use paper and material provided';
A version for Polymer
14. 'use emity';
An Apple specific version with libraries to create
glitchy graphical effects and a connection testing
feature that randomly disconnects WiFi
15. 'use to excite VCs';
A specialist version dedicated to IOT and VR
16. 'use this, bro!';
A version that makes omitting semicolons mandatory,
automatically moves opening braces to the next line
and commas to the start of the next line. Limited for
use in the Silicon Valley only (geofenced)
Today I want to talk about a challenge we are facing: we want to advance JavaScript, but it seems we can not do so without breaking the web.
JavaScript is a massive success when it comes to developer adoption and distribution. It is found everywhere these days. Whilst in the beginning it was only used to add flashy bits to web sites and prevent a page reload, you now can find it in browsers, hardware, servers and many other places. The reason is its forgiving nature.
This, of course is also one of its main issues. To someone coming from stricter development environments and languages JavaScript can look flimsy and badly designed and it is easy to say it is not up to the job of large applications. The same is said about PHP all the time. When a language is flexible enough to be implemented in various environments, it is easy to discredit it compared to “proper” languages.
Which, to me, is a “No shit, Sherlock” moment. You can not compare a language that wasn’t designed for a certain task but gets used because of its appeal to one that was designed for the task. JavaScript’s big benefit is its flexibility and that it allows anyone to take part. The low learning curve is what made it what it is today.
That said, we do use JavaScript for ridiculously complex things these days. Which means we should have a go at improving the language in terms of memory allocation, security and readability for people not versed in it.
The problem is that we need to do this without breaking what is already out there, and without making people dependent on one environment. JavaScript is a success because it is independent of browser and development stack.
We will never have a world where every user has one browser or an evergreen environment. Once we put something out on the web, it is there and the more it gets distributed, the harder it is to remove. Saying all your users need a certain browser is a silly argument. It is not using the web to its strengths.
One thing we started to do when moving JavaScript to the server and in other environments that need more control is to introduce strict mode. This one disallows for some of the laxities of JavaScript and results in more predictable code. The way to make that work is by simply adding ‘use strict’ to your code – either for a whole document, or only for one method or function in it.
There is a massive movement now to innovate on top of JavaScript. And every creator of browsers, JavaScript engines or any other consumer of JS has great ideas.
Google, for example seems to be working on SoundScript and SaneScript.
The work in progress way to trigger SaneScript is to create an opt-in called “use sanity”. But why stop there?
In the past, innovating in the browser wasn’t hard. All we need to do is to test for the support of new objects or methods and we’re safe. Browsers that don’t support what we have will not get it and we treat it as an enhancement.
Using a few tests, we can block out the browsers that don’t understand what we are trying to achieve.
This technique is upgradeable, as this example shows.
You can even nest that and create various versions of support. All without having to worry about backwards compatibility and non-supporting environments will never get bothered with technology they don’t understand.
Almost. The issue with us innovating JS right now is that we mess around with its syntax. And that’s something you can’t really test for. JavaScript is not forgiving like HTML or CSS – when there is a syntax error, the JS engine gives up trying to compute the rest of our scripts.
Template strings for example allow us to use multi-line strings and in-string replacement without concatenation. This makes our markup generation much terser and cleaner and less error prone. Of course, the even better way for this would be templates in HTML, but that’s another presentation.
One of the “err, what?” moments of JavaScript for people not familiar with the language is the need for a lot of anonymous functions and scoping. This can make code look bloated and unoptimised.
Arrow functions work around that issue and with their more lexical nature avoids having to keep scope in a that=this hack.
The issue is though, that to date, the support for ES6 isn’t that good. Red in this support grid means not supported. And it would be naïve to expect this to change any time soon and all the browsers on all the platforms to get an upgrade to support ES6.
A lot of the changes we do to the language now are needed for porting products and moving JavaScript to the larger world of large projects. Therefore it would be dangerous to let browser limitations stop us.
It makes more sense to have a conversion step. TypeScript was a good start for this.
Babel allows us to write ES6 and get it converted into ES5 JavaScript for browsers now. You even have a live console to see the code it generates, which is great for learning it.
Back in the long, long ago, IE had its own JavaScript version called Jscript. By adding a type of text/jscript to the script block you could use this without bothering other browsers. As browsers don’t render script nodes of a type they don’t understand, we also used this for HTML templating before <template>
A type of es6 would allow browsers that don’t understand it to skip and others to execute.