Dart fixes a number of problems with Web programming, but introduces new problems of its ownFollow @peterwayner
But I'm not as thrilled as some Dart developers are about the way the team cleaned up the event connection code. The old way of simply putting an extra attribute like
onclick into the HTML tag is gone. Now you have to add event listeners to the DOM element in the Dart code. The Dart team argues that this is cleaner because you might want to have several functions receiving the events.
I shouldn't complain about too many possible paths -- as I do in other places of this review -- and then grouse when Google prunes some of the options. It's just that it was very handy to have the method call inside the HTML tag itself. When I poke around some Dart code and try to figure out where the clicks are going, I need to first find the name of the element and then search through the code for methods that are attaching themselves to that element. It's cleaner, but it makes debugging a two-step process.
Google Dart: Will it win?
But there may be deeper practical issues. The very simple program that prints "Hello World" is converted into 231,503 lines of code, many of them fairly long. I pushed this code through the built-in optimizer, and the result was still 183K. This overhead, or the ensuing bandwidth bills, will give developers for any popular site a reason to pause.
That will change if and when Dart is built into the browser. That day will probably come relatively soon, thanks to the way that Google is open-sourcing the code for Dart. The rest will be up to Web programmers.