When should I use a JavaScript compiler, and which one should I use?

Published December 20, 2014

There are a few different options for Compile-to-JS languages and here I'm going to outline the main contenders as of late 2014.

Plain JavaScript

Let's start with the basics. A lot of people who do not understand plain JS berate it for many things, but in reality its main practical drawback is that it becomes unwieldy on larger projects (like any dynamic language), and in such cases, having a checking compiler will cut down on a lot of unit testing. Plain JavaScript is fine for small projects, it becomes problematic as your code grows; the point at which that happens depends on the skill and discipline of your developers.

Regardless of what you choose, you're going to be working indirectly with JS and you should learn it to a fluent level.

CoffeeScript

CoffeeScript (CS) was very popular when it was released but popularity has since waned. Its only feature is syntax, which implies that there is something seriously wrong with JavaScript's syntax (subjective), but fixes it by making it completely different (Ruby-ish) instead of identifying exact problems and improving them. It is now quite surprising to come across CoffeeScript code, which suggests that people have generally rejected CS as an improvement (an opinion I agree with). It does not really help with the fundamental problem of code management, because it's just another dynamic language. Avoid.

Dart

(Google's) Dart is a strange one because although Dart code can compile to JavaScript, it's really designed to be run on a virtual machine, which only Chrome implements. For this reason, it is not worth evaluating further. Avoid unless you have a particular reason not to.

Google Closure Compiler

Closure is a checking compiler from Google, and it is interesting in that it works on pure JS code, i.e. it's not a separate programming language. Code written for Closure needs comment type annotations (which are quite ugly and cumbersome, but easily written if you are disciplined) to make use of the compiler's features. The compiler does useful things like checking that the methods you are calling really exist, instead of leaving you to find out at runtime.

The main downside of Closure is performance; there is no incremental compilation which means if you change one line of one file you have to recompile the whole thing, and it can take several minutes. I should stress that for development this makes little difference - you tend to develop using your raw code, not the compiled code, so invoking the compiler is something you do before committing code, not (always) before trying it out locally. To make full use of Closure all external libraries need to have type definitions; for popular libraries these are easy to find and it is not too hard to write these yourself (but it is an extra requirement).

Google's investment in AtScript (see below) may have implications for the future of Closure, but the compiler itself is mature and reliable as it is.

TypeScript

TypeScript (TS) has been around for a few years now and only recently seems to be finding its niche, although growth is still slow. TS is a superset of JS and adds some useful syntax, but its real value is in allowing you to write strongly typed and checked code, similarly to Closure, but its standardisation allows IDEs to give you things like code completion. If your average foray into JavaScript is in writing a 50 line jQuery plugin, TypeScript is completely overkill for you. On the other hand, if you are working on a JS project with multiple developers and hundreds of files, TypeScript is very useful, although it is only recently that the tooling has become mature enough to handle this scale.

The tooling (via Visual Studio) is (now) both good and stable, and the compilation step in development is fast and largely transparent. If you are using an MS environment and have access to Visual Studio, you should absolutely strongly consider using TypeScript. MS claims that tooling exists for non Windows based platforms but I cannot speak to its quality (and frankly, I'd be sceptical).

Note that TS requires type definitions for external code, like Closure.

TS is a bit of a risk in that growth appears slow and MS might see that as a reason to discontinue it.

AtScript

AtScript is superficially not dissimilar to TypeScript, but at the moment the project is too immature to seriously evaluate how it practically differs, and because of its immaturity it would be unwise to start using AtScript any time soon.

Summary

In summary, your choice for "which compiler do I use?" depends on project size, project length, and number of developers. I'll condense this all down to lines of code to get the point across. In order of preference:

Project SizeApprox #lines of codeChoices
Tiny1kPlain JS
Small10kTS, Closure, Plain JS
Medium to very large>10kTS, Closure
Filed under: javascript, programming, typescript, closure, atscript, dart

Talk is cheap

Leave a comment:

HTML is not valid. Use:
[url=http://www.google.com]Google[/url] [b]bold[/b] [i]italics[/i] [u]underline[/u] [code]code[/code]
'