JS minus JS: The Future of the JavaScript Community is better through transpilation.

Last week, I had the pleasure of representing CoVenture while speaking at the Northern edition of ForwardJS about a topic near and dear to my heart: transpilation in the JavaScript ecosystem. It’s my understanding that a recording of that will be coming out soon, but before that (and with a desire to expand my thoughts outside of the 20 minutes I had to talk on the matter at the event) I decided that I would write out a bit more on my thoughts here.

Let me preface this discussion with a bit of celebration: in 2017, and so far in 2018, no matter how you slice the data, JavaScript is one of if not the top language used by developers. Its position is visible in rankings from Github itself, the fantastic team at RedMonk, even the PYPL index. The IEEE has it as #7 on its list, which is one of the lowest rankings I could find in relevant sources.

Suffice it to say that the field of JavaScript development continues to grow, and shows no signs of stopping. With the advent of native mobile frameworks and the adoption of server-side JavaScript increasing, there are more ways to develop in the language than ever before. Furthermore, through the introduction of the TC39 process, JavaScript continues to advance at an even faster pace. These points make the landscape in 2018 very, very exciting.

At the same time, the world of JavaScript can be very intimidating to the outsider and uninitiated: Mobile, Hybrid, Native, Server-side, Client-side, Gulp, Grunt, Bower, Webpack, React, Angular, Vue, NPM, Yarn, Functional vs. Object-Oriented… the lists of terms, concepts, and processes extend forever, sparking debates around which is best or en vogue. The fallout from these internecine conflicts is that it is quite easy to alienate new developers, and I would propose that it is only momentum and critical mass — the gravitational pull and monopoly JS has on development for the web — that allows JS to continue to grow. However, lack of clarity and cohesion will persist if not checked, and other contenders are coming down the track towards JS. If the community wishes to continue to flourish, it can’t afford to be complacent.

There are two solutions to this scenario, as I see it. The most obvious is to determine a winner in the myriad of debates currently underway: to establish a “right way” to develop JS on the web in 2018 and beyond. The primary issue with this approach is that we will likely lose many people in the process — the functional fans will go back to friendlier territory, or the object-oriented observers find greener pastures to inherit.

The better alternative, in my opinion, is to open the gates entirely; embrace the wildness that is the JavaScript arena! Let everyone develop how they are most comfortable, and then work on consolidating and normalizing that code after the fact. If JavaScript is to be the lingua franca of the web, let folks get there in their own way. As the title of this post would suggest, this means, of course, turning towards the transpiler.

Before we continue, let us define the terms “compilation” and “transpilation” for the purposes of this conversation. More complex and specific definitions will of course be available, but it is important that we come to terms within the scope of this discussion.

When referring to “compilation,” I mean the transformation of code from one language to another: typically, this means from a language or form of higher abstraction to a lower one.

“Transpilation,” on the other hand, is a variant or subset of compilation, where one transforms code between languages at a similar level of abstraction. When used in the context of this conversation, this will even more specifically refer to the transformation of code from a given source language to the target language of JavaScript. You also often see this referred to in other places as “targeting.”

You should note that while abstraction in the context of programming has implications on human readability or ease of conceptualization, the process of transpilation is usually an automated one, and may also include removing readability aids (such as whitespace). While this may mean that the act of transpilation changes the level of readability of the resultant code, the general level of abstraction will remain the same.

I believe that embracing transpilation is the best future for JavaScript development for several reasons, and you can summarize many of them in the following statement:

Transpilation allows developers to write in whatever language or framework they prefer, and have the result still be JavaScript.

This process is beneficial for many reasons: it allows developers to leverage the pieces of abstraction more useful to them, to write in languages that they are comfortable in, and exposes JavaScript to more concepts and innovation.

Every developer is unique, and conceives of or conceptualizes differently. The implication of this is that each developer will prefer to abstract a different aspect of their writing process. Some prefer not to have to think about the typing of their components, while others would rather avoid the explicit declaration of every aspect of each of their structures. When designing a language, different problem areas will always be addressed, depending on the personal opinions and philosophies of the language’s creator. Like-minded individuals will naturally gravitate towards the implementation that most closely adheres to their profile to become more efficient in their work, and this should be encouraged.

Forcing people to write in languages they aren’t comfortable in, while it can be an effective way to expand one’s mindset (a laudable desire, in my opinion), is not a very good way to satisfy developers, and is more likely to lead to poorly written or designed code. Most developers, given a choice, would choose not work on a project rather than be forced to use a language or framework they find incompatible with their approach or mindset.

Instead, if we encourage various mindsets to contribute to a project in their unique way, we introduce new concepts to what might otherwise be an incredibly homogeneous conversation. More diversity is always better.

Transpilation is not a new concept and has been around in the JavaScript space for a while. CoffeeScript first appeared at the tail end of 2009, TypeScript in 2012 (it’s interesting to note that TypeScript itself is now one of the most popular languages on GitHub), and even the Babel predecessors (6to5, Traceur) are four years old now. This field continues to grow — the list on the CoffeeScript Github is extensive. For virtually every member of the top 10 or 15 programming languages, there is a method to get your code transpiled to JavaScript. Here are just a few, for some of the more popular options.

• Java: there are several options, but two of the most interesting are JSweet and Kotlin — a language in its own right that is remarkably similar to Java, is growing in popularity among the native Android developers and targets JS out of the box.
• Functional Fan?: Clojure has ClojureScript, and Elm is a functional language (primarily for the graphical side of the web) that targets the modern web stack (HTML/CSS/JS).
• The C School: Emscripten can convert C/C++ projects to the asm.js JavaScript subset, and Dart (a C-style language) offers dart2js.
• PHP and others: while not every language may have perfect interoperability with JavaScript, projects like Haxe can act as a Rosetta Stone of sorts, making PHP->Haxe->JS relatively effortless, but tremendously advantageous for testing out the impact of various approaches across systems.

In summary, I would like to say the following two things:

1. The future is a polyglot one.
2. The more ways there are to write JavaScript, the more people will write JavaScript, and the more people that write JavaScript, the better JavaScript will get.