Reports

Webcasts

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.

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.

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!