Google Dart

One of the big announcements this week is Google Dart, Google’s new language that’s aimed at replacing or at least supplementing JavaScript. I haven’t tried it out yet (I’m waiting until it is at least implemented in Chrome), but I’m so far pretty optimistic about it.

JavaScript is impressively easy and fast to use especially when combined with idiomatic libraries such as JQuery. When I first tried JS, I was shocked how little time it took for me to start cranking out nifty bits of interactivity and how well it worked. JQuery’s convenient functions plus JS’s seamless closures are pretty fantastic for productivity. Any language that wants to replace this needs to be able to hit those same points:

  • Simple, familiar syntax. Curly braces and semicolons are what most programmers have grown up on.
  • Closures that are so easy they you can use them without every knowing what a “closure” or “lambda” is.
  • Powerful, easy debugging. JavaScript does pretty well here, but again not really by it’s own merits. I’ve used the debuggers in Chrome and IE9 and Firebug in Firefox. They’re all pretty solid but not exceptional. Dart needs this. The hard part is that the debugger really needs to be tied into the DOM inspectors and network profiling tools. That means that the all of the browser need to implement them. That’s another obstacle for getting Dart in every browser. I assume that Google will be quick to add a Dart debugger to Chrome.
  • Great built-in API. JavaScript doesn’t really have this on it’s own, but you get it with libraries like JQuery and Prototype that are so easy to add to your project. As far as I can tell, Dart is completely missing this. This is absolutely necessary. API design is really hard, so I’d rather that the Dart developers take their time, but they can’t just leave this up to the community at large if they intend to complete.

Dart brings a couple more things to the table:

  • Even faster execution. This is nice to have (especially on the server-side and good for things like WebGL games) but I don’t really think it’s needed. As long at it isn’t any slower, it’s good enough.
  • Useful on server-side and client-side. I think this can be an important bit. I think most of the reason that likes like node.js have gained popularity is that so many people have experience and feel comfortable in JavaScript that they want to continue to use it everywhere. If Dart can be used easily in both places, that likely will increase the rate of adoption.
  • Syntactic sugar. I’m often in-favor of this, but some of the features that Dart uses worry me a bit (like the automatically-copy-arguments-to-fields thing). Someone who has only used Java or C++ can look over a JavaScript program and figure out what’s going on. Dart should be careful to avoid loosing this.
  • Sane syntax. Dart doesn’t have some of JavaScript’s craziness that make it hard for me to use (or at least feel good about using) such as automatic semicolons and strange variable scoping.

I think Dart will be a good general purpose language like BASIC, JavaScript or Java. It’s relatively simple easy to learn and that’s key for getting the “average-level” programmers to try learn and use it.

Additionally, I really don’t like Ecma’s current plans of a glacial evolution of Javascript. I think sometimes a breaking change is the best option. So far, Dart is the first language that I’ve really liked as an alternative.