There really isn't any obvious bad news, but there is plenty of cold, hard reality that appears after one plays with the code for a bit. The documentation is upbeat and highlights how Dart is fixing the pet peeves of the Dart creators, peeves that many of us probably share. But the Dart developers are not superhumans, and they did not find new breakthroughs to taming the way that software turns into a jungle of vines. At best, it's not even clear that they did more than remove some hard corners and smooth over some rough edges. Their fixes work for them, but like all fixes in laws and software, they're bound to create new problems down the road.
Art of the familiar
Before I give my opinion about the type system in Dart, I want to explain that I began this project after spending two solid days trying to chase down a crashing bug in an Objective-C program that appeared after I upgraded a library. My code didn't change, but it started crashing in one small, yet crucial corner. The new version of the library renamed one of the objects that my code used as a base class, but I never noticed.
The Objective-C compiler probably noticed, but it didn't bother to tell me it couldn't find that base class anymore. Nope, it built my code and gave me a high five, perhaps because someone thought that the word "objective" means not sticking your nose into others' conflicts or taking sides of any kind. After a few days of fiddling, I found the conflict and the code stopped crashing.
Given that, you can imagine how overjoyed I was to read Gilad Brancha, one of the Dart developers, write in the Dart documentation, "Your program will have exactly the same semantics no matter what type annotations you add." Wow. Thanks for nothing, literally. In response, some jokers suggest that Google just wanted to save you the hassle of putting comment marks around the type annotations.
It turns out that Dart doesn't throw the type information into the bit recycling bin. You can ask it to run more slowly and check to see if the types of the data actually agree with what you suggested. There's even a static checker that preprocesses the file to flag some of the problems. The Dart authors also suggest the compiler might do a better job if the type information is there, but that awaits a future spec.
Some people will see this as ideal. I've known many smart and capable programmers who hate type systems. What I see as a helpful exoskeleton of logic, they see as a rigid pain in the neck invented by programmers who want to get paid by the keystroke. Dart offers them most of the power of type checking if and when they want to deploy it. If they're just having fun and writing something simple, there's no need to be too verbose and specify the type. People like me, on the other hand, can add types to everything and it might help catch some bugs. This kind of flexibility is ideal for the lone coder because the lone coder can choose their favorite path.
A deeper question is whether Dart and this new freedom will really make it easier to get teams together to write big programs. There's no doubt that the careful namespaces and class structure add nice firewalls that prevent collisions. That discipline is something that's bound to help most people.
But can all of the other new features and flexibility help larger teams? In some cases, the syntactical shorthand may sow confusion. In others, the devil-may-care attitude toward typing will leave team members at odds with each other because flexibility isn't always a good idea for keeping people on the same path.
Structure and freedom
I've worked on several teams where the leader was a real whip cracker who drafted long lists of annoying rules. Each statement had to be on its own line. Each constant had to start with a certain letter. There could be no chaining of method calls because it made stepping through the code difficult during debugging. Everyone hated the rules and the rule maker, but the code was much more consistent and readable.
Dart seems to be taking the opposite approach. There are often several ways to say exactly the same thing. Functions are first-class objects and they're tossed everywhere. Constructors take various forms. Of course you can also get your own whip cracker to come up with tough rules and jam them down the throats of the coders, but we can already do that with the existing languages. If anything, Dart is offering more ways for programmers to develop their own secret idioms, then get cheesed off when the other coders can't grok their infinite coolness.
Dart's simplicity is not always an advantage either. The Dart team tossed away the word "function" from the declaration of a function, now all you need to do is list the parameters between parentheses. As I read the Dart code, I found myself thinking like a parser to determine whether the parentheses were declaring a function or acting algebraically. The word "function" may be a pain to type repeatedly, but it's a helpful marker when you're reading the code. What speed we gain when writing the code, we lose when reading it. Of course if you're really going to ignore the type system, you can just create a new class called "function" and have every method return it.
It may be my inexperience with Dart, but at times I felt like I was dealing with the same kind of mad geniuses that invented Lisp or APL. They too worshipped the beauty of some minimal collection of keystrokes that were actually intricate mechanisms delivering the answer with deft precision. Yet those languages have been disasters in corporate environments. The fun that lone programmers can have with clever code tropes can't make up for the confusion that everyone else in the team feels until they figure out the inside move.
A cleaner web
The developers of Dart heard these cries and added most of the goodness from these libraries to Dart. They've gotten rid of the lengthy names like getElementsByTagName and replaced them with a catch-all function called query that takes jQuery-like parameters to find what you want.
They've also smoothed out the internal data structures describing the DOM. The fields of each DOM element now use standard data structures. That means you don't need to remember method calls like hasChildNodes and firstChild. You just need to know that there's a field "node" that responds to the standard collection methods. These seem like perfectly obvious solutions and I'm thrilled with them.
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.
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 optimiser, 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.