In 2006, Google released a software package called Google Web Toolkit (or GWT). It allows you to write browser-based applications in Java. While it is still in use today, it never really caught on. GWT is just another software technology, one of many, that litters the web landscape.

Seven years later, Google released another software package called Dart, which has pretty much the same goals as GWT. It allows you to write browser-based applications in the Dart language. Both can compile to JavaScript that runs on all browsers. Both can run their applications within a virtual machine (or VM). Both try to capitalize on developers’ familiarity with Java (to which Dart bears a strong syntactical resemblance).

The question is: Why should Dart catch on now, when GWT couldn’t? While Dart has improved on GWT in many ways, these are all design tweaks that do not address the much bigger issues holding back both platforms.

For Dart to succeed, to become a strong alternative to JavaScript in the browser universe, either the Dart VM must be built into all browsers, or Dart’s JavaScript output must run on all browsers. The former is highly unlikely, as Microsoft, Apple, and Mozilla will never support Dart for political reasons. Why cede control of the web to Google?

Forget the naive plan to use a Dart-enabled Chrome to showcase Dart applications and attract a major user migration (thereby giving Chrome’s competitors a swift kick in the rear). This plan can only work if Dart applications are ubiquitous or if a few “killer” Dart applications take the world by storm. The latter is a faint hope, and the former is unlikely (the classic chicken-or-the-egg dilemma). Users of the web must be shown the actual utility of Dart applications.

Compiling to JavaScript is a non-starter because, as of this writing, it only supports the latest browser versions. We cannot expect everyone in the world to be running the latest browser versions, and to disfranchise even a small minority of web users is unacceptable. Moreover, the JavaScript output will never run as well as the Dart VM, and non-Chrome users will be annoyed that they’re treated as second-class citizens. (“Works best in Chrome” is not a mantra that will gain converts.)

I understand that Dart is playing the long game. It’s preparing for the day when the JavaScript issues I mention no longer matter. But until then, Dart is dead in the water. It’ll keep company with GWT.

Dart on the Server

What about Dart on the server side? Can it fare well there?

Dart would be competing with the Go language, which in my opinion is a far superior language. Go is much simpler, much cleaner. Go compiles lightning quick, giving it a dynamic feel. Go code runs much faster. Go has mandatory, not optional, static typing (optional typing has rather limited value).

Moreover, Go is a much more mature language (as of 2014, 5 years versus 1 year old). The Go user community is much larger and more vibrant. The Go ecosystem is much richer. For example, Go has two major web frameworks, Beego and Revel, whereas Dart has Rikulo Stream, the only framework I could find that could be called “mature” and reliable, i.e., has staying power and won’t disappear in a few years. (Incidentally, according to TechEmpower, Stream performs poorly, as do Dart and the Start framework.)

I see no reason to choose Dart over Go on the server side.