Universal JavaScript

In the beginning, there was Netscape. And Netscape wanted to run Scheme in Netscape Navigator. So they hired Brendan Eich to work on it. But then they changed their minds and decided they wanted Java instead. And lo, JavaScript was born. And it was good (enough).

Some years later, Ryan Dahl had this crazy idea to pair Google’s V8 JavaScript runtime with libev so developers would have a way to run their JavaScript outside the browser. And node.js became a thing. And npm. And the people rejoiced.

And people started writing web servers in JavaScript, and flying helicopters with JavaScript, and putting it on tablets and mobile phones, and embedding it in thermostats and refrigerators and pretty much anywhere they pleased. And there was a proliferation of JavaScript. And Serious Developers™ despised the common people who wrote JavaScript, but the people just kept writing more and more JavaScript.

And the people sought for a word to describe this widespread adoption of JavaScript, because the term “JavaScript” on its own was not sufficient to describe its vastness. SoCharlie Robbins suggestedthat the term “Isomorphic JavaScript” might be used to describe JavaScript code that “can execute both on the client and the server”. And nobody knew what the hell it meant, but now instead of just writing JavaScript the people were writing Isomorphic JavaScript.

Wait … huh?

When coining the termIsomorphic JavaScript, Robbins explains that he meant “that any given line of code (with notable exceptions) can execute both on the client and the server”. However, if we examine more closely the meaning of the wordisomorphic_we read “corresponding or similar in form and relations”. In other words, two entities that_are not the same_but only_look the same. This would be a great word to use when describing the relationship betweenjQueryandZeptoorUnderscoreandlodash, for example. These libraries are similar in form (they share the same API) but differ in underlying ideas and philosophy.

Instead, what we need is a word that describesthe same code_but_running in a different environment. Nowadays we run JavaScript code not only on servers and in browsers, but on mobile and embedded devices as well. We’re running it on Raspberry Pis and Wii Us andiPhones. But this is a purely technical argument. What’s even more important is conveyingunderstanding.

But of course, understanding is highly subjective. Recently, Ryan Florence and I began conductingReact.js Trainingcourses full-time. Up to this point we have trained several hundred developers, and it’s not uncommon for someone to ask what the wordisomorphic_means. Now, this is purely anecdotal evidence, but when we use the word_universal_instead of_isomorphiceveryone gets it. It may have something to do withApple using that same wordto describe application bundles that ran on both architectures back when they made the switch from PowerPC to Intel.

It’s true thatthere are two hard problems in computer scienceand one of them isnaming things. Why? Becausegood names are important. A good name teaches about purpose and responsibility, so you have to spend some time thinking about it.

So let’s give our JavaScript code a name that people can understand; a name that indicates what it actually does instead of introducing words into the common vernacular that clearly don’t belong there; a name that teaches people that it runs not only on servers and browsers, but on native devices and embedded architectures as well.

Let’s call itUniversal JavaScript.

My thanks toRyan Florence,Pete Hunt,Peter Cooper,Dan Abramov, andMark Dalgleishfor reviewing this post prior to publication. Also, thanks to Ryan for riffing on these ideas with me.