Start Your Transpilers

Friday, May 1, 2015

Early last year I began to take ECMAScript 2015 seriously and leaned towards using the new language features of JavaScript sooner rather than later. The tools needed to make the new language work in existing browsers already existed. Some people thought I was crazy.

This year the ES2015 / ES6 specification is a final draft stage and is only waiting for a final blessing. Iā€™m even more convinced that the language is ready to use. In fact, why stop with ES 2015? ES7 already has some firm specs and the tools are even better.

Consider these points:

1. The technical committee responsible for ECMAScript specifications has committed to delivering a new version of the language every year.  

2. The best way to keep up with the challenges presented by contemporary applications is to tackle those challenges using the best features of a language. ES6 is considerably better than ES5 and dramatically changes how to build and organize abstractions. ES7 should include better support for metaprogramming and async work.

3. Next generation frameworks, like Aurelia, are already taking advantage of ES7 features. It is natural for people who build frameworks like to stay on the cutting edge and use the best features a language has to offer.

4. Browsers will perpetually be behind the curve going forward, but tools and polyfills will make most new language features work. There will always be exceptions which require native support from the JavaScript VM, like collections using weak references, but almost everything in ES2015 can be polyfilled or transformed into a working syntax.

I still see some resistance to using new tools in a JavaScript build process, even though most environments have been using tools to minify and concat JavaScript for years. It is time to rethink any resistance to source code transformations. For the above reasons, I think everyone should start working with a transpiler (ES* ā€“> ES5) or a compiler (TypeScript ā€“> ES5) without further ado.


Comments
gravatar KevinM Monday, May 4, 2015
Agree 100%, with a small caveat. A tool or polyfill may enable a feature or offer api compatibility, but won't necessarily ensure run-time performance acceptable in all cases, no?
Tuesday, May 5, 2015
Hi, here are my two cents (I already shared with *my* difficulties in another post ) in another post. I think that the main issue is the fact that things are advancing way too fast for most devs. 1. until you learn and adopt some new tool or library - there is something newer to learn. you just finished a few month ago the angular tutorial, and here we began a new serious about aurelia. so if we learned and developed with angular 1.X, and need to decide about a new system architecture, shouldn't we be conservative and stay with the angular 1.X (it makes me laugh just think about angular as conservative). 2. The knowledge base in the internet can't be rich enough with all those changes and alternatives. try google "jspm with visual studio". you will get first a link to odetocode, and two extra links to stackoverflow referencing odetocode I guess our world is splitting to two: Large and conservative organizations vs young and dynamic start ups.
Tuesday, May 5, 2015
Angular's initial release was back in 2009 so the 1.x line is not exactly new.
gravatar Scott Tuesday, May 5, 2015
@KveinM: Very true, most polyfills can't match the performance of native support.
gravatar Scott Tuesday, May 5, 2015
@Anonymous: Angular 1 is ancient, based on ES5, and no transformation is required to use it in a browser. The best frameworks coming out this year will be based on ES6+.
Wednesday, May 6, 2015
Never said angular 1 is new. but, the big rise of angular was in 2013/2014, which demonstrates my point. there is a gap between the time for a new technology to show, until it is being widely used exactly because of the reasons I mentioned (and more....) by the way, marius shultz just published a post with the same conclusions as you so maybe it is all just me. https://blog.mariusschulz.com/2015/05/04/the-era-of-transpilers
Comments are closed.

My Pluralsight Courses

K.Scott Allen OdeToCode by K. Scott Allen
What JavaScript Developers Should Know About ECMAScript 2015
The Podcast!