Dart is a new programming language for the web, developed by Google. It’s intended to bring more structure to programming for the browser.

To get a taste of Dart, I re-implemented my ClojureScript coin-tossing experiment in the language, learning as I went along. The source code is on GitHub, take a quick look at it before reading my comments.

Pre-alpha geekery

Before you read on, it’s worth noting that Dart and its associated tools are not even in alpha release. They’re changing all the time and bugs are an expected part of the experience. The point of evaluating it now is to get a glimpse of the future, not to see whether Dart’s something to use in your next production system.

Dart, as currently experienced, compiles to JavaScript. The ultimate idea is that there’ll be a Dart interpreter in your browser, which will run Dart programs natively. The Dart team don’t foresee a Dart virtual machine, much in the same way that JavaScript doesn’t have a VM. Seen in one light, Dart and JavaScript interpreters are VMs themselves—this is already in evidence with languages like ClojureScript and CoffeeScript compiling down to JavaScript.

IDE from the get-go

Though it’s possible to use a command-line compiler, the Dart project pushes you strongly in the direction of using the Dart Editor. The editor itself is a specialized version of Eclipse. Despite not being an habitual IDE user, I had little trouble adjusting to the Dart Editor.

The most valuable feature of using the IDE is the incremental compilation, which enables you to catch errors early on, especially if you use static types. Another advantage of using types is that it brings the IDE autocomplete into play.

Static and dynamic types

Dart solves the issue of whether to use static or dynamic types by letting you do both. I am having a tough time deciding whether this is the smartest thing ever, or too much power for mere mortals to wield. For example, I can declare a variable either as simply a var or as an int and work with it in the same way. Here are my initial thoughts.

• Having types is great. It lets me find more errors at compile-time. It reminds me of how productive I felt when I first started using C#. In fact, Dart has as much affinity with C# than as with Java in my mind.
• Not having types is great. There are moments when a programmer finds themselves putting 80% of their effort into dealing with artificial class hierarchies than actually doing work. I can duck the question of which class or generic to use and get on with writing code.
• This could get messy. I hope those Dart guys know what they’re doing!

The more you can use types, the more errors you’ll catch before execution. Here’s a fuller explanation of Dart’s optional type system.

Generics

I’m old and grumpy enough not to like generics very much. They raise a lot of questions and make programmers do more work than they need to. If you’re unlucky in which examples of Dart code you encounter first, you might run away screaming because of the similarity to Java generics.

However, it’s not as bad as it looks. Dart’s optional typing manages a compromise that, though I don’t yet truly understand how it works, lets me apply as much strong typing as I need to avoid errors, without making me dance in circles trying to keep up with it.

I’ll conclude my desperately unscientific analysis of Dart types by saying that they’re doing something clever that makes typing feel more natural and gets less in the way, but because I don’t understand it yet, I worry that it might explode in my face one day.

Classes and Interfaces

Dart isn’t prototype-based, like JavaScript. Instead, compound behaviors are achieved through classes and interfaces. Much like Java, an interface defines a contract that gets implemented by an actual class.

This is probably the most confusing thing about Dart right now. For example, List is an interface. But you can use it directly, because it has a default implementation, Array. However, that’s really not clear to any newcomer just reading source that throws lists around.

I was completely stumped as to how I’d go about adding behavior to a List. As I wrote the coin-tossing example, I wanted min() and max() functions for my list items. I could extend the List interface OK, but then I had absolutely no idea how to go about providing a default implementation for these new methods. In the end I plumped for writing my functions in a Util class.

Mixins, or something similar, would be an ideal way to solve these kind of issues. Apparently they’re under consideration.

As a side note, my being forced to use an auxiliary utility class mightn’t be a bad thing. This is one of the most pernicious things about object oriented programming, you get caught up trying to fit your code into its arcane strictures rather than getting things done.

The two most valuable things Dart could add to List, or its parent Collection, would be map() and reduce() functions. 

This ain’t JavaScript

While Dart seems really familiar to a JavaScript developer, there’s quite a lot of peace of mind to be had from knowing you don’t have to worry about the crazy bits of JavaScript semantics.

One of the most-needed holes in JavaScript that Dart fills is string interpolation, e.g. “Hello ${name}” does just what any Perl or PHP programmer would expect it to.

Dart also involves a whole lot less boilerplate. Rather than

function() { }

for a closure, you can write

() { }

And one-line function definitions have a shorthand with =>, for example:

bool toss() => Math.random() < 0.5;

Though a little cryptic at first, there’s a great shortcut for constructors that do little more than initialize member variables.

Foo(this.bar, this.baz);

Interacting with the page

Dart are working on a browser API that’s more abstracted than the browser DOM, in much the same way that jQuery is. They’ve sensibly adopted the jQuery selector syntax, and it was easy to figure out how to add event handlers, e.g.

document.query("#mybutton").on.click.add((e) => print('hi!'));

Miscellaneous observations

Dart is hard to search for in Google right now, being a generic term. I found adding the word “language” to my searches did the right thing in most cases.

The API docs badly need a search. Google’s Seth Ladd says it’s coming.

It was frustrating not to have an interactive Dart console to play around with stuff. Dart’s going to need either this or a debugger as part of its 1.0 release.

Dart vs ClojureScript

As I’ve written this program in both Dart and ClojureScript, there are ways in which I find them contrasting.

• ClojureScript’s optimized code is much smaller than Dart’s.
• Dart’s browser API libraries being part of the core feels more natural than ClojureScript’s delegation to Google Closure.
• In ClojureScript I found it easier to focus on the problem I was trying to solve rather than the mechanics of object-orientation.
• In Dart, I really miss having a REPL.
• Dart’s IDE makes it easier to get started.

Conclusion

Dart looks promising. It feels web-native, and manages to bring in the advantages of modular organization and static typing without sacrificing the flexibility of a dynamic language. Dart is fun to write, which is for me an important test of a programming language.

As a pre-alpha technology, there’s a lot of flux and change in Dart right now. With Google’s backing, I give it a good chance of being a key part of web development in a few years’ time. If you want to have a say in Dart, or be a part of it, it’s a good time to start splashing around.

Check out the Dart source code for my coin-toss experiment.

For more Dart news, follow these folk on Google+: Seth Ladd, Bob Nystrom, Dart Bits.