Dart: did Google miss the bull’s-eye?

The vocal portions of the Web that care about such things seem to have already made up their minds about Dart, the new web programming language from Google. My opinion of it has been flipping between intrigue and tedium.

Maybe you don’t even know what I’m talking about so here’s the gist of it: last week at the GOTO conference Google unveiled, to moderate hype, their new programming language called Dart. The official aim of Dart is to help developers with writing “structured web applications” – which sounds like a euphemism for “[eventually] replace JavaScript” — to some at least. I’m going to explore that loaded sentence (or go to tl;dr).

Origins of Dart at Google

Google and the Web are inseparable. To many, the Web would pretty much cease to be useful without Google Search and Gmail. Google pioneered, or at least popularised, the foundations of modern web application development, namely AJAX. When Google Maps was released it was a breath of fresh air in its product niche and an astounding achievement in programming and UX. The thing to note here is the J in AJAX, which stands for JavaScript. Having wedded itself to the Web, Google has had to wrestle with this piece of technology since the beginning of its forays into anything more complicated that a search box and a list of results.

I doubt a Google spokesperson has ever come out to say it, but it’s clear that Google staff are no fans of JavaScript. Six years ago, they got sick of figuring out the look and feel of things and started work on GWT. A few years later they got fed up of the performance of JavaScript runtimes and wrote the source-to-source Closure Compiler/Optimiser for JavaScript and started work on their own V8 JavaScript Engine which powers Google Chrome (and notably also NodeJS).

All in all, a business expense of at least tens of millions of dollars, not to mention the headaches and opportunity cost. Of course, Google has to go all this effort because of the scale of their JavaScript codebase, which makes any criticism from small- to medium-sized development teams utterly moot when they say “we’ve never had a problem with normal JavaScript” — yes, of course you haven’t, because you’re not juggling a web application product line which includes Gmail and Google Docs.

This leaked email from Googler and ECMAScript committee member Mark Miller emerged last year. It provides an insight into Google’s view of JavaScript as a bottleneck in their efforts to build products that compete with native applications. It’s a long read but the gist of is that Google can either wait for JavaScript to evolve slowly, and/or take action and write its own better JavaScript, codenamed “Dash” in the email. The main goals of the new language are listed as performance, developer usability (including familiarity) and improved tooling (a.k.a. clearer code structuring and packaging), which no-one will deny are lacking in JavaScript.
So they did just that. Sort of.

Dear Google, Public Relations != Developer Relations

<rant>

Google suffers from NIH Syndrome: it does not take from the outside world, preferring to build its tools from scratch, and anything it produces it does so mainly for consumption by the thousands of people it employs (this manifests itself in things like their approach to Platform development, too). Don’t let the odd open-sourced project fool you.

In the case of Dart (not the first Google-made langauge) they may have hyped up its announcement, but they clearly have no intention of letting programmers — the only people who care — actually experiment with the new language yet. When you go to Dart’s code repository, there is little effort made to make it simple for you build and use anything.

Maybe Dart is just not ready for too much public airing, but that means they should have left its unveiling until it was. Google is not providing a pre-built compiler or VM binary for Dart, and their build instructions are just about tedious enough that I’d rather not waste my time. If git clone and make install are good enough for many a large project, why am I being instructed to install and use a Google-specific tool to merely fetch code?! No thanks.

</rant>

What’s Dart Like?

Apart from syntax and code samples that run in the browser, there isn’t much to go on. I quite like this article that says Dart is to JavaScript what C# is to C++: basically cleaning up some of the mess. Here’s a summary of what I think are the main features to give you a feel.

Key Language Features

Purely class-based

The class and interface concepts from Java are brought into Dart, almost exactly, with multiple inheritance being achieved through implementing several interfaces. The “purity” here refers to the idea of everything-has-a-class (or everything-is-an-object), which is lacking in both Java and JavaScript, and can only be a good thing. This applies to functions, of course, which makes closures possible in the same way as JavaScript.

Compared to JavaScript’s prototype-based model of OOP this class-based approach makes writing Dart code less crufty, more familiar to the average programmer, and will make tooling and dealing with hierarchy of the code simpler or at least easier to adapt from existing tools.

I suspect this model improves the run-time performance of Dart code compared to JavaScript, too, since JavaScript’s prototypal inheritance and functions-as-objects idiom are expensive (objects are cloned or recreated instead of referenced or re-used), at least without a good JIT compiler (but don’t hold me to that).

Optional typing

This is one of the more baffling features for me. You could write Dart code without any consideration for variable types, but you could also annotate your variables with types, like String or any class you’ve defined. The baffling nature of this is that the annotation is just that, an annotation: it makes no difference to how your code works, other than the compiler giving you a warning if you’ve misused the variable (e.g. tried to assign a number to a String variable). The code will still compile and run.

The justification for this feature is that it provides “documentation” and aids debugging and static build tools during development. I’m not convinced by this half-feature. Perhaps the makers didn’t want to put off web developers with scary strong typing or the goal of making Dart compilable to JavaScript was an obstacle. The official advice is “use types where they make sense”. To me, that advice doesn’t make sense.

Structure and isolation

One of the big practical difference between JavaScript and Dart is that when embedded in HTML, each script tag containing Dart code is isolated and can not access other scripts directly, i.e. there is no per-page global namespace. Also, Dart code isn’t simply run when it is encountered but a main() function needs to be included as the entry point into each piece of code. In theory, the designers intend each portion of code, or isolate, to be able to run in its own thread, but such multi-threading support is non-existent in browsers.

This is where the “structured” nature of Dart is most obvious and I personally like it compared to JavaScript, but those used to the way JavaScript behaves will resist it.

In the language specification, there is some detail about the concurrency model of Dart, which involves these isolates behaving like actors which perform local computation and then communicate via message-passing. I didn’t spend much time trying to understand these, but this (rather negative) write-up has an explanation.

Why you won’t use Dart

Firstly, there is obviously no practical implementation for developing or deploying Dart code, so don’t waste your time on it yet. Even the Google Chrome team aren’t 100% on whether and when they will implement a Dart runtime, let alone other browser vendors.

Secondly, although all concepts used in Dart should be familiar, it is still a paradigm shift for web developers and you can get by just fine with JavaScript. This extends to the way Dart handles DOM events which is something many developers take some time to completely absorb even in JavaScript with all the online documentation available, let alone with Dart’s event model.

Thirdly, if you really don’t want to write in JavaScript, and you don’t have Google’s NIH Syndrome, you already have access to many well-established alternatives. I have written a non-trivial amount of code in CoffeeScript, which is a pleasure to use, and look forward to playing more with ClojureScript, which is elegant but still immature. Of course, JavaScript isn’t just “assembly language for the Web” which can be ignored and you still need to fully understand its intricacies before trying to work around it.

tl;dr

This chap on StackOverflow got it right, in my opinion: Learn JavaScript, use CoffeeScript, check out Dart.