HTML5 Zone is brought to you in partnership with:

Dr. Axel Rauschmayer is a freelance software engineer, blogger and educator, located in Munich, Germany. Axel is a DZone MVB and is not an employee of DZone and has posted 246 posts at DZone. You can read more from them at their website. View Full User Profile

Google Dart to “ultimately ... replace JavaScript”

  • submit to reddit
The following keynote will be held at the GOTO Aarhus 2011 Conference on Monday, Oct. 10, 2011:

Dart, a new programming language for structured web programming

This post explains what Dart is all about and how it relates to JavaScript.

Google’s strategy for JavaScript

Unless another source is mentioned, all of the following quotes come from a Google email that was written in November 2010. It summarized a Google-internal discussion:

On November 10th and 11th, a number of Google teams representing a variety of viewpoints on client-side languages met to agree on a common vision for the future of Javascript.

The agreed-upon “common vision” was to develop a new programming language called “Dash” (which was later renamed to “Dart”).

The goal of the Dash effort is ultimately to replace JavaScript as the lingua franca of web development on the open web platform.

In order to minimize the risk of failure, Google will hedge its bets:

Javascript has fundamental flaws that cannot be fixed merely by evolving the language. We'll adopt a two-pronged strategy for the future of Javascript:
  • Harmony (low risk/low reward): continue working in conjunction with TC39 (the EcmaScript standards body) to evolve Javascript
  • Dash (high risk/high reward): Develop a new language (called Dash) [...]

Dart (originally Dash)

Dart’s goals are (quoting verbatim from the email):

  • Performance – Dash is designed with performance characteristics in mind, so that it is possible to create VMs that do not have the performance problems that all EcmaScript VMs must have.
  • Developer Usability – Dash is designed to keep the dynamic, easy-to-get-started, no-compile nature of Javascript that has made the web platform the clear winner for hobbyist developers.
  • Ability to be Tooled – Dash is designed to be more easily tooled (e.g. with optional types) for large-scale projects that require code-comprehension features such as refactoring and finding callsites. Dash, however, does not require tooling to be effective--small-scale developers may still be satisfied with a text editor.

There will be several ways of running Dart:

  • Dedicated VM: as a substitute for JavaScript, in all browsers.
  • Server: with the goal to enable “Google-scale” web applications where front end and back end are written in the same programming language.
  • Cross-compiler: that compiles Dart to ECMAScript 3 on the fly, for compatibility with non-Dart browsers. Compare to Google Traceur [2] which compiles [1] to ECMAScript 3, in a similar manner.
The FAQ at the end of the email makes it clear that Google intends to use Dart wherever it can (at least in the web space). It also makes it clear that Google expects the migration from JavaScript to Dart to take a while. There will be a tool to help with the migration:

The Dash Cross Compiler should be capable of taking typed Closure code (with some restrictions) and converting to Dash. Although the migration process won’t be fully automatic, it should make moving over to a Dash codebase somewhat easier.

Hidden in the FAQ: Google is working on a “cloud IDE (Brightly)”.

Brightly will enable building any web application in V1 using today’s Javascript plus the additions in Harmony. As soon as it is ready, Brightly will support Dash as well. We expect that the more prescriptive development aspects of Brightly that will come on line in the future will be more Dash focused.

We expect Brightly itself to be the first application written in Dash.

What does it all mean?

Consequences for [1]. With Google considering to be merely a stepping stone for Dart, I expect them to be conservative about new features (the above mentioned “low risk” approach). They will be most interested in features that make it easy to compile Dart to ECMAScript. That is a real shame, because a lot of innovation is happening in ECMAScript development and things are progressing quickly and pragmatically.

Will it be technically sound? The three goals for Dart are spot-on. I love that they are focusing on toolability, an area in which JavaScript currently has severe deficiencies, especially compared to Java. The goal of “developer usability” ensures that the language will remain lightweight. There are brilliant people working on it – that have both compiler expertise and language design expertise:

Who authored this document [the email introducing Dart/Dash]?

Brad Abrams, Erik Arvidsson, Lars Bak, Darin Fisher, Dimitri Glazkov, Dan Grove, Peter Hallam, Bruce Johnson, Alex Komoroske, John Lenz, Kasper Lund, Mark Miller, Ivan Posva, Alex Russell, and Joel Webber, who collectively represent TC39 (the EcmaScript standards body), WebKit, Parkour, Brightly, JSPrime, JS++, Closure, JSCompiler, V8, Dash, Joy, and GWT, among others.

