Google’s "The Future of JavaScript” Internal Memo Leaked. "JS is Flawed, Won'tWork, and Can’t Be Fixed”

---------- Forwarded message ----------From: Mark S. Miller <erig...@google.com>Date: Tue, Nov 16, 2010 at 3:44 PMSubject: "Future of Javascript" doc from our internal "JavaScript Summit"To: java...@google.com

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

This document is the result:https://docs.google.com/a/google.com/document/d/1aPluaNecjfam8MbF_ewsKRYh55klKM7xXQ8Bf4TCBTc/edit?hl=en

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

Please forward this message to people and groups that should know about this. This internal list,java...@google.com, is the place we should have the Google-wide discussion of this document and these issues.If you'd like to join this discussion, please subscribe at:https://groups.google.com/a/google.com/group/javascript-standard/topics

Executive Summary

Javascript has fundamental flaws that cannot be fixed merely by evolving the language. We'll adopt a two-prongedstrategy 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) that aims to maintain the dynamic natureof Javascript but have a better performance profile and be amenable to tooling for large projects. Push forDash to become an open standard and be adopted by other browsers. Developers using Dash tooling will beable to use a cross-compiler to target Javascript for browsers that do not support Dash natively.

That’s the 10,000 foot overview. For more detail (including an FAQ), read on...

------------------------------

Future of Javascript State of affairs

Building delightful applications on the web today is far too difficult.

The cyclone of innovation is increasingly moving off the web onto iOS and other closed platforms. Javascript hasbeen a part of the web platform since its infancy, but the web has begun to outgrown it. The web developmentcommunity has been backed into using large amounts of JS largely to work around the deficiencies in theplatform.

Complex web apps--the kind that Google specializes in--are struggling against the platform

and working with a language that cannot be tooled and has inherent performance problems.

Even smaller-scale apps written by hobbyist developers have to navigate a confusing labyrinth of frameworks andincompatible design patterns.

The web has succeeded historically to some extent in spite of the web platform, based primarily on the strength ofits reach. The emergence of compelling alternative platforms like iOS has meant that the web platform mustcompete on its merits, not just its reach.

Javascript as it exists today will likely not be a viable solution long-term. Something mustchange.

Overview of two-pronged solution

There are two ways to approach the problem: either we can try to evolve Javascript, or we can push for a newlanguage that addresses core problems in Javascript that can’t be repaired easily or quickly.

The “evolve Javascript” option is relatively low risk, but even in the best case it will take years and willbe limited by fundamental problems in the language (like the existence of a single Numberprimitive). Javascript has historical baggage that cannot be solved without a clean break. Thus, although it’slow risk, it’s also relatively low reward.

The “clean break” option is extremely high risk--it will be a huge challenge to convince other browservendors to rally around a new language--but is the only way to escape the historic problems with Javascript.Thus, its high risk is matched by the potential for a very high reward--a classic leapfrog strategy.

Pursuing either strategy in isolation is likely to fail.

The evolve Javascript strategy, if executed in isolation, leaves the web in a hobbled state and unable tocompete against the encroachment of other, less open platforms.

The clean break strategy, in isolation, would leave us in an undesirable situation if it were to fail--Javascriptevolution would have slowed down or evolved in undesirable ways without our support, we would still havethe fundamental flaws, and--worst of all— Google’s leadership position on the web would beseriously damaged.

The only solution is to execute the two strategies in parallel. When the leapfrog attempt succeeds (that is, it is anopen standard and browsers covering a majority of market share implement it), web programmers will have aviable and superior alternative to JavaScript.

Harmony: Evolving Javascript

It is paramount that Google continue to maintain a leadership position on important open web standards such asHarmony. Harmony is the name of the agreed trajectory of EcmaScript in TC39. Our JS++ project (part of thelarger Parkour project) will join with our Caja project’s efforts to advance Harmony. Together, we will focus onimproving the public Harmony spec and helping drive it forward at a faster pace in external standard committeesand by leading by example in Chrome wherever possible.

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 writtenagainst the proposal. Details of this approach are yet to be determined. The effort will also work with other browservendors (e.g. Mozilla) to get experimental support included, providing further pressure to get Harmonystandardized and widely implemented quickly. Harmony will be implemented in V8 and JSC (Safari) simultaneouslyto avoid a WebKit compatibility gap.

Developers who can focus solely on Chrome can expect to be able to see some Harmony features in Chrome(behind a flag) by the middle of 2011. Developers focusing on all browsers will have to wait multiple years for directHarmony support, due to the relatively slow pace of the standardization process. To enable Harmony developersto target all earlier browsers, we will enhance our source-to-source translators (such as Caja’s ES5-to-ES3translator) to translate from a large subset of Harmony to earlier versions of JavaScript.

Harmony will continue to be evangelized by Google externally as the evolution of Javascript. The audience forHarmony is developers currently building on the web platform who wish to write standards-compliant JavaScript.GWT, JSCompiler, and Caja continue to offer tooling support for Harmony for those that need it.

Dash: The Clean Break

Dash is the leapfrog effort that is designed to be a clean break from Javascript. It will seek to keep the parts thathave made the Internet so successful, but fill in holes everyone agrees it has.Dash is designed with three perspectives in mind:

Performance -- Dash is designed with performance characteristics in mind, so that it is possible to createVMs 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 ofJavascript 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-scaleprojects 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 texteditor. Dash is also designed to be securable, where that ability does not seriously conflict with the three maingoals.

Dash will be designed to be consumed in a number of locations:

Browser VM -- Our aspiration is that Dash will ultimately be a viable substitute for Javascript as the nativeclient-side language of choice across all browsers.

