Google Dart hits a bull's-eye for Web developers

When we first heard rumors of Dart, the new client-side Web programming language from Google, it was described as a "JavaScript killer," aimed at replacing a language seen as "fundamentally flawed." Those early reports spurred various reactions from the Web development community, ranging from unabashed excitement to bemused skepticism to worry that Google was trying to usurp the open JavaScript standard in true Microsoft fashion.

Google officially unveiled Dart this week, during a keynote address at the annual GoTo conference in Aarhus, Denmark. Thankfully, it seems to live up to much (though not all) of the hype, while falling far short of the worst fears. In fact, based on the documentation and tools released so far, Dart may be exactly what many client-side Web developers have been waiting for.

[ Get software development news and insights from InfoWorld's Developer World newsletter. | Sharpen your Java skills with the JavaWorld Enterprise Java newsletter. ]

Yet another Google language?

Some will doubtless say we've been here, done that. Not long ago, Google debuted a new language called Go, which was widely hailed as a "Java killer." But aside from a few presentations at Google's developer conference, we haven't heard much about Go since it was first unveiled. Is Dart likely to fare any better?

Maybe. It's important to realize that Go and Dart are parallel efforts, each with different goals. Go is a classic compiled language that outputs binaries as processor-native machine code. In that sense, it's closer to C and C++ than to Java or dynamic languages such as JavaScript. Go is intended as a general-purpose and systems programming language with some modern features, such as garbage collection and baked-in support for parallelism.

Dart, on the other hand, is a VM-based language that seems to have much more in common with JavaScript than the initial reports would have us believe. One revelation from this week's announcement was that Dart is intended to run not only in the browser but also on servers via a stand-alone VM, much like how Node.js enables JavaScript on servers. Still, most Dart code will probably be client-side, and for the time being, the way to run it is to compile it into JavaScript code that can be executed by modern Web browsers (including Chrome, Firefox, and Safari for now, with more to come).

So what's the point? If Dart applications end up being executed as JavaScript code anyway, why not just code in JavaScript and cut out the middleman?

The answer lies in Google's description of Dart as "a language for structured Web programming." If you think about it, we've never had that before. Sure, there are plenty of server-side languages that allow you to build Web applications, but on the client we're limited to JavaScript (or Flash with ActionScript, which is essentially the same thing). JavaScript began as a means of adding simple interactivity to Web pages and has mostly grown organically over the years. It was never designed for building modern, large-scale Web applications such as Google Docs. Dart aims to address some of JavaScript's more troubling aspects in a way that preserves those aspects that have made it a success.

How Dart improves on JavaScript

For example, JavaScript is a dynamic, weakly typed language that allows you to, for example, treat a numeric string as an integer and perform arithmetic on it. This makes it very easy to lose track of which variables should hold values of which types, leading to data corruption and hard-to-trace errors. You might assume that Google would address this issue by making Dart a strongly typed language, but it didn't. Instead, it added just enough type safety to make debugging easier without sacrificing JavaScript's flexibility.

In Dart, declaring data types remains completely optional. If you declare them, however, Dart generates compile-time warnings -- not errors -- alerting you of potential problems. You can also execute Dart code in a debug mode that generates errors and halts execution at runtime if type conflicts arise. The advantage of this method is that you can start out coding in fast-and-furious JavaScript style and add type declarations later, as your code base grows and matures.

Dart also differs from JavaScript in its object-oriented syntax. JavaScript is a prototype-based language, a programming style that may be unfamiliar to developers with experience in languages such as C++ and Java. Objects in Dart are defined using the more traditional classes, reducing the learning curve for programmers coming from other languages.

Other Dart differences are designed to help make client-side code easier to manage and maintain, particularly when dealing with large applications and development teams. For example, JavaScript code loaded by different <script> tags in the same HTML page all exists within a single namespace; objects and variables referenced by one script can be modified by any other. Dart doesn't allow this; each script has full control over its own state.

Also, while JavaScript tries to run whatever code it can, as soon as it can, Dart code is executed in true application style. Dart waits until the DOM is fully loaded to begin execution, and each application runs starting with an explicit main() function, as in C. These and similar features impose just enough order on programmers to help pull client-side development out of the Wild Wild West that is JavaScript.

Will you use Dart?

All in all, I'm impressed with what I've seen of Dart so far. I guess I shouldn't be surprised; in many ways, Dart is exactly what we should have expected from Google, the company that has poured more effort into JavaScript-based application programming than any other. The question is, will it gain any traction or will it remain mostly an experiment like Go?

The decision to have Dart code compile to JavaScript may be disappointing to some, but it was the right choice. Requiring a plug-in to run Dart applications in current browsers would have been a total nonstarter. No doubt Google will embed a native Dart VM into Chrome before too long, and because Dart is open source, other vendors will be able to do the same if the language has any legs.

I can't help but wonder, though, whether a new client-side Web programming language is really the answer. Google began the project out of frustration with the limitations of JavaScript. JavaScript has been around for 15 years now. Surely, after 15 years, Dart will seem similarly long in the tooth. I'd still like to see an effort to embed a more open, language-neutral VM into Web browsers that would allow client-side developers to code in the languages of their choice.

That might be wishful thinking. The more pragmatic approach is to develop tools that can improve on JavaScript today. With Dart, Google has done an admirable job of that. It's a tool worthy of any Web developer's attention, and I look forward to seeing where it goes next.

This article, "Google Dart hits a bull's-eye for Web developers," originally appeared at InfoWorld.com. Read more of Neil McAllister's Fatal Exception blog and follow the latest news in programming at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.