For example: Gilad Bracha has great taste in language design, his work on Newspeak and pluggable type systems [PDF] is exemplary. Newspeak is currently the best guess for what Dart will look like – given that both of the presenters at the GOTO conference have worked on Strongtalk. Strongtalk is a language that added an optional static type system to Smalltalk, a dynamically typed language. This approach would go together well with the Dart goal of “developer usability”. Newspeak is in many ways an evolution of the Strongtalk ideas. Furthermore, an IDE has always been at the core of Newspeak’s design which jibes with the “ability to be tooled” of Dart.

Will everyone adopt it? Google does not make it easy on the JavaScript community. Quoting a tweet from JavaScript creator Brendan Eich:

[...] the problem is Google's imperious non-open (delayed-open, but all the devs are employed) ways.

Dart is another piece of Google software that is almost proprietary: It is not developed in the open and only shown to the public once it is finished (Eich calls this “delayed-open”). And all of the developers work for Google. It will be free (which is great and will help its popularity), but heavily controlled by Google. This approach reminds one of Android where recently an internal email has leaked that demonstrates that things are not always as innocent as Google likes to pretend. The following two bullet points are verbatim quotes from the email.

  • Do not develop in the open. Instead, make source code available after innovation is complete
  • Lead device concept: Give early access to the software to partners who build and distribute devices to our specification (ie, Motorola and Verizon). They get a non-contractual time to market advantage and in return they align to our standard.

Going back to the Dart/Dash email, Google’s plan for involving other browser vendors sounds a bit naive:

What if other browsers don’t follow us with Dash?

Lars has promised to “sweet talk” the other browser vendors and, while we are all eager to see this, we recognize this is a very difficult road. Our approach is to make an absolutely fantastic VM/Language and development environment and build great apps that fully leverage it in order to help other browsers see the wisdom in following. Once Dash has had a chance to prove its stability and feasibility, we are committed to making Dash an open standard with involvement from the broader web community.

So the idea is for Google to get a head start and then convince others of adopting it? Not really the most socially sensitive plan. One should also remember that even if the Dash source code is eventually open, porting it to other browsers is far from trivial.

It is not a good sign that Brendan Eich, a guy who really works his behind off to involve the community in the design of has not been approached, yet. He should be the first person for Google to target with their “sweet-talking”. Oh, and how is that for sweet-talking [emphasis is mine]:

Why are you circumventing the standards process?

We fully intend to cooperate fully with standards processes--the problem is that the current standard processes are limited to Javascript, which is not viable in the long term. Any effort with the historic baggage that Javascript has will be extremely limited. We need to make a clean break, make progress, and then engage the community.

That is an incredibly simplistic statement. How can they possibly predict what JavaScript will look like in the long term – a language that is currently very minimal and thus easily extended? The above statement would also sound better if Google mentioned their own motivations, something along the lines of “we want to try something different and to (initially) go it alone”.

Isn’t Dart similar to CoffeeScript? Yes and no. To run either Dart or CoffeeScript [3] on a JavaScript engine, you will have to perform a translation step. However, CoffeeScript intentionally stays close to JavaScript semantics which means that it is a transpiler (only local transformations), while Dart will probably need a compiler (that makes sophisticated non-local transformations). Source-code-level debugging is in store for CoffeeScript [4], but it’ll be much harder to implement for Dart. Thus, Google Chrome with a dedicated Dart VM will probably be the best way to run Dart for a long time and that could seriously fragment the open web (which has made incredible progress, language-wise, with ECMAScript 5 and [1]).

More voices on Dart

Brendan Eich:

Here is something that the Google leak about Dart (née Dash) telegraphs: many Googlers, especially V8 principals, do not like JS and don’t believe it can evolve “in time” (whatever that might mean — and Google of course influences JS’s evolution directly, so they can put a finger on the scale here).

They’re wrong, and I’m glad that at least some of the folks at Google working in TC39 actually believe in JS — specifically its ability to evolve soon enough and well enough to enable both more predictable performance and programming in the large.

There’s a better-is-better bias among Googlers, but the Web is a brutal, shortest-path, Worse-is-Better evolving system.

I’ve spent the last 16 years betting on the Web. Evolving systems can face collapses, die-offs, exigent circumstances. I don’t see JS under imminent threat of death due to such factors, though. Ironic that Google would put a death mark on it.

Gilad Bracha
[one of the people behind Dart]:

Lots of speculation about Dart; few facts. All will be revealed at GOTO Aarhus.

More from Eich
on Hacker News (part 1/2):

