I wrote a piece about Dart for the Norfolk Tech Journal several months ago. It’s fairly opinionated, I’m more mellow about JavaScript nowadays, and it is also a little out of date; for example, Dart will not now become part of Chrome. It’s here as a personal historical artefact as much as anything.

---

WTF is Dart?

Internally, Google is reputed to use Java and C++ almost exclusively, with a little Python, but they’ve been developing the Go and Dart languages in the last few years. Go is interesting and revolutionary like celery is spicy, yet is burning brightly in the tech community, with lots of high profile adopters. Dart, whilst not revolutionary either, does do useful and novel things, and I think it deserves a little more attention than it gets.

Douglas Crockford’s book Javascript: The Good Parts is slim, yet boasts two enlightening anti-appendices — Awful Parts and Bad Parts — and the rest of the book is not massively compelling either. However, JavaScript does have two good parts: first-class functions, and ubiquity.

Node.js extends this ubiquity to the server-side, but ultimately you’re still writing JavaScript — well, ECMAScript 5 — which brings all-too-familiar problems with it.

Now, some people love JavaScript, and I don’t mean to knock them. The development experience can be so quick to iterate that it feels massively productive, and browser competition has produced several good implementations. Those who immerse themselves in JavaScript can do wondrous things, but it can be a very potholed road for those of us who don’t do it full-time.

I’ve personally found that building larger applications is hard work with JavaScript, and I’m not alone. As an application grows you can find yourself getting uncomfortably intimate with the libraries and frameworks you’re using. Boilerplate and conventions can become the dominant forces in keeping the teetering stack up in the air, and the pleasures of programming slowly file out stage left.

This is where Dart makes sense. It rides the ubiquity of JavaScript by compiling to JavaScript, and provides the convenience of Node.js by being available both client-side and server-side. However, it bolts this onto a much cleaner language, with a modest but well-structured standard library. The language itself has a greater range of data types than JavaScript, functions are (still) first-class objects, exception handling is richer, there are conveniences like typedefs, reflection, and a library/module system, language support for asynchronous IO, and even generics.

The standard set of tools from dartlang.org includes a decent IDE, profiler and debugger, documentation generator, and Dartium, which is a version of Chromium with native Dart support. This will eventually make it into stable Chrome builds, but it’s good for development right now. Production deployment via compilation to JavaScript is still the way to go on the client, but on the server you can run your code in the Dart VM.

Dart is thoughtfully constructed and well executed. There are the tools you need as a developer, including a unit test library, and command-line access to the compiler, static analyser, package manager, and others, meaning you’re not tied to Dart’s IDE either. It interoperates with JavaScript on the client, there are ports of Polymer and AngularJS to get started with, or you can interact with JavaScript directly via the dart:js library from the standard library, and code packages can be used for deployment and sharing. If it sounds as if Dart is a mature and well-designed language that fits nicely into the node.js niche, only without legacy baggage… that’s because it is.