Let’s begin with the good news. Google’s Dart is a modern, full-featured tool designed by grabbing the best features of Java, JavaScript, and C. The development team is obviously large, and the samples show they have the ambition and talent to create a system that will power desktop, mobile, and browser applications in the future. The tools are real, and the path to gaining widespread acceptance is one that Google can travel. The platform works.
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.
How will you feel about this? Programming languages are great topics for debate, and your opinion of Dart will depend heavily on your tastes. It is largely a mixture of JavaScript and Java, so anyone who feels comfortable with those languages will feel at home with Dart. There are moments when you feel like you’re coding in JavaScript, and there are moments when you are living with constructs from the Java API. The team clearly went out of its way to stick with familar structures to make it simple for programmers to adopt Dart.
Many of the decisions the Dart developers made are likely to be cheered by most JavaScript and Java programmers. Other changes will be seen as great victories by some and grave mistakes by others. Still others look like advances, but I think they create even more problems than they solve. Naturally, you might feel differently.
Any differences of opinion about Dart, though, aren’t likely to be crippling. Switching to Dart from JavaScript or Java isn’t much of a leap. There are no radical decisions or dogmatic structural impositions — indeed, you can pretty much ignore the features you don’t like because the developers aren’t on a quest to convert you. While each of us will be able to find fault with something, no one should find anything noxious enough to be a deal breaker.
Google Dart: 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 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.
Google Dart: 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 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 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 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.
Google Dart: A cleaner Web
Not all of the moves will have this effect. Almost everyone I know who writes JavaScript for the Web also uses a library like jQuery to smooth out the differences among browsers. I’m sure every one of them also wonders why someone hasn’t made jQuery part of the official JavaScript spec or permanently baked it into the browser.
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 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.
Google Dart: Will it win?
Does Dart have the charm and charisma to attract enough programmers and grow into the dominant language on the Web? There are certainly plenty of new features, and the authors did a nice job of cleaning up some of the most annoying cruft that’s getting in the way of progress in the HTML/JavaScript/CSS stack.
One roadblock facing Dart is the fact that JavaScript is surprisingly agile, and JavaScript programmers have become very adept at reforming it to be just what they want. You don’t need to migrate to Dart to get the nice class structure Google added — programmers are already experimenting with bolting one onto the JavaScript juggernaut. The jClassy project is just one example. Libraries like Dojo and YUI have nice, elaborate mechnisms for loading just the code that’s necessary. And you don’t need to wait for Dart to emulate jQuery; you’re probably using jQuery already.
The immediate plan is for Dart code to be translated into JavaScript, and this mechanism should work well enough. The code crashed when I loaded it into IE 8, but it ran smoothly when I switched over to Chrome.
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.
The good news is that if they choose to come, they’ll find a comfortable, familar structure that’s cleaner and a bit better lit than the current world of HTML, JavaScript, and CSS. The structure is pure, and maybe that will be enough to attract the hordes.