On Dart: Google as a single entity does not know what could be done in Ecma TC39, since the Dart/V8 principals never participated, and V8 needed a fresh-thinking second team finally to get going on Harmony prototyping.
Innovating in the open and proposing early and often to standards bodies are fine. Delayed-open-washing and increasing piles of proprietary (open-source doesn't matter) single-vendor code, which implements features that are not ever proposed for standardization, are not.

More from Eich
on Hacker News (part 2/2):

For the record, I'm not worried about JS being replaced by a better language. I am working to do that within Ecma TC39, by evolving JS aggressively.

The leaked Google doc's assertion that this is impossible and that a "clean break" is required to make significant improvements is nonsense, a thin rationale for going it alone rather than cooperating fully.

The big issue I have with Dart, which you seem to consider inconsequential, is whether Google forks the web developer community, not just its own paid developers, with Dart, and thereby fragments web content.
Dart is GBScript to NaCl/Pepper's ActiveG.

Published at DZone with permission of Axel Rauschmayer, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Kevin Peck replied on Mon, 2011/09/12 - 11:40am

Seems like all languages hit some sort of a wall when it comes to moving forward and holding on to backward compatibility. Once it is under a committee things can take a LONG time to move forward. See latest C++ version as an example of a long time in committee. Looks like history repeating itself here. They want to move something forward but it appears that will be a long drawn out process. They are sick of backward compatibility baggage which a "new" language will not have.

Is JavaScript totally broken and ready to throw away? I would guess no but I have never written a JS engine so I can't be sure. It does have some annoying limitations. Will a new language be fun and cool to write? Sure. We have learned many things since JS first came out. Always fun to start fresh and toss out the old. Are we ready for this to happen? I really am not looking forward to a new language and new browser compatibility issues. There will be new bugs, missing features and security issues to deal with again.

As far as the openness side of things I am a bit torn. If a new language is tossed to the masses too soon things can get muddled quickly. If one person / entity owns it until it is near release ready, can be shown to be fast, stable, include an IDE and there is example code to prove it is worth trying it out that can be very helpful. But one person / entity can overlook features that are really needed. As and example how did C# get initially released without clipboard support? I really don't want version 1.0, 1.2, 2.01 etc. followed in such quick succession that you are in backward compatibility mode months after it is initially released. A strong initial leader with a solid first cut can keep this from being another also ran.

Code ownership can be a good things if the owner is willing to fix bugs and provided updates in a timely manner. If they refuse to admit to problems, call every feature request stupid or everything gets stuck in endless meetings to discuss it then we just have a new broken language.

If some guy named Bob and his coding partner Sally came up with a new language, developed it in a garage and released it in a really solid state would we call them evil and breaking all the open source rules? I would hope not but replace "Bob and Sally" with Microsoft, Apple, Oracle and Google and the rules change? Probably too simple an example but something to think about.

Jon Davis replied on Mon, 2011/09/12 - 5:34pm

Google is far too cocky. It's as nonsensical to assume any one entity can oust Javascript as it is to assume Go could oust C for low-level native executables.

OrangeBook replied on Tue, 2011/09/13 - 2:56am

It is quite confusing that it is Google who says JS is not viable anymore. They were doing all these efforts to make it viable.. V8, GWT, their web apps.. I was not convinced of JS/HTML5 as a software platform, but (mostly) they made me change my mind. So I wonder what does this mean for JS, with is biggest supporter backing off.

Other than that, I think it is unfortunate the words they have used. They could have just said "this is something new and experimental, and we are doing it on our own. It will be like CoffeeScript but more ambitious. It will compile to JS, and we might have a native VM for chrome. If it is successful we will welcome other browsers to join, and drive it through an standard".

But now it looks like 1) they are not backing JS anymore, and 2) they are trying to control the web on the sly.

Not good news!


James Jamesson replied on Tue, 2011/09/13 - 5:36am

Typical Google attitude, why not propose to extend ecmascript?.

They can put Dart in Chrome for sure but who is gonna use it while everything is cross browser today? they have got enough cash to throw out; for that reason, I could not blame them for being too cocky in their own junkyard.

Keith Barret replied on Tue, 2011/09/13 - 5:43am

It's true - the turnaround time for establishing new web technologies have rapidly increased the last years. Nevertheless - some of us still know in their daily work what Internet Explorer 6 can do and what not.

 I doubt that Google will be able to shift the trend toward JS. It would be fine if they at least would be able to a establish Go instead of C. So I think we'll see another fragemantion just like the Flash/Java Applet/JavaScript fragmentation we just have overcome in the last years.

Carla Brian replied on Fri, 2012/04/06 - 10:06am

This is the first time I have heard about this. I am still adjusting on the software. - Tawny Tucci

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.