DART – Google’s new programming language of tomorrow

The opening keynote at this year’s GotoCon in Denmark gave us our first view of Dart, Google’s new programming language. This post is about the findings and discussions that were circling at the conference, starting with why this has come about in the first place.

Javascript has had a colourful history. It hasn’t always been as fast and easy as it is today, and the varying implementations of it have sometimes been painful to work with. Thanks to faster VM’s and tighter ECMA standards, Javascript is on around 2 billion devices and the tool of choice for many web developers. The new specs are exciting and soon we’ll have static typing, classes, and lots of other highly in-demand features as detailed by Alex Russell‘s talk at Goto, which directly followed the Dart keynote.

Google’s Javascript engine, V8 and it’s head programmer Lars Bak, had a significant role in providing the community the ability to run relatively large, complex applications using Javascript. It is the engine used in Chrome, and the fashionable NodeJS. Some would say that Lars took Javascript, and made it fast. It wasn’t his first time either; similar VM’s were created for Smalltalk and Java. Unsurprisingly, Lars is also an instrumental part of Dart.

Looking at Dart, then. It is, as expected, a statically typed language. You can however still continue to write code in a dynamically typed fashion (a la Javascript) if you so wish. Dart runs in its own VM, but can be converted to Javascript using DartC, although early indications aren’t very complimentary at the time of writing this.During a later Q&A session, the guys explained that the code excess was due to the fact that the technology is still in alpha and not a realistic view of what the final product would output. For more details on its specifics, visit the docs.

It seems there is also a misconception arising that Dart (and its snapshotting) will make everything lightening fast automatically. Sadly, although there will be advantages, Dart will still be driving the same gears that are rendered on the browser and therefore does not mean that the components, such as Canvas, will be any faster than they are with Javascript.

What about the Dart specification and browser adoption? When asked if they were going to open up spec contributions to the wider community, they responded, “without other browsers adopting Dart’s VM, whats the point in opening up the spec to a community of one?” Although it wasn’t said explicitly, it raises the most important point for Dart; will the Mozilla’s and Microsoft’s of the world ever want to adopt a Google-backed VM?

If Google are going to take on Javascript, even though in their words, “the competition is not Javascript,” then I can’t help but feel they haven’t gone far enough. What is the competition, then? Primarily, they say it is the issue of fragmented mobile platforms and implementations of Javascript, which I think everyone agrees is a real one. According to Google, Javascript is too slow to load (think Gmail), and that this is restrictive for what we can achieve on mobile devices and (relatively) low memory. Whether this is enough of a reason to switch to an entirely new tool is for the jury to decide, and we are yet to see an implementation of Dart on any such devices. Overall, it looks to be a familiar language to work with, but also looks like a Javascript wish list of what is already in the pipeline from ECMA.

Perhaps the biggest potential would surface if Dart also went server-side, which it does look like there’s plans to do so judging by the leaked internal memo that kicked this whole thing off.

– Front-end Server — Dash will be designed as a language that can be used server-side for things up to the size of Google-scale Front Ends. This will allow large scale applications to unify on a single language for client and front end code.

Of course Dart may or may not prove to be a better tool for that job than Javascript is but either way, it is a good thing. It is a good thing because it gives Javascript a kick up the rear. All languages must evolve in order to keep up with its even faster evolving environment, the web. Whoever ‘wins’ will have helped the development world towards this and I look forward to it.

The postings on this site are the thoughts and opinions of the individual contributors and do not necessarily represent the positions, strategies or opinions of R/GA, The Interpublic Group of Companies, Inc, or their clients.