---------- Forwarded message ----------
This document https://docs.google.com/a/google.com/document/d/1aPluaNecjfam8MbF_ewsKRYh55klKM7xXQ8Bf4TCBTc/edit?hl=en is the result. It was first announced on Buzz at http://www.google.com/buzz/a/google.com/komoroske/VxgE3F2yPyg/On-November-10th-and-11th-a-number-of-Google-teams
That’s the 10,000 foot overview. For more detail (including an FAQ), read on...
In order to help speed up what can be a long and drawn out standardization process, the internal Harmony effort will experiment using a preprocessor on top of V8 to prototype features in a way that allows real code to be written against the proposal. Details of this approach are yet to be determined. The effort will also work with other browser vendors (e.g. Mozilla) to get experimental support included, providing further pressure to get Harmony standardized and widely implemented quickly. Harmony will be implemented in V8 and JSC (Safari) simultaneously to avoid a WebKit compatibility gap.
Dash is designed with three perspectives in mind:
- 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.
Dash is also designed to be securable, where that ability does not seriously conflict with the three main goals.
Dash will be designed to be consumed in a number of locations:
- Front-end Server -- Dash will be designed as a language that can be used server-side for things up to the size of Google-scale Front Ends. This will allow large scale applications to unify on a single language for client and front end code.
While Dash is catching on with other browsers, we will promote it as the language for serious web development on the web platform; the compiler allows such developers to target other browsers before those browsers implement Dash.
The Dash language effort will be driven by Lars Bak and his team in the Aarhus office. Bruce Johnson’s team in Atlanta will handle the tooling, and Pavel Feldman in STP will provide Web Inspector level support for Dash and Harmony.
Dash will be spec complete and have working bits for the browser in Q1 2011. Developers who can focus solely on Chrome can expect to be able to rely on some Dash features built into Chrome within a year. Developers focusing on all browsers will have to make use of the Dash cross compiler to target other browsers, and, depending on the success of the evangelizing effort, might have to wait years for other browsers to implement native support for Dash.
Although Dash is in the early stages of development, work is progressing rapidly. You can learn more about the current proposal in this presentation https://docs.google.com/a/google.com/present/view?id=c6b9wv4_27fzwwsddk&revision=_latest&start=0&theme=google&cwj=true.
FAQ Who authored this document? 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.
What happened to JSPrime? The JSPrime effort was begun to unify and be a (single!) successor to GWT and Closure/JSCompiler, suitable for large-scale development inside and outside Google, including being amenable to IDE-like tools and static compiler optimizations. The JSPrime team is happily folding its efforts into Dash now that everyone agrees Dash will explicitly include the same goals.
What happened to Joy? The Joy templating and MVC systems are higher-level frameworks that will be built on top of Dash.
Where can I learn more about Dash? Dash is still in the early stages of development, but work is progressing rapidly. For an early look at the current proposal, see this presentationhttps://docs.google.com/a/google.com/present/view?id=c6b9wv4_27fzwwsddk&revision=_latest&start=0&theme=google&cwj=true .
What about the existing code bases for large Google Apps? Won’t they have to rebuild everything to take advantage of Dash? 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.
We expect Brightly itself to be the first application written in Dash.
What about Go? Go is a very promising systems-programming language in the vein of C++. We fully hope and expect that Go becomes the standard back-end language at Google over the next few years. Dash is focused on client (and eventually Front-end server development). The needs there are different (flexibility vs. stability) and therefore a different programming language is warranted.
Will Dash run on the Server? Android? Yes, but short term we are focused on the client.
Does Dash replace Java? For many projects that will be a viable option but it requires significant engineering effort on Dash tooling and an extensive set of libraries.
Is Dash statically typed and toolable? Dash is optionally-typed and with judicious use of types is as toolable as Java. This enables “grown up” developer tools such as code-refactoring, while still allowing small-scale or experimental projects the flexibility that dynamism provides.
What is the future of the JSCompiler and GWT? JSCompiler and GWT were already on a merger path. This effort gives us a direction for that unification around the Dash language. We will actively support teams for a long time on the current generation of JSCompiler and GWT and provide fantastic co-existence and migration tools to Dash.
What are the time frames? The Dash VM and Dash Cross Compiler will be developed in parallel with the language specification, and so should be available not long after the spec is settled (likely in early 2011). However, the initial versions will not be heavily optimized (and thus not necessarily ready for production apps) until later (likely later 2011).
Why do you have two projects? Why not just one? See the section above about why we’re pursuing a two-pronged strategy.
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.
What will we say at Google IO about Dash/Harmony? Google deeply cares about the web. We care about making the web incrementally better today (Harmony) as well as making it substantially better in the future (Dash). Large scale applications should probably build on Dash; smaller-scale developers might want to stick with Harmony until the Dash standard gains ubiquity. Given that Dash is such a big bet we are likely to spend much more time at IO on Dash, though of course we will spend some time on the leadership position Google is taking in Harmony.