The Web Dev Zone is brought to you in partnership with Mendix. Discover how IT departments looking for ways to keep up with demand for business apps has caused a new breed of developers to surface - the Rapid Application Developer.
The agreed-upon “common vision” was to develop a new programming language called “Dash” (which was later renamed to “Dart”).
In order to minimize the risk of failure, Google will hedge its bets:
- Dash (high risk/high reward): Develop a new language (called Dash) [...]
Dart’s goals are (quoting verbatim from the email):
Dart (originally Dash)
- 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.
- 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:
- 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  which compiles ECMAScript.next  to ECMAScript 3, in a similar manner.
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)”.
We expect Brightly itself to be the first application written in Dash.
Consequences for ECMAScript.next . With Google considering
ECMAScript.next 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.
What does it all mean?
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.
[...] 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 ECMAScript.next 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?
Isn’t Dart similar to CoffeeScript? Yes and no. To run either
perform a translation step. However, CoffeeScript intentionally stays
(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 , 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 ECMAScript.next ).
More voices on Dart
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.