This morning was the big “Dart language” unveil – the Dart websites are up at http://dartlang.org and http://dart.googlecode.com. And already many seasoned Javascripters have the knives out. I’m surprised for a couple of reasons: the first, this isn’t quite as big a deal as many people thought it would be (me included), both in terms of the scope of the system and the distance to Javascript. Second, the system isn’t quite as finished as many predicted: this isn’t going to be usable for a little while.

That all aside, let’s look at the highlights:

It’s classicly classful

Javascript has a prototypical object system. That means that instead of having classes that define what objects should look like, you simply create an object, make it look how you want it to look, and then use that as a template for all future members of that “class”. This is deeply confusing to many people who have come from languages like C#, Java, C++, Python (etc. – i.e., practically all of them) where you do things the classical way. The Dart designers have more or less thrown out the prototypical system, and a standard class-based system is available, with some degree of optional typing.

And in fact, it seems more or less mandatory: they’ve used main() as the code entry point again, and like in Java, for anything non-trivial you’re basically going to have to write a class which implements that function.

I’m not yet sure whether this is a great thing or not – mostly, I’m ambivalent – but lots and lots of people have written their own “quacks like a class” system on top of Javascript, including Doug Crockford. Javascript is flexible enough to represent this, so the Dart-to-Javascript compilation bits will work, but obviously it’s not going to interact well with Javascript libraries that take a different view of classes or inheritance. This is probably not a problem; Perl has a number of different ways of implementing objects and there doesn’t generally seem to be much trouble with it.

Wider standard library set

Javascript has been let down by its standard library set in many ways. First, there really aren’t many data types available: you have an associative array, you have a non-associative array, and that’s about it. Objects are more or less associative arrays. But also, there aren’t other APIs to do useful things in the primary heartland of Javascript, the browser. The answer to all this, of course, has been the rather well designed Javascript library projects that have sprung into being: the JQuery, Mootools and YUIs of this world. And there are many of them, and the competition is fierce, and the end results are actually very good.

Dart goes a slightly different way with this. The library sets that come with Dart do a lot more than Javascript is capable of. There are lots more basic types, and many basic behaviours (interfaces) that describe in what context you can use such data – for example, any type that implements ‘Iterable’ can be used in a loop. It’s pretty great that this is all standard. Sadly, the DOM library makes a re-appearance, which is a bit of a shame because it’s literally one of the suckiest APIs ever invented, but on the flip side it does mean that the likes of JQuery could be ported to Dart easily.

Sugar for asynchronicity

Javascript, particularly when used in the browser, is deeply asynchronous. Unfortunately, the language itself doesn’t have an awful lot of support for that. You can pass functions around as first-class objects, so a lot of APIs are designed with function call-backs to execute “later on”. This leads to a kind of “macaroni code” where roughly procedural code (“Do this, then do that, then do this other thing”) is broken up over many functions just so it can be passed around like this. Dart gives the programmer a little bit of help here by implementing Promises.

In Dart, the Promise is an interface which looks an awful lot like a thread in many ways. The key sugar here is that the language still has the callbacks, but you can chain them together with then() instead of embedding them each within itself. You can also check on how they’re doing, cancel them if you like, and other stuff – again, nothing that Javascript doesn’t have, but slightly more elegant. Combined with the class system, it also means the end of ‘var $this = this’ and other such scoping hacks.

Message passing

This is probably more important than the Promises interface. Dart has message passing built-in, like many suspected. And, it looks nice and simple: you have ports, and you can either receive messages from them or send messages to them. The receivers are basically event-driven in the same way a click handler would be. Seeing the value here is difficult in some ways: it will be interesting to see how the balance is struck, because if you are designing a class you could either make an API which creates Promises, or send/receive messages – the net effect is roughly the same. You probably don’t want to implement both, but which system you use is up to you. The message passing interface is slightly more decoupled; but it’s probably easier to abuse in the longer term.

It’s all sugar

I think this is the thing which surprises me most about Dart: it’s actually pretty close to Coffeescript, but with a more Javscript-like syntax. And that’s why I can see this being successful: you can turn it into standard Javascript, but it gives us a lot of the bells and whistles that programmers have been crying out for. Classes have getters and setters like C#, strings can have variables that interpolate within them, you can write really lightweight functions in a new => syntax, and classes can have built-in factories – just to name a few of the highlights.

There are some extras, like the ability to reference needed CSS, which point to a slightly grander future where Dart scripts are rolled up with their related resources into something more easily distributable. And maybe this is the point: the unveiling of Dart was not really a beginning itself, but the beginning of a beginning. They’ve designed the language to attempt to grow with your application: you can start small and simple, but as your application grows you can add more to it (like types and interfaces) to make it more structured and, hopefully, safer to run. And in the same sense, Dart itself is going to grow over time as well.