asgaard

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

Sat, 20 Dec 14 13:40:47 +0000

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 Size	Approx #lines of code	Choices
Tiny	1k	Plain JS
Small	10k	TS, Closure, Plain JS
Medium to very large	>10k	TS, Closure

TypeScript and Closure

Sun, 05 Oct 14 16:42:07 +0000

For the past few years I've worked a lot on large JavaScript projects. JS is a very dynamic language and that means it is very difficult to maintain a reliable code base for multiple developers over long periods of time without strong tooling.

For most of that time, we've used Google's Closure Compiler. Closure (the compiler) is extremely good and very useful. Although its main way of selling itself is to describe itself as an advanced minifier, its real value is in its strong understanding of the JS you give it and its ability to perform a lot of static checking. Closure (the library) is not something I would recommend, but the compiler is solid.

The only real downside of Closure is that it requires adding ugly annotations to your code, e.g.

/** 
  * @param {string} s
  * @return {number}
  */
function toNumber(s) { return parseInt(s, 10); }

I think that the fact it requires all these annotations to become useful is the main reason that Closure has been largely overlooked by JS developers (i.e. "too much effort"). But I would argue that requiring type documentation is not really a bad thing if you want maintainable code.

The flip side of this is that Closure code is just JavaScript. You don't even need to invoke the compiler to test your modifications - just fire up your browser and away you go (well, unless dependencies need regenerating, but that's actually quite rare). Assuming you are using the compiler as a safety check, it's usually only necessary to use it before you're ready to commit your code.

TypeScript

Next onto the scene is TypeScript. TypeScript is a compile-to-JS language by Microsoft that fulfils the same niche as Closure. It adds type information into the language syntax and its compiler is able to perform the same class of static checks as Closure. It looks a bit neater:

function toNumber(s: string) { return parseInt(s, 10); }

The main feature that TypeScript gains, as a result of being its own language and not a set of non-universally recognised comment conventions, is that IDEs recognising TypeScript should expect to be more helpful. In short, I am describing Visual Studio's intellisense.

But in reality the quality of Typescript's tooling has never appeared to be of much importance to Microsoft and it's still not very good now. Pre-1.0 was practically unusable due to the instability and performance woes that it would inflict upon Visual Studio (by which I mean several crashes per day, often preceded by periods of very high memory usage). The fact that it was ever released in that state is a worry in itself as to how serious Microsoft is about TypeScript, and despite critical issues being fixed now, it's still not really very good:

Visual Studio still requires usually one restart per day to fix performance issues (the dreaded "Formatting task took more than 2 second(s) to complete. Try again later" message - once you start seeing that, some key strokes take 2 seconds).

Occasionally the editor will start reporting non-existent syntax errors and refuse to compile to JS. This is extremely confusing, but it can be fixed by cutting the offending code out of the document, pressing save and letting it recompile, and then pasting it back in. Until you get wise to this, you can spend a lot of time hunting for the (non-existent) cause of the syntax error.

Overall the quality is poor enough that I'm sceptical that TypeScript is getting any real everyday testing/usage by its developers. That would be ok if it was still in alpha state, but it's been public for two years now.

You can, of course, use any editor you like to write TypeScript, but if that's the case you aren't gaining anything over Closure.

There are other annoyances that probably aren't TypeScript's fault. Debugging TypeScript is a bit less pleasant than debugging JavaScript, simply because the browser isn't executing TypeScript. Sourcemaps get you 90% of the way there, but it's still not as smooth as debugging the pure unedited JavaScript as allowed by Closure.