For a long time the web development process has been able to be compilation free. Write your code in any editor and refresh in the browser was all you needed. Of course you could always burden yourself with compilation steps during development. In some ways you have to, though, like for linting and minification when producing a distribution build. But it wasn’t required to write JavaScript.
Note: A client of mine asked me to write blog posts for them. You can find the original post on their website, linden-it.com. You can find a copy below for posterity (was added here at least a month later).Recently something changed. JavaScript changed. Not only was a new version released (ES6 / ES2015) but more importantly for the first time since ES3 (that would be ES1999) there have been many and significant syntactical changes to the language. Yes, ES5 (“ES2009”) had syntactical changes but they were relatively small. My favorite is probably the trailing comma and that probably says enough. Any of the changes were really just small sugar cubes which would be usable as soon as IE8 was phased out. Or IE9. Or… well IE is phased out in general so we’re probably good now. That only took like 6 years. At this point reserved words as property names and trailing comma’s are pretty safe to use. And nobody uses getters, setters, “elided” comma’s that aren’t trailing, or “line continuations”, anyways. Hurray. But did we miss them while they were unavailable? Mehhh, not really.
Enter ES6. It introduces so many new things that I won’t even start to summarize them. More importantly, YOU WILL WANT TO USE THEM. The new syntax concerns important new features to the language. Of course browsers will still take a long time to implement these new features and it will take an even longer time before “the network”, aka the internet, propagates these new browsers far enough that the syntax becomes usable. Mobiles don’t help at all in that regard. Some things never change. But unlike the ES3 era, this does bring us to the case in point: the gap must be bridged with a compiler.
Big deal? Yeah, I think so, because it removes the main reason why you’re not using a different language to begin with. You can develop your web apps in any language you desire. This isn’t anything new. That cross compiling (“transpiling”) concept has been evolving on the web for about five years now. And it’s not a new concept either, don’t get me wrong, but on the web it’s only been evolving the last few years. The game changer now is that since you’ll need to compile your ES6 to ES5, anyways, what’s stopping you from using any other language? ES5 is “Turing Complete”. That means it can do anything that any other language that is also Turing Complete can do. Meaning you could write your business logic in C, Perl, Java, or Forth, and run it in the browser. Bonus points for using source maps so you can debug your original code while the browser runs it as ES5, wowzers.
It’s not _that_ cut and dried, though. Yes you can cross-compile any other language to ES5 but some languages will require a bunch of libraries to do exactly whatever the hell it is they do. Forth, for example, will require some kind of stack management. C will require pointer maintenance. And Java will require super long identifier support (hur hur). It really depends on the language and some languages are more suited to compile to ES5 than others. But that’s besides the point, they can so why wouldn’t you if you feel more comfortable in another language? Why speak English if your native language is Flemish and there’s a perfect translator available for it?
Well, there’s performance. But you weren’t caring about performance when you were considering to write ES6. Most of the new features are horribly slow and will remain so for a long time. It took browsers some fifteen years to get ES5 to the performance levels of today. You think ES6 will match that performance in matter of months? Nope nope nope. So with performance out of the window there’s only the principle of language left.
I would argue that it really doesn’t matter anymore. The current development pipeline requires so many build steps, anyways, that the actual language to develop in becomes a second class citizen. Yes, in the long run ES6 will become viable out-of-the-box but then there’s ES7, and ES8, and ES2025. It’s ironic, but I think in a way this new ES release cycle is cannibalizing the language. And I’m okay with that. I’ve seen it coming for a while and I think this is the pivotal moment. ES5 will become some kind of “universal web assembly”, not to be confused with actual web assembly, which may dumb down to something like “asm.js”, also not to be confused with web assembly. Then later, it may slowly be migrated to actual web assembly, which looks pretty cool but is pretty cutting edge for the time being.
“There is so much in this world that I do not understand. See that machine? It has something to do with recycling our water supply. I have absolutely no idea how it works. But I do understand the reason for it to work.” — Councilor Harmann. I may not be The One, but I can be the guy that builds water supply recycling machines. And that’s okay too.