Channels ▼

Web Development

Can Google's Dart Hit Its Target?

In recent blog posts, several pundits have wondered whether Google's programming language Dart might be the future of the Web. I will pause here to allow time for the guffaws and coffee-spitting.

More Insights

White Papers

More >>


More >>


More >>

Many folks might argue that Dart is presently very far from being the future of anything. Some people might doubt that Dart has any significant future itself. I think they're wrong and that the pundits might well be right, or partly right. If you're not following Dart development, you're not getting the whole story. Dart definitely has its supporters: Many developers, within and outside Google, are enthusiastic about the language. I edited a book on the language myself, and I follow several blogs on Dart development. Dart recently crept up into the TIOBE Programming Community Index top 50 for language popularity, although now it's back down in the 50 to 100 pile, along with Dylan, Occam, Simula, and another Google language, Go. Yes, I know. You'd think that languages developed by Google could attract a few more users.

I have to think that Dart's lack of popularity is at least in part due to the fact that it's just not a very exciting language. And it has grown less exciting over time. Programmers who really wanted to love Dart tell me that its developers have made a number of boring and disappointing compromises. Nevertheless, as I say, I think Dart could be the future of the Web — for at least one significant group of Web app developers.

Let's backtrack a bit. The stated goal of Dart, according to its developers, is "ultimately to replace JavaScript as the lingua franca of Web development on the open Web platform." JavaScript has some limitations for large-scale Web applications, they claim, and Dart's purpose is to remedy those shortcomings.  

Well, yes. It's hard to argue with the Dart team's contention that JavaScript is imperfect. And it's hard to fault them for attempting to overcome JavaScript's shortcomings. And it's not a totally crazy position that the JavaScript ecosystem is so overgrown with weeds that the best plan is to plow it under and plant anew.

So, what's the Dart plan? Dart's developers decided to provide two scenarios for Dart use. These scenarios are not equally exciting or equally likely. In one scenario, browser creators support the Dart virtual machine, allowing you to write native Dart code both server side and browser side. This lets you create large-scale, full-stack Web applications that run lightning fast.
That's a pretty cool idea. But, that's not going to happen.

OK, I can't predict the future, but if it is, then some major attitude changing is going to have to take place. If you listen to the developers of any major browser not developed by Google, they are all, without any exception that I'm aware of, adamant that they will never support Google's proprietary language in their browsers. Not gonna happen.

But really, that doesn't sound like an "open Web platform" vision anyway. In the other scenario, you write your Web applications in Dart and compile them to JavaScript, and they swim in the familiar waters of Web application development today. Sort of like working in CoffeeScript.

Let's reflect on this second, more modest, scenario for a moment. Dart is not an exciting language in itself; the VM implementation is going nowhere; and in its compile-to-JavaScript incarnation, it effectively does what Coffeescript does, but with a steeper learning curve. This can't possibly be the future of the Web, right?

Well, it could be. The promise of Dart, according to its developers, is reliable, high-performance, full-stack Web applications. Reliability and performance are the Achilles' heels of JavaScript (and if you have two Achilles' heels, you're pretty vulnerable). The reliability part comes from constraints: Dart's generated JavaScript is going to be safer than the average JavaScript out there because the Dart team designed Dart that way.

Dart still could be a winner if it turns out to be the best way to move beyond JavaScript for large, complex, performance-focused Web apps. For that, it needs to deliver on both those goals: reliability and performance. Especially performance. So, this news from a recent edition of the Dart newsletter is promising:

"Dart has recently received two bumps in performance, and now both the Dart VM and generated dart2js code is faster than hand-written JavaScript in the DeltaBlue benchmark."

What this is saying is that Dart is generating JavaScript code that runs faster than JavaScript code. Not "any possible JavaScript code" obviously, but real-world JavaScript code.

That's what Dart needs — for the compiled JavaScript to be more reliable and faster than JavaScript you'd write yourself.

If it can do that, browser makers don't need to drink the Dart Kool-Aid and Dart can go right on being a boring language. Its future as a high-end Web application language will be bright.

For many years, Michael Swaine wrote the "Swaine's Flames" column in Dr. Dobb's Journal.

Related Content

See our feature article on Dart, which discusses its rationale, goals, and the technologies that make up the language.

Related Reading

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.



Although I agree with most of this article, (which was good read btw), I don't see why Dart is boring ... it depends on who uses it and how one uses it ...
For example, Dart can be very expressive with it's "auto cascading" features, operator overloading, etc ...
(I also think c++ is very nice and some might call it boring).

I think the majority of web developers who aren't convinced about Dart's future probably haven't read about it enough, if you gave CoffeeScript a chance and TypeScript (I like it too, no offense but it's quite surprising to see everyone go all emo about a JavaScript "superset" that looks like ActionScript 2.0 and a mix of C#, given all the crap Microsoft have made so for when it comes to front end development, IE 10's development tools are still as bad as in IE8, but everyone loves TypeScript) ...

As for "replacing JavaScript", I don't think that's still the main goal behind the project, and everyone has to admit, the Dart team has done a pretty good job ... There's no one who knows V8 better than they do, so I think that concerning performance we can at least trust them and give Dart a try.

Dart is fun and has it's place as much as TypeScript or CoffeeScript ...and if never makes it to anywhere at least as far as code goes, it is a really nice project.


Well said.

The list of languages that compile to Javascript includes: C#, F#, VB, Java, Python, Ruby... in fact Github's list of languages that compile to Javascript is pretty eye opening. Basically, if you have ever learned a programming language, you can compile it to Javascript.

Plus Google is scary. One day they are pushing us into something and the next day they are either charging for it or shutting it down. They seem to have no road map, and I don't know that I would trust it if they did.

And given that Google can't get along with anyone else, including Apple, Microsoft, Amazon and even the Chinese government for heaven's sake. You have to wonder if what you are building today in Dart will still work everywhere tomorrow.


It's so difficult to find the way to go with web/mobile apps. I looked at Dart, but when I saw it had such limited support for server-side databases (esp Postgress) I decided to give it another six to nine months before I try it out. I'm looking at Meteor right now. However, I'm most likely to go with Lift on Scala.

What I really want is something like Seaside on Smalltalk that runs on the JVM. Dart is actually quite close to that, in that you could build a similar framework quite easily. I just find it sort of odd that the Dart developers would leave something so important as persistence to the user community to develop.


ClojureScript/Clojure is another alternative.


If Dart were the only compile-to-JavaScript game in town, it would get some traction. But that field is getting increasingly crowded. Now that JavaScript is a LLVM target, the last holdouts, C and C++, are a viable alternative to Dart. Meanwhile we have TypeScript from Microsoft, which has the advantage of strong interoperability with hand-written JavaScript. And we have Kotlin and others which target both JavaScript and JVM.

Dart would have to bring something pretty special to the table to compete these days.


I don't see it going anywhere.

Most languages get into mainstream due to some killer library/framework that makes people want to learn the language, or get imposed to the developers as a means to target certain platforms.

Dart is neither, and the compile-to-Javascript field is already crowed with every possible language, so what is Dart's advantage there?


I think Dart is one of the best things to come out of Google lately. I do think though it is unjustly receiving a "yeah whatever" from the dev community. The Dart team really needs to allow devs to use Dart to build web and mobile (i.e. native android) apps and providing a UI widget library. That would be huge in winning over developers. Unfortunately the only thing that ever keeps coming from Seth and Bob is..."we only have so many resources and we're focused on the web right now."

While I have much respect for the Dart team excuse me for saying that is one of the dumbest goal statements I have ever heard. Hellooo its 2013 and mobile development is hot hot hot!!! Dart was conceived of back in what late 2010 or early 2011. Again mobile development was taking off at that point. Providing a mobile framework should have been #1 on the list.

But hey this is all just one guys opinion. I don't know their entire game plan (which I'm sure includes Chrome packaged apps). So lets just hope they hurry up and "get the web right" so they can move on to tying Dart into Android.

Besides as much as I like Dart I think Portable Native Client apps is going to also be really cool if it ever goes mainstream.


Assembly code is untyped, and we can translate HLLs into it without any problem with types. When was the last time your C program tried to add a float and a string without your casting something? I think dart2js is a fine way to bootstrap Dart to existing browsers. I wouldn't want to count out a Dart VM, though. Look, all browsers have the ability to do plugins, right? They can display pdfs and stuff llike that, calling into a .so, .dll or .dylib, right? Is it possible to implement Dart with a native code plugin? I don't know but I wouldn't be terribly surprised.

Dr. Dobb's TV