Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

JVM Languages

The JavaScript Alternatives

Two and a half years ago, in discussing JavaScript's ubiquity, I projected that this trait alone would make the language the continued target of new languages and compilers. And, in fact, this has happened. Many languages now offer the ability to compile to JavaScript in addition to their original, principal targets. For example, among those that also compile to native code, there are: Nimrod, which we discussed last month, Fantom, and the gaming language Haxe. In addition to these, there are many standalone tools that translate code from your favorite language to JavaScript. Of these, the most famous by far is the under-appreciated Google Web Toolkit (GWT), which converts Java code to JavaScript. (I say "under-appreciated" because the tool definitely has magical aspects to it. For example, you can live debug Java code, which is mapped behind the scenes to the actually executing JavaScript.)

There is another segment of the industry, though, where a lot of action is taking place. Entrants here aim to correct the perceived shortcomings of JavaScript by either extending or improving the language and offering code-to-JavaScript compilation. The most widely known players are CoffeeScript, Google's Dart, and Microsoft's TypeScript. Their approaches are rather different, but are all aimed at enabling JavaScript to be used in larger projects than it was ever intended for.

The first of these languages to come to market (in 2010), CoffeeScript is probably also the most established. It borrows concepts from both Ruby and Python to reduce clutter and remove some ragged aspects of JavaScript syntax.  To be comfortable with CoffeeScript, you must be willing to forgo traditional mainstream programming constructs — curly braces, semicolons, etc. — and adopt new syntactical elements like meaningful white space. Users of Python and Ruby already have partially adopted those conventions, and so it's no wonder they in particular have embraced CoffeeScript. For example, it's now part of Ruby on Rails (as of v. 3.1). And at GitHub, it's the recommended language for doing Web development.

Dart is a considerably more ambitious effort, driven by the same team that wrote the V8 JavaScript VM that drove Google Chrome to the performance lead among browsers. They set about writing a language that stays closer to JavaScript, but which can run in its own dedicated VM (in addition to compiling to standard JavaScript). This VM has several unusual properties, one of which is that there is no separate internal instruction set to which Dart code is compiled prior to execution. The VM uses the Dart code, in its parsed form, as the instructions. The VM currently runs only in Google Chrome. No other browser has plans to support it.

The overarching goal of Dart is to obtain the best possible performance for Web apps. Hence, I sense that the VM will be as important a center for continued refinement as the JavaScript generation. If not the VM itself, then certainly the tools that support its use. To this end, the team has built remarkably extensive tooling for writing, testing, and debugging Dart.

TypeScript is Microsoft's entrant into the fray. It has a somewhat different tack on the question of syntax improvement. Its entire focus is to fix the things in JavaScript that make writing large programs (100K+ LOCs) difficult, if not impossible. It does this by adding types, classes, and namespaces, while retaining much of the basic JavaScript syntax. In this regard, it is carefully tracking features that are certain to be delivered in the ECMAscript 6 specification, which defines the language. This long-delayed document is set for ratification and public release later this year.

TypeScript, designed by Anders Hejlsberg of C# (and Turbo Pascal) fame, is a superset of JavaScript, which syntactically makes it different from the two alternatives here. You can copy and paste JavaScript into a TypeScript program and it will run without requiring modification. Tooling consists of extensive plugins to Visual Studio, that enable you to program and debug in TypeScript rather than JavaScript. The company's larger efforts to achieve optimal execution performance don't follow Google's path of a separate VM. Rather, Microsoft has chosen to keep refining its JavaScript VM (Chakra).

In choosing which solution to adopt for large JavaScript projects, there are many factors to consider. Here, I've primarily discussed the language directions, on a somewhat comparative basis. But political factors enter into it, too: While all three languages compile to JavaScript and so generate portable apps that run in all browsers, TypeScript and Dart are driven by vendors. These vendors have both pulled the plug on projects they no longer valued due to changes in corporate priorities. What happens if you have a 200K project a now- retired language? Fortunately, all three solutions are open source, so communities could arise to fill the gap (although I expect that would be unlikely). The distinct benefit of the vendor support is that the tooling in TypeScript and Dart is advancing faster than with the non-vendor-supported CoffeeScript.

To be fair, both Microsoft and Google are hugely invested in making the Web experience as fast as possible on their respective platforms, so it seems unlikely that they will ever abandon tweaking and perfecting JavaScript language features and performance. So, I think that while the vendor factor can never be dismissed outright, it can be accorded a secondary place, with the choice of language made primarily on the basis of features, the supporting tool ecosystem, and (especially) the community size and tone.

—Andrew Binstock
Editor in Chief
[email protected]
Twitter: platypusguy

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.