Alex Hudson

Thoughts on Technology, Product, & Strategy

Speculation on Google’s “Dart”

Just yesterday people jumped on the biographies and abstract for a talk at goto: the Keynote is Google’s first public information on Dart, a “structured programming language for the world-wide web”. Beyond knowing a couple of the engineers involved – which allows a certain amount of inference to take place – there’s also some speculation that Dart is what this “Future of Javascript” email referred to as “Dash” (this seems entirely possible: a dash language already exists; Google already used ‘Dart’ for an advertising product but have since stopped using that name, potentially to make way for the language).

I thought it would be interesting to have a look at some of the details of this new language. One thing seems quite certain: Google’s Javascript engine, V8, is going to target this, because it’s going to target client-side application programming to begin with. V8 is, of course, very popular – it’s in Chrome, it’s in Node.js, it’s going to be put in Qt. However, it hasn’t really been a brilliantly standalone project (witness the problems getting Chromium into Fedora, as an example) and the addition of Dart will almost certainly make this worse.

So, what else do we know?

Compiles to Javascript

It seems likely that the language will, at least in a proper subset, compile into Javascript – a lot like Coffeescript does. Personally, I cannot stand Coffeescript for the same reasons I really don’t like python, but there is some obvious win to this approach: you get backwards compatibility with existing systems and, usually, a method of interacting with existing code and libraries.

I suppose the first question is, how different to Javascript will it be? It will almost certainly be object-oriented, but that need not imply prototypical inheritance – it could be the Javascript compiler will do some fancy trick with object to make things appear more classical. Coffee does this to a large extent too, and I think we’ll see a similar approach. I doubt much of Coffee’s syntax would be copied – it’s almost Perl-like in its terseness sometimes – but I think there will be a similar approach to the object model.

There will be other differences. Javascript is relatively typeless, I suspect Dart will have types of some sort at least optionally. The scoping rules will probably be a bit different as well – the “let” keyword has never caught on wildly, but some level of block scoping (as an example) would be an obvious improvement.

Not just a language

I think it’s relatively clear from the “Dash” discussion that this isn’t just going to be a language: templating and possibly even MVC will be available alongside, some how. I expect to see some interesting things here, actually – there might not be much impact on the language (although a way of embedding HTML templates might be handled specially) but I think it will be closely aligned to these key tools. The Javascript world has been doing some interesting stuff – see Backbone.js and Knockout.js as two obvious examples – but it will be really interesting to see how much “platform” is put into Dart.

There is a worry here, of course, that it’s too restrictive. Knockout is actually a great example: it’s MVVM architecture, not MVC, and for a lot of jobs I’ve actually been really, really impressed with it. It’s simple, straightforward, but most of all productive. It would be a shame if you can’t do something similar in Dart, but I would bet you can. Binding data onto a web page is so fundamental, so basic, that I really think there will be some interesting stuff there.

Binary Dart?

I’m not really sure about this, but I’ll chuck it out there anyway: clearly, writing Dart in a text editor is going to be fine. However, I also expect that there would be alternative delivery mechanisms. Right now, people use tools like Closure to “compile” Javascript into a more compact representation. Clearly, if you’re starting with a new language, you could specify a binary format right from the start. This would also sit beside NaCl/Pepper quite nicely, and allow multiple resources to be included into a project without having to have multiple file downloads into the browser.

Google are going to be focussed on deployment of large, highly-interactive apps, I think – so although the small page enhancement stuff would still be on the table, really I think Dart is going to be about writing GMail and Google Docs. In that context, being able to wrap up everything into a nice deployment package makes a whole heap of sense.

A month to wait?

Sadly, I don’t think we’re going to know too much more before goto;. I had a look around the V8 source, there aren’t really many clues in there to what’s coming. If they’re offering a compile-to-Javascript option, that might be the only thing released at first – so Dart would effectively be a standalone compiler only to begin with, growing features to target specific engines later on.


The quality of Fedora releases


Is package management failing Fedora users?

1 Comment

  1. Javalike

    Google is big but Javascript belongs to all developers not Google. if you think you have better ideas, then create a language and a compiler to compile your better language to Javascript! It is way better for all of us! Don’t make another JAVA out of javascript.

Leave a Reply