Ok, everyone, let’s all calm down. There’s been so many blog posts and podcast debates all over the net about what’s wrong with Dart. The only problem with Dart, the way I see it, is that Google is too good at marketing: too much hype before we got to see the product.
The way I see Dart, it’s another language for doing client-side web application programming. Luckily, it’s not another Flash or Silverlight with its plethora of languages. It would like to be a part of the browser, but for now it contends itself to being a language that compiles down to JavaScript. That puts it together with CoffeeScript and Objective-J, to name but a few. See a long list here. As you can see from the list, this is nothing new.
The only problem with Dart is that everyone had their hopes up for the perfect language that would contain all their pet features. And of course, the set of preferred combinations is probably as big as the number of developers in the world.
What I find to be one of the strong points of Dart is that it uses the actor model as its concurrency model. I remember it well from my days at uni, thinking it was a model leading to waaay to much overhead. Surely, the Smalltalk guys must be mad! But as time has given us more power, I’ve come to believe that this is a great model, which has lead me to Scala and Akka. Although GCD is very powerful, I find myself looking into using actors in my language of choice, Objective-C, all the time.
So where does Dart go from here? Well, that depends on what kind of backing it has from Google. Google hasn’t been very clear on how well the Dart support is grounded in the organization. But if it gains a good community of libraries and evolves a good community, it could become the preferred way of writing Android apps, letting developers re-use code for their web-app and mobile app. If not, it could become shelved like Go.
Personally, on this front I’ll brush up my ancient JavaScript skills and look more at SproutCore the next couple of weeks, probably along with CoffeeScript. Then in a month or two, if there is any momentum going for Dart, I’ll probably write something where I can exploit Darts actor model and see if we become good friends. 2011 will be interesting still.







Get it here
> The only problem with Dart is that everyone had their hopes up for the perfect language that would contain all their pet features. And of course, the set of preferred combinations is probably as big as the number of developers in the world.
Another argument for Polygot Client — aka “support the language attribute in the SCRIPT tag”.
Why shouldn’t I use Scheme or LUA to code my browser game? Why shouldn’t I use Ruby to code my client-side webapp? Why shouldn’t my “learn to program” app teach Logo? Why can’t we have scratch.mit.edu or kidsruby.com programs running in browsers? Why does rubymonk.com need a “send code to the server” hack? And why does testfirst.org need to use git clone instead of running inline?
Since JS is the only game in town, browser engineering effort is focused on optimizing JS interpreters. With a tiny little shift, all that effort could be turned to a generic VM (like LLVM or even JVM) which compiles any number of languages into a common bytecode and then runs blazingly fast and efficiently. An ecosystem of tools and standards could arise around debugging and optimizing and porting and emulating this VM.
Hi Alex,
Not sure how much it would grow the browsers to support all of these. I mean, I have llvm laying around, but I don’t expect everybody to, so it could be a fair bit extra.
That would indeed be very cool.
Cheers
Nik