A World of Javascript Transpilers
I recently gave a presentation on JavaScript Transpilers at the Flatiron School with Dison Ruan, and I believe it’s such an important and compelling topic for just about anybody who uses software that it makes a lot of sense to write this accompanying article. I’ll split it into the same four sections that we did the presentation:
- Why JavaScript
- The Babel Transpiler
- The World of Transpilers
- The Future of JavaScript
So for a little background:
Why JavaScript?
JavaScript is a language created in ten days by Brendan Eich (who later ascended to hacker-God status and founded Mozilla) while he was at Netscape Navigator in 1995.
Remember Netscape Navigator? Back then the net was just comprised of static HTML documents: once a webpage finished loading in your browser, that was how it was going to look until you navigated to a new page. Because that is exactly as boring and inefficient as it sounds, Netscape wanted to add dynamic elements to pages, so that they could change after they were loaded and tailor their data-driven output to the input of the user. In order to do this, they had to create a language that could be transmitted in an HTTP response and build interpretation of that language into their browser so that it could be used for client-side scripting. So Brendan Eich built JS in ten days.
Any application that can be written in JavaScript, will eventually be written in JavaScript
Since then, JS has evolved into the most widely used programming platform in the world. I use the word ‘platform’ here because hardly anyone actually programs in base JavaScript.
It’s a much derided language, as you can readily get a sense of by simply googling “hate Javacript”. JavaScript has weak typing, strange equality and type coercion, and generally just has some very strange and frustrating quirks.
But this frustration and derision with plain ‘vanilla’ JavaScript is a piece of the reason programmers have created so many other ways of writing and adapting the language.
This is a big part of the ‘Why’ that we’re getting to.
Another big part of the ‘Why’ is the standardization of JS. In 1996, not long after the original JS language was rolled out, the language was delivered to Ecma International (European Computer Manufacturer’s Association) amid squabbles between Microsoft and Netscape about the future of client-side scripted web browsing. Microsoft even released a language called JScript that year to prevent trademark infringment. Standardization of the language would help it to become more broadly and more easily used, and the first iteration of ECMAScript was released in 1997. Brendan Eich is known to have likened the name to that of a skin disease.
ECMAScript’s standardization has allowed it to function as the primary form of client-side logic for the last 20 years. And it has developed well beyond scripting capabilities, into a language with functional and object oriented capabilities.
JavaScript’s pervasive use has led to the idea that any change made in the language should be well-designed and should not interfere with the any backwards compatibility. This leads us to the primary usage of what is likely its most widely used transpiler, Babel.js.
In the Book of Genesis, the Tower of Babel was a structure built by a united humanity after the Great Flood in order to ascend to heaven. God saw this and decided to diversify the languages of the united people so that they could no longer communicate with each other, and scattered them across the Earth.
Aptly named, Babel is a platform that translates many of the extended language functionalities into ES5, which is a version of ECMAScript that is standard on all modern browsers. This makes Babel a launchpad for many of the slick and shiny JavaScript platforms out there because it allows us to extend the functionality of JavaScript while maintaining its backwards-compatibility. In other words, it lets you build out JavaScript without breaking the web!
For example, Babel is an integral part of the React build. In React, when we use JSX to build out the virtual DOM elements in psuedo-HTML, we are writing in a language that Babel is built to understand. In spinning up a build, we are using Babel to translate the JSX, as well as the rest of the JavaScript in React, into a single ES5 file. Ever looked at the static .js file of an app you’ve spun up from React and noticed that it’s literally thousands of lines longer than your original project files? Yep, that’s Babel. In fact, Babel has its own preset specifically for React, among others:
That’s cool, but how does Babel work?
Babel uses what’s called an Abstract Syntax Tree (AST) in order to execute all of its translations. In three distinct steps, it breaks down all of the syntactical input:
- Parse: takes in code and outputs an AST
- Transform: takes in an AST and traverses it, adding, updating, and removing nodes as it does so.
- Generate: takes in the modified AST and joins it back into a string of syntax, also creating a source map
The Abstract Syntax Tree allows for this to take place because it breaks down code and organizes it with all of its metadata in a hierarchical tree.
For example, these two lines of code:
Result in the following Abstract Syntax Tree:
There is a cool webapp that allows you to see how your JS code breaks down into an AST at astexplorer.net!
Babel is then able to take this tree, translate it based on a preset (e.g. React, Flow, ES2015, ES2016, ES2017, etc.), and generate the ES5 syntax needed to run in the browser.
Presets allow you to define which language you are translating from and are configured via your .babelrc file, or alternatively in your package.json. However, you are not limited to the official presets that are available, and have the ability to create your own plugins to hone the way in which Babel parses, transforms, and generates your code. This allows for custom architectures and syntax that is designed to your specific needs! The article that the above AST illustrations are from elaborates on the ways in which you can use Babel plugins to your advantage. You can find it HERE, and you can read the official documentation about Babel plugins and presets HERE
So that’s Babel. And I think you can see why it is so central to the development and standardization of JavaScript; it allows us to write in extended versions of JavaScript without having to worry about compatability issues over the web. Technically speaking, Babel is a transpiler for React, Flow, ES2015 — ES2017, and much more due to the expandability of plugins.
There are also a couple very common transpilers that expand on but do not stray far from the bounds of ‘vanilla’ JS. These are Coffeescript and Typescript. CoffeeScript allows for more expressive, almost Ruby-esque, syntax:
TypeScript, on the other hand, uses type annotations to get rid of some of JavaScript’s weak typing issues:
You can read more about JS’s weak typing in this excellent excerpt from Kyle Simpson’s You Don’t Know JS.
Beyond CoffeeScript, TypeScript, and Babel, there are swarms of other transpilers out there. They serve not only to extend JavaScript itself, but to allow us to write in just about any language we please and transpile it back to JavaScript.
And that’s not even close to all of them! W is also for WebAssembly, a transpiler designed to support C and C++ code right from the start with high performance, as is also done by EMScripten. L is also for LiveScript, which extends the functional programming capacities of CoffeeScript. C is also for ClojureScript, which transpiles from Clojure into JS. There are practically more JS transpilers every day!
So what does this mean for JavaScript’s future?
Even despite JavaScript’s hasty beginnings, its strange mannerisms and frustrating quirks, JavaScript has evolved into a language that is so incredibly well used and critical to the web that developers have found ways to adapt it to just about every use case out there. Opal is there for devs who love the poetry of Ruby, and ASM is out there for those who love Intermediate Representation (basically halfway to machine code) for its high-performance nature.
In addition to JavaScript’s high variability through the use of transpilers, JavaScript is quickly gaining access to other platforms as the line between the web and the desktop starts to blur.
Tools such as Electron allow for desktop apps to be modeled in HTML, CSS, and JavaScript so that they are exactly the same as their webapp counterparts.
As this trend grows, any language that has a transpiler to JavaScript could be considered ‘native’ not only to the web platform, but also to the desktop platform. As this comes to fruition, it could mean the end of the paradigm of ‘native’ binaries altogether! Gary Bernhardt lays it out better than I possibly could:
In many ways, the future of JavaScript intrinsically linked to the future of programming as a whole. Whether you love it or whether you hate it, it is here to stay as a lasting part of the Web.
And if you do hate it, go write a transpiler for the language you prefer!
