Could Server-Side Dart Replace Node.js?

Luc Perkins

July 1, 2014

Share +

Dart is a Google-produced programming language that has slowly been gaining traction, particularly since its 1.0 release last year. While Dart has thus far been seen as a promising alternative to JavaScript in the browser, I'd like to argue that like Node.js, the true promise of Dart is actually on the server side.

I too am skeptical of Dart as a client-side language, but if you cross over to the server, Google is cooking up something extremely promising and ready to carve out a large niche for itself, attracting not just Node.js developers but even developers from the Java community and beyond.

Dart on the Client: a Total Non-Starter?

Since the earliest days of Dart in 2011, the language has provoked a great deal of skepticism from all sides, primarily because Google has advertised it as a successor to JavaScript on the client side—not just another compile-to-JavaScript option, mind you, but rather a new, full-fledged in-browser runtime suited for a bold new generation of thick client applications. Sounds good, eh? Well, yes, but the skepticism towards Dart is well founded:

While the in-browser Dart VM is currently bundled with Chromium, Google has provided only very vague promises that the Dart VM will someday be included in Chrome as well. This makes Dart a hard sell.

One of the primary design considerations behind Dart has been to provide a rock solid compile-to-JavaScript story so that Dart can be used now, on any browser, even though none of the major browsers ship with a Dart VM. This is admirable and a necessary move by Google, but the problem is that the compiled JavaScript can be quite bulky. Even for basic apps, you're usually looking at over 100k, even when minified. This is a deal breaker for many, and rightfully so.

While the Dart VM might end up being superior to V8 and other engines, it's not like there's a dearth of options for client-side developers. The past few years have seen an absolute explosion in client-side JavaScript technologies, too many to even begin to mention. And so if Dart is going to have traction on the client, it will have to be unquestionably, demonstrably superior to JavaScript. I have my doubts.

Nonetheless, there are some encouraging signs for client-side Dart. Markus Persson, aka Notch, the creator of Minecraft, has thrown his weight behind Dart and has even begun building games in it, and projects like AngularDart seem to be catching on. So the skeptics might be in for a surprise down the road.

Dart on the Server: look out, Node.js and Java

As I argued above, the skeptics are right to wonder how much of a foothold Dart can gain. But let's set aside the client-side Dart issue for a minute and take a look at sever-side Dart. That's when we start to see a much different and more immediately promising picture.

The power of Java without the verbosity — Hopefully I've made it clear why Node.js devs should consider Dart. But I think that JVM folks should be paying attention as well, because Dart offers a lot of things that no Java developer could live without: abstract classes, declarative typing (which is optional), generics, a real import system, metadata annotations, and variable types that are directly inspired by Java, including final and static variables. What this means is that Dart is frankly a better constructed language than JavaScript in almost every regard and a natural fit for JVM developers who want to try something that is less verbose but also targeted at Node.js-style architectures—and who want to do so without giving up certain coveted aspects of Java.
In terms of performance, Dart is still a ways off from JVM-caliber performance and probably will be for quite some time. But the core libraries are still coming together and the performance story could be markedly different in a year's time. Dart has already performed exceedingly well on some benchmarks.

Node.js without the JavaScript baggage — I like Node.js because of the principles on which it was built: run things asynchronously whenever possible, use data streams whenever you can get away with it, and tie it all together with futures and callbacks. The problem with Node.js is that it's JavaScript. There's no distinction between types of numbers, working with arrays is always janky, NaN-infused wat moments abound, and so on.
But Dart gives you everything that's great about Node.js without the baggage of JavaScript clinging to the project like a nagging, alcoholic in-law. Dart has an incredibly robust stream API and top-notch futures support baked into the core dart:async library, plus a bunch of other stuff that you get for free, like WebSockets, SSL support, a decent math library (complete with ints, nums, and doubles out of the box), as well as the foundations for an Erlang-flavored actor system in the dart:isolate library.
Basically, server-side Dart is trying to solve the same problems that Node.js was built to solve, i.e. problems around asynchronous, non-blocking I/O, but is doing so on a better VM and with a more robust and less flaky language. Another bit of good news is that Dart in practice is highly reminiscent of JavaScript, from the basic syntax to callback functions as first-class citizens, which means that the bridge from Node.js to Dart isn't a terribly precarious one.

Other good stuff — Even though the language is young, Dart's package manager, pub, is simple and yet powerful, with clear debts to npm and its package.json-based system. If you're looking for IDE support, the makers of Dart provide their own IDE, the Dart Editor, which isn't too shabby at all on its own. I would recommend, however, having a look at WebStorm's support for Dart, which is currently very strong. And when it comes to publishing and documenting code, pub.dartlang.org is a great resource, inspired by Rubygems and related sites, that makes it easy to publish projects. For example, I've been working on a Dart HTTP client for interacting with REST APIs called Mesh, and interacting with the main Pub repository has been a breeze.

Conclusion

I'm surprised that Dart isn't yet being taken more seriously as a server-side option for a wide variety of use cases. The performance isn't quite up to JVM standards, but Dart beats scripting languages like Ruby, Python, and PHP in a variety of areas and is explicitly designed for the same architectures that Node.js is currently the best fit for. The next time you sit down to write a web server or a Markdown parser or an algorithm library, give Dart some real consideration.