ES2015 JavaScript vs. Elm vs. TypeScript
In search of the perfect Front End Language
As a Front End focused software engineer, one of my goals is to constantly evolve the tools and methodologies I use in my work. Change is baked right into my DNA, and rightfully so considering my chosen profession I might add. People often speak of JavaScript fatigue, a syndrome where engineers get burnt out from the constant change in the JavaScript ecosystem. This is not a problem for me. I embrace the change and I try to move faster than it, which of course is not always possible. That said, when it comes to making alterations at the language level, I am often more cautious and I take my time to make decisions based on experience.
Over the past year, I have written JavaScript professionally and have experimented significantly with two additional flavors of JavaScript supersets, if you will, including Elm and TypeScript. In this article, I will compare each of these language choices and make a conclusion as to which is my language of choice for 2017.
JavaScript
JavaScript has undergone some serious transformations over the years. Most recently, it received the biggest update to the language ever. The JavaScript we are writing nowadays with ES2015 and onward is a totally different animal compared to what you might be used to seeing with pre-ES2015 JavaScript. If you are not familiar, we are using a tool called Babel that takes new JavaScript and changes (transpiles) it into JavaScript that can be understood by modern web-browsers.
The release of ES2015 gave me motivation to write JavaScript full-time, where in the past I would never have considered making a career out of it. It’s a very exciting time to be a Front End Engineer. Using web technologies nowadays, we are able to make just about anything you can think of. Dynamic web applications, native and browser-based mobile apps, virtual reality, artificial intelligence, APIs & web-servers, cross-platform desktop apps, et. al.
Beyond just the syntactic updates to the language, one of the major changes has come with the tooling that is now available. Using Webpack, we no longer need to load modules via script tags and are able to bundle up our code in such a way that is compatible with web-browsers. This has enabled Front End Engineers to think about UI application design in terms of components, making it simple to package up reusable interface component libraries.
Overall, JavaScript is a very exciting language to work with, but at the end of the day, it is still missing some key features in my opinion. On the top of the list is static-typing, followed closely by native immutable data structures. Although there are libraries that help to fill in the gaps, namely Flow and Immutable.js, it can be tough to find a common ground from project to project. For this reason, vanilla JavaScript is not my top choice for Front End languages going forward.
Elm
I spent roughly 3–4 months reading books about Elm before I took the dive into using it for a project. I have to say that Elm is by far my favorite of the three and in fact might be one of my favorite languages of all time. First-class support for: static typing, persistent immutable data structures, auto-currying, ADTs, the Elm architecture, etc. The list goes on and on. Elm is a Front End Functional Programmer’s best friend and is right up my alley.
With all of this said, Elm is not my top choice for Front End languages. Elm is still very much a niche language without a terrible amount of widespread industry acceptance. My desire to be involved in a number of projects as an independent contractor keeps me motivated to use more mainstream technologies for the time being. Perhaps in a year or so, Elm will rank number 1 for me.
TypeScript
Let’s get real for a second. Nowadays we are building just about everything with JavaScript. For the most part, this works great. We are able to eliminate nearly all bugs and performance issues using immutable data structures and Flux / Redux. There is still one class of bugs that pop up quite frequently, however. This entire class of bugs can be fixed with static type checking and TypeScript is designed to do just that. With TypeScript, you are still writing the JavaScript that you are already used to, but you have first-class support for static-typing bundled into an extremely modern and fast compiler.
TypeScript is a blast to work with and is very easy to get setup with it. Using Webpack makes incorporating TypeScript as easy as installing a loader and saving files to a .ts(x) extension. Other than a few demonstration projects, the first real project that I made using TypeScript as the main language is the scalable-react-ts-boilerplate project. This project is a spin-off of another boilerplate micro-framework that I built as leader of the Udacity Alumni Web Team. It implements the same feature-first architectural pattern, but using TypeScript as the main language.
In building this project, the realization that I made is that TypeScript is very well fit for building UI component libraries. As part of this boilerplate, I built a dozen or so reusable UI components, which demonstrated the capacity of TypeScript to facilitate self-documenting APIs. This is also the case for GraphQL, a library that I am also incredibly fond of, as it also deploys a static type system which facilitates automatic documentation of your application’s data layer. Due to the fact that in 2017, I will be working as a core contributor on several UI Component libraries, TypeScript is starting to make a lot of sense for me.
By incorporating a static type-checking tool like Flow, JavaScript on it’s own is a very powerful language and is on the same level as TypeScript in terms of its abilities. The main reason why I prefer TypeScript at the current point in time is that it encourages the use of type-safety more so than Flow. It has been my experience that when you work with a team on a project, Flow does nothing to enforce the usage of static-typing, meaning that your team members can very easily sidestep Flow’s type-checking. With TypeScript, it is a given that anyone working on the project will be using static typing and you end up with higher quality code as a result.
Summary
While there are dozens of solid choices for Front End languages these days, it is my opinion that the three that I wrote about here are the best available choices. ESNext will be one of the top choices for a long time to come due to its mainstream acceptance. It is a very good language and is leaps and bounds more evolved than its predecessors were. Elm is my favorite language of the bunch due to its functional nature, but due to the fact that it’s still fairly niche it is not going to be my primary language anytime soon. All in all, TypeScript is my top choice. The fact that I am writing nearly the exact same thing as with JavaScript, other than adding type annotations, makes TypeScript the perfect middle-ground for me. It also enforces better practices than Flow and has a faster / more accurate type-checking, in my opinion.