Front-end Server -- Dash will be designed as a language that can be used server-side for things up to thesize of Google-scale Front Ends. This will allow large scale applications to unify on a single language forclient and front end code.

Dash Cross Compiler -- Dash will be designed so that a large subset of it can be compiled to target legacyJavascript platforms so teams that commit to using Dash do not have to seriously limit their reach.

Platforms that have a Dash VM can operate on the original Dash code without translation and take advantage of

the increased performance. One of the ways we will evolve Harmony is to be a better target for such compiledDash code.

The goal of the Dash effort is ultimately to replace JavaScript as the lingua franca of web development on the openweb platform. We will proactively evangelize Dash with web developers and all other browser vendors and activelypush for its standardization and adoption across the board.

This will be a difficult effort requiring finesse and determination, but we are committed to doingeverything possible to help it succeed.

While Dash is catching on with other browsers, we will promote it as the language for serious web development onthe web platform; the compiler allows such developers to target other browsers before those browsers implementDash.

The Dash language effort will be driven by Lars Bak and his team in the Aarhus office. Bruce Johnson’s team inAtlanta will handle the tooling, and Pavel Feldman in STP will provide Web Inspector level support for Dash andHarmony.

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 intoChrome within a year.

Developers focusing on all browsers will have to make use of the Dash cross compiler to target otherbrowsers, and, depending on the success of the evangelizing effort, might have to wait years for otherbrowsers 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&amp;revision=_latest&amp;start=0&amp;theme=google&amp;cwj=true.

FAQWho 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, whocollectively 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 forlarge-scale development inside and outside Google, including being amenable to IDE-like tools and static compileroptimizations. The JSPrime team is happily folding its efforts into Dash now that everyone agrees Dash willexplicitly include the same goals.

What happened to JS++?The collection of features under the JS++ umbrella have been folded into Google efforts around the HarmonyJavascript effort. We continue to seek to improve the Javascript language to allow developers to better takeadvantage of our DOM improvements. This is a better plan because it gives us fewer independent Javascriptevolution vectors.

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 currentproposal, see this presentation:

https://docs.google.com/a/google.com/present/view?id=c6b9wv4_27fzwwsddk&revision=_latest&start=0&theme=google&cwj=true .

How will Dash interoperate with the huge body of existing JavaScript (JQuery, Analytics, etc)?Moving to a new language will be a very large undertaking. The specifics of how inter-operation with currentJavascript would work is still an open question.

What about the existing code bases for large Google Apps? Won’t they have to rebuild everything to takeadvantage of Dash?The Dash Cross Compiler should be capable of taking typed Closure code (with some restrictions) and convertingto Dash. Although the migration process won’t be fully automatic, it should make moving over to a Dash codebasesomewhat easier.

How does this affect Web Inspector?Web inspector will continue to support Javascript including any new features of Harmony that we add to chrome.

How does this affect our cloud IDE (Brightly)?Brightly will enable building any web application in V1 using today’s Javascript plus the additions in Harmony. Assoon as it is ready, Brightly will support Dash as well. We expect that the more prescriptive development aspectsof 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.

How will we get Harmony related changes into Chrome?Very carefully . V8 is carefully tuned for speed with the current Javascript standard rather than flexibility--thismakes it very difficult to make experimental changes. We are considering pre-processors and a number of otheroptions, but ultimately the precise solution is still an open question.

What about Go?Go is a very promising systems-programming language in the vein of C++. We fully hope and expect that Gobecomes the standard back-end language at Google over the next few years. Dash is focused on client (andeventually Front-end server development). The needs there are different (flexibility vs. stability) and therefore adifferent 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 anextensive 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” developertools such as code-refactoring, while still allowing small-scale or experimental projects the flexibility thatdynamism 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 theDash language. We will actively support teams for a long time on the current generation of JSCompiler and GWTand provide fantastic co-existence and migration tools to Dash.

Why are you killing Javascript?

We are not! Google has a huge interest in keeping the evolution of Javascript on track. In fact, our investment inTC39 (the Javascript standards body) will likely increase somewhat, and we will continue to honestly and whole-heartedly improve the language within the constraints.

What are the time frames? The Dash VM and Dash Cross Compiler will be developed in parallel with the language specification, and soshould be available not long after the spec is settled (likely in early 2011). However, the initial versions will not beheavily optimized (and thus not necessarily ready for production apps) until later (likely later 2011). ExperimentalHarmony features will begin showing up in Chrome (behind a flag) by midway through 2011, and will later beimplemented simultaneously in V8 and JSC (Safari’s Javascript engine) to avoid a WebKit compatibility gap.

Why do you have two projects? Why not just one? See the section above about why we’re pursuing a two-pronged strategy.

What will Google developers be using? We will strongly encourage Google developers start off targeting Chrome-only whenever possible as this gives usthe best end user experience. However, for some apps this will not make sense, so we are building a compiler forDash that targets Javascript (ES3). We intend for existing Google teams using GWT and JSCompiler to eventuallymigrate to the Dash compiler.

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 recognizethis is a very difficult road. Our approach is to make an absolutely fantastic VM/Language and developmentenvironment 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 openstandard with involvement from the broader web community.

However, in the event that other browsers don’t follow, Dash can still be a success.

Developers that target only Chrome can rely on the Dash VM, and developers that target other browsers aswell can still make use of the Dash compiler.In this event, the wider web will be stuck with Javascript as the standard language--and that’s precisely whywe must continue investing in evolving Javascript.

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

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 wellas 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 Dashis such a big bet we are likely to spend much more time at IO on Dash, though of course we will spend some timeon the leadership position Google is taking in Harmony.

-- Cheers,--Mark Morgan