September 6, 2015

The JavaScript / TypeScript / CoffeScript / Dart choice 2015 (part 1 of 2)



I created an overview of the “big four” JavaScript language dialects: ECMAScript, TypeScript, CoffeeScript and Dart, in order to study their respective advantages and disadvantages, and to evaluate the best choice for future projects.

TL;DR: Big JavaScript language family overview / comparison ahead!

JavaScript is not the same as it was ten years ago. Having recently gained momentum and attention both for server-side programming (mainly due to the Node.js platform) and client-side programming (thanks to sophisticated frameworks such as AngularJS), JavaScript is now a viable alternative to “traditional” languages and platforms such as Java or C# for any (web-based) project of arbitrary scale, especially as it unifies client and server code base through a single main language.

However, as a JavaScript newbie, you’ll discover that there’s also not just the JavaScript. There is actually a variety of different versions and dialects of the langue, which emerged throughout the chequered history of the language.

Also, JavaScript isn’t actually “JavaScript” anymore at all. When JavaScript developers refer to their language, they typically mean the official standardization through ECMA International called “ECMAScript”. Due to various shortcomings and lack of updates to the old ECMA standards (ECMAScript 5 (2009) and earlier) in recent years, a number of independent script languages have emerged, the most wide-spread of which are nowadays TypeScript, CoffeeScript, and Dart. These are designed to be “transcompiled” to optimized JavaScript, which is typically effectuated through an additional automated step in the application deployment process.

However, in June 2015, ECMA released their newest standards specification (ECMAScript 6 (2015), called “Harmony”) which does not only address most shortcomings in earlier versions, but really enhances the language with important concepts known from other high level languages such as classes, module imports and promises, but also includes concepts still lacking in many other major languages (such as String interpolation or parameter default values, lacking in Java).

Hence, nowadays, after you’ve chosen to build a JavaScript-based solution, but prior to making any tech stack decisions (Node.js, AngularJS, …), you have to choose an actual language implementation. The main question here is: Will you go for the official standard, and if so, for which one? Or does your situation require a specialized, 3rd party language implementation?

Here I present an overview of the currently most wide-spread members of the JavaScript family:

JavaScript language family overview

ECMAScript 5 (2009) ECMAScript 6 (2015) (“Harmony”) TypeScript 1.5 Dart 1.12.0 CoffeeScript 1.9.3
by Ecma International Ecma International Microsoft Google Jeremy Ashkenas
Open source license BSD BSD Apache BSD MIT
Compile to ECMAScript 5 (using e.g. Node.js) N/A YES (Through e.g. Babel or Traceur) YES YES YES
Run headless / natively (with own VM) N/A N/A NO YES NO
Native browser support YES NO (< 100% depending on engine) NO NO (just “Dartium” experimental browser) NO
Compile to JavaScript on-the-fly in browser N/A N/A YES (not officially supported / recommended) NO YES (not officially supported / recommended)
Syntax
; optional YES YES YES NO YES
{ } optional NO NO NO NO YES
Definition keywords var
  • var
  • let
  • const
var
  • var
  • (static types)
(none)
Additional special operators (none) (none) (none)
  • ?. null-safe
  • .. cascade
  • ? existential
  • ?. null-safe
  • @ this
  • (more)
“Everything is an expression” NO NO NO NO YES
“Everything is an Object” NO NO YES YES NO
Optional explicit type checking NO NO YES YES (warnings only) NO
Control flow
Array / List comprehensions NO NO NO NO YES
Strings
String interpolation NO YES YES YES YES
Multiline Strings NO YES YES YES YES
Functions
Default value for optional parameters NO YES YES YES YES
varargs NO YES YES NO YES
Array spread NO YES YES NO YES
Destructuring NO YES YES NO YES
Generator functions NO YES NO YES YES
Promises NO YES NO YES (called “Future”) NO
Collections
Ranges NO NO NO NO YES
Data structures
Classes NO YES YES YES YES
Accessors (implicit getters / setters) YES YES YES YES NO
Interfaces NO NO YES YES (classes are implicitly also interfaces) NO
Enums NO NO YES YES NO
Generics NO NO YES YES NO
Mixins NO NO YES YES NO
Modules NO NO YES YES NO
Import / export NO YES YES YES NO
ECMAScript 5 interop
Inline ECMAScript 5 YES YES YES NO NO
Embed ECMAScript 5 N/A N/A N/A YES YES
Tools
Dedicated IDE N/A N/A Visual Studio - -
Plugins for open source IDE (every major IDE) Eclipse (through plugin) Eclipse IntelliJ IDEA Community Edition Eclipse (but support seems dead)
In-browser debugging YES YES (with transcompilation or natively depending on engine) YES (depending on IDE / browser) YES (it uses Source Maps) YES (it uses Source Maps)

Some considerations

Licenses

All standards and implementations are open source. The license should thus not be a deciding factor.

Compile to ECMAScript 5

All the 3rd party language implementations are actually “transcompiled” to ECMAScript 5 or another JavaScript-compliant language (which is quite remarkable as ECMAScript is a high-level programming language by itself). This is important for two usage scenarios:
  • Server: There is no dedicated VM for the language, so you have to compile it to a language your server environment can run (e.g. ECMAScript 5 / through Node.js).
  • Client: You’re targeting a browser without native support for the language. Apart from the 3rd party dialects, this is currently also true for the official ECMAScript 6 standard.
In either case, you’re going to add an additional “transcompile” step in your deployment process. Although the concrete implementation differ for each language, this process can and must be automated using e.g. Node.js / Grunt.

However, note that this automated “transcompiling” step actually provides an additional advantage:
  • The outcome JavaScript is typically “optimized”, more so than you could probably write by hand (of course, this depends on the language implementation)

Additional functionality and libraries

When comparing the various language implementations, it’s important to remember that because of the to-Javascript-transcompilation, you can use any 3rd party JavaScript extension library to include additional functionality not covered by the core distribution of the language. For instance:
  • Module import / export, as included in e.g. ECMAScript 6, is also included in Node.js.
  • Promises, as included in e.g. ECMAScript 6, are also provided by the Q library.
Thus, if a language lacks a desired feature, you’re most likely to find a JavaScript extension library for just that. For course, this does not apply to features which require extra syntax such as list comprehensions.

ECMAScript 5 interop

A language’s familiarity to ECMAScript 5 defines ease of a migration path. Here, we have two type of languages: ECMAScript 6 and TypeScript with are fully backward-compatible with ECMAScript 5 and are thus technically a super-set of ES5 functionality, and Dart and CoffeeScript which have built their own grammar from scratch. However more or less similar to original JavaScript, their parser doesn’t recognize JavaScript syntax if it derives from the language’s own syntax. However, these two languages come with a built-in means to evaluate native ECMAScript 5 code.

Tools

Some language come with their own IDE; for others, there are plugins available in major open source IDEs. I have neglected proprietary IDEs here. Of course, pure JavaScript writing is possible with any text editor, and the most important tools of a JavaScript deployment pipeline really are just command line tools, which may diminish the need for sophisticated IDE support in smaller projects.

Thanks to the so-called Source Maps facility, debugging on the original source code is possible even after transcompilation into ECMAScript 5.

At this point, I encourage you to study above comparison chart and draw your own conclusions, or read my own evaluation and conclusions on the next page.

Pages: 1 2