Guest User


a guest
Sep 9th, 2011
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 18.24 KB | None | 0 0
  1. ---------- Forwarded message ----------
  2. From: Mark S. Miller <>
  3. Date: Tue, Nov 16, 2010 at 3:44 PM
  4. Subject: "Future of Javascript" doc from our internal "JavaScript Summit"
  5. last week
  6. To:
  8. On November 10th and 11th, a number of Google teams representing a variety
  9. of viewpoints on client-side languages met to agree on a common vision for
  10. the future of Javascript.
  12. This document
  13. <
  16. is the result. It was first announced on Buzz at
  17. <
  20. Please forward this message to people and groups that should know about
  21. this. This internal list,, is the place we
  22. should have the Google-wide discussion of this document and these issues. If
  23. you'd like to join this discussion, please subscribe at <
  26. Executive Summary
  28. Javascript has fundamental flaws that cannot be fixed merely by evolving the
  29. language. We'll adopt a two-pronged strategy for the future of Javascript:
  31. - Harmony (low risk/low reward): continue working in conjunction with
  32. TC39 (the EcmaScript standards body) to evolve Javascript
  33. - Dash (high risk/high reward): Develop a new language (called Dash) that
  34. aims to maintain the dynamic nature of Javascript but have a better
  35. performance profile and be amenable to tooling for large projects. Push for
  36. Dash to become an open standard and be adopted by other browsers. Developers
  37. using Dash tooling will be able to use a cross-compiler to target Javascript
  38. for browsers that do not support Dash natively.
  40. That’s the 10,000 foot overview. For more detail (including an FAQ), read
  41. on...
  42. ------------------------------
  44. Future of Javascript State of affairs Building delightful applications on
  45. the web today is far too difficult. The cyclone of innovation is
  46. increasingly moving off the web onto iOS and other closed platforms.
  47. Javascript has been a part of the web platform since its infancy, but the
  48. web has begun to outgrown it. The web development community has been
  49. backed into using large amounts of JS largely to work around the
  50. deficiencies in the platform. Complex web apps--the kind that Google
  51. specializes in--are struggling against the platform and working with a
  52. language that cannot be tooled and has inherent performance problems. Even
  53. smaller-scale apps written by hobbyist developers have to navigate a
  54. confusing labyrinth of frameworks and incompatible design patterns.
  56. The web has succeeded historically to some extent in spite of the web
  57. platform, based primarily on the strength of its reach. The emergence of
  58. compelling alternative platforms like iOS has meant that the web platform
  59. must compete on its merits, not just its reach. Javascript as it exists
  60. today will likely not be a viable solution long-term. Something must
  61. change.
  62. Overview of two-pronged solution
  63. There are two ways to approach the problem: either we can try to evolve
  64. Javascript, or we can push for a new language that addresses core problems
  65. in Javascript that can’t be repaired easily or quickly.
  67. The “evolve Javascript” option is relatively low risk, but even in the best
  68. case it will take years and will be limited by fundamental problems in the
  69. language (like the existence of a single Number primitive). Javascript has
  70. historical baggage that cannot be solved without a clean break. Thus,
  71. although it’s low risk, it’s also relatively low reward.
  73. The “clean break” option is extremely high risk--it will be a huge challenge
  74. to convince other browser vendors to rally around a new language--but is the
  75. only way to escape the historic problems with Javascript. Thus, its high
  76. risk is matched by the potential for a very high reward--a classic leapfrog
  77. strategy.
  79. Pursuing either strategy in isolation is likely to fail. The evolve
  80. Javascript strategy, if executed in isolation, leaves the web in a hobbled
  81. state and unable to compete against the encroachment of other, less open
  82. platforms. The clean break strategy, in isolation, would leave us in an
  83. undesirable situation if it were to fail--Javascript evolution would have
  84. slowed down or evolved in undesirable ways without our support, we would
  85. still have the fundamental flaws, and--worst of all--Google’s leadership
  86. position on the web would be seriously damaged.
  88. The only solution is to execute the two strategies in parallel. When the
  89. leapfrog attempt succeeds (that is, it is an open standard and browsers
  90. covering a majority of market share implement it), web programmers will have
  91. a viable and superior alternative to JavaScript.
  92. Harmony: Evolving Javascript
  93. It is paramount that Google continue to maintain a leadership position on
  94. important open web standards such as Harmony. Harmony is the name of the
  95. agreed trajectory of EcmaScript in TC39. Our JS++ project (part of the
  96. larger Parkour project) will join with our Caja project’s efforts to advance
  97. Harmony. Together, we will focus on improving the public Harmony spec and
  98. helping drive it forward at a faster pace in external standard committees
  99. and by leading by example in Chrome wherever possible.
  101. In order to help speed up what can be a long and drawn out standardization
  102. process, the internal Harmony effort will experiment using a preprocessor
  103. on top of V8 to prototype features in a way that allows real code to be
  104. written against the proposal. Details of this approach are yet to be
  105. determined. The effort will also work with other browser vendors (e.g.
  106. Mozilla) to get experimental support included, providing further pressure to
  107. get Harmony standardized and widely implemented quickly. Harmony will be
  108. implemented in V8 and JSC (Safari) simultaneously to avoid a WebKit
  109. compatibility gap.
  111. Developers who can focus solely on Chrome can expect to be able to see some
  112. Harmony features in Chrome (behind a flag) by the middle of 2011. Developers
  113. focusing on all browsers will have to wait multiple years for direct Harmony
  114. support, due to the relatively slow pace of the standardization process. To
  115. enable Harmony developers to target all earlier browsers, we will enhance
  116. our source-to-source translators (such as Caja’s ES5-to-ES3 translator) to
  117. translate from a large subset of Harmony to earlier versions of JavaScript.
  119. Harmony will continue to be evangelized by Google externally as the
  120. evolution of Javascript. The audience for Harmony is developers currently
  121. building on the web platform who wish to write standards-compliant
  122. JavaScript. GWT, JSCompiler, and Caja continue to offer tooling support for
  123. Harmony for those that need it.
  124. Dash: The Clean Break
  125. Dash is the leapfrog effort that is designed to be a clean break from
  126. Javascript. It will seek to keep the parts that have made the Internet so
  127. successful, but fill in holes everyone agrees it has.
  129. Dash is designed with three perspectives in mind:
  131. - Performance -- Dash is designed with performance characteristics in
  132. mind, so that it is possible to create VMs that do not have the performance
  133. problems that all EcmaScript VMs must have.
  134. - Developer Usability -- Dash is designed to keep the dynamic,
  135. easy-to-get-started, no-compile nature of Javascript that has made the web
  136. platform the clear winner for hobbyist developers.
  137. - Ability to be Tooled -- Dash is designed to be more easily tooled (e.g.
  138. with optional types) for large-scale projects that require
  139. code-comprehension features such as refactoring and finding callsites.
  140. Dash, however, does not require tooling to be effective--small-scale
  141. developers may still be satisfied with a text editor.
  143. Dash is also designed to be securable, where that ability does not seriously
  144. conflict with the three main goals.
  146. Dash will be designed to be consumed in a number of locations:
  148. - Browser VM -- Our aspiration is that Dash will ultimately be a viable
  149. substitute for Javascript as the native client-side language of choice
  150. across all browsers.
  151. - Front-end Server -- Dash will be designed as a language that can be
  152. used server-side for things up to the size of Google-scale Front Ends. This
  153. will allow large scale applications to unify on a single language for client
  154. and front end code.
  155. - Dash Cross Compiler -- Dash will be designed so that a large subset of
  156. it can be compiled to target legacy Javascript platforms so teams that
  157. commit to using Dash do not have to seriously limit their reach. Platforms
  158. that have a Dash VM can operate on the original Dash code without
  159. translation and take advantage of the increased performance. One of the
  160. ways we will evolve Harmony is to be a better target for such compiled Dash
  161. code.
  163. The goal of the Dash effort is ultimately to replace JavaScript as the
  164. lingua franca of web development on the open web platform. We will
  165. proactively evangelize Dash with web developers and all other browser
  166. vendors and actively push for its standardization and adoption across the
  167. board. This will be a difficult effort requiring finesse and
  168. determination, but we are committed to doing everything possible to help it
  169. succeed.
  171. While Dash is catching on with other browsers, we will promote it as the
  172. language for serious web development on the web platform; the compiler
  173. allows such developers to target other browsers before those browsers
  174. implement Dash.
  176. The Dash language effort will be driven by Lars Bak and his team in the
  177. Aarhus office. Bruce Johnson’s team in Atlanta will handle the tooling, and
  178. Pavel Feldman in STP will provide Web Inspector level support for Dash and
  179. Harmony.
  181. Dash will be spec complete and have working bits for the browser in Q1 2011.
  182. Developers who can focus solely on Chrome can expect to be able to rely on
  183. some Dash features built into Chrome within a year. Developers focusing on
  184. all browsers will have to make use of the Dash cross compiler to target
  185. other browsers, and, depending on the success of the evangelizing effort,
  186. might have to wait years for other browsers to implement native support for
  187. Dash.
  189. Although Dash is in the early stages of development, work is progressing
  190. rapidly. You can learn more about the current proposal in this
  191. presentation<>.
  193. FAQ Who authored this document?
  194. Brad Abrams, Erik Arvidsson, Lars Bak, Darin Fisher, Dimitri Glazkov, Dan
  195. Grove, Peter Hallam, Bruce Johnson, Alex Komoroske, John Lenz, Kasper Lund,
  196. Mark Miller , Ivan Posva, Alex Russell, and Joel Webber, who collectively
  197. represent TC39 (the EcmaScript standards body), WebKit, Parkour, Brightly,
  198. JSPrime, JS++, Closure, JSCompiler, V8, Dash, Joy, and GWT, among others.
  200. What happened to JSPrime?
  201. The JSPrime effort was begun to unify and be a (single!) successor to GWT
  202. and Closure/JSCompiler, suitable for large-scale development inside and
  203. outside Google, including being amenable to IDE-like tools and static
  204. compiler optimizations. The JSPrime team is happily folding its efforts into
  205. Dash now that everyone agrees Dash will explicitly include the same goals.
  207. What happened to JS++?
  208. The collection of features under the JS++ umbrella have been folded into
  209. Google efforts around the Harmony Javascript effort. We continue to seek
  210. to improve the Javascript language to allow developers to better take
  211. advantage of our DOM improvements. This is a better plan because it gives
  212. us fewer independent Javascript evolution vectors.
  214. What happened to Joy?
  215. The Joy templating and MVC systems are higher-level frameworks that will be
  216. built on top of Dash.
  218. Where can I learn more about Dash?
  219. Dash is still in the early stages of development, but work is progressing
  220. rapidly. For an early look at the current proposal, see this
  221. presentation<>
  222. .
  224. How will Dash interoperate with the huge body of existing JavaScript
  225. (JQuery, Analytics, etc)
  226. Moving to a new language will be a very large undertaking. The specifics of
  227. how inter-operation with current Javascript would work is still an open
  228. question.
  230. What about the existing code bases for large Google Apps? Won’t they have
  231. to rebuild everything to take advantage of Dash?
  232. The Dash Cross Compiler should be capable of taking typed Closure code (with
  233. some restrictions) and converting to Dash. Although the migration process
  234. won’t be fully automatic, it should make moving over to a Dash codebase
  235. somewhat easier.
  237. How does this affect Web Inspector?
  238. Web inspector will continue to support Javascript including any new features
  239. of Harmony that we add to chrome.
  241. How does this affect our cloud IDE (Brightly)?
  242. Brightly will enable building any web application in V1 using today’s
  243. Javascript plus the additions in Harmony. As soon as it is ready, Brightly
  244. will support Dash as well. We expect that the more prescriptive development
  245. aspects of Brightly that will come on line in the future will be more Dash
  246. focused.
  248. We expect Brightly itself to be the first application written in Dash.
  250. How will we get Harmony related changes into Chrome?
  251. Very carefully ;-). V8 is carefully tuned for speed with the current
  252. Javascript standard rather than flexibility--this makes it very difficult to
  253. make experimental changes. We are considering pre-processors and a number
  254. of other options, but ultimately the precise solution is still an open
  255. question.
  257. What about Go?
  258. Go is a very promising systems-programming language in the vein of C++. We
  259. fully hope and expect that Go becomes the standard back-end language at
  260. Google over the next few years. Dash is focused on client (and eventually
  261. Front-end server development). The needs there are different (flexibility
  262. vs. stability) and therefore a different programming language is warranted.
  264. Will Dash run on the Server? Android?
  265. Yes, but short term we are focused on the client.
  267. Does Dash replace Java?
  268. For many projects that will be a viable option but it requires significant
  269. engineering effort on Dash tooling and an extensive set of libraries.
  271. Is Dash statically typed and toolable?
  272. Dash is optionally-typed and with judicious use of types is as toolable as
  273. Java. This enables “grown up” developer tools such as code-refactoring,
  274. while still allowing small-scale or experimental projects the flexibility
  275. that dynamism provides.
  277. What is the future of the JSCompiler and GWT?
  278. JSCompiler and GWT were already on a merger path. This effort gives us a
  279. direction for that unification around the Dash language. We will actively
  280. support teams for a long time on the current generation of JSCompiler and
  281. GWT and provide fantastic co-existence and migration tools to Dash.
  283. Why are you killing Javascript?
  284. We are not! Google has a huge interest in keeping the evolution of
  285. Javascript on track. In fact, our investment in TC39 (the Javascript
  286. standards body) will likely increase somewhat, and we will continue to
  287. honestly and whole-heartedly improve the language within the constraints.
  289. What are the time frames?
  290. The Dash VM and Dash Cross Compiler will be developed in parallel with the
  291. language specification, and so should be available not long after the spec
  292. is settled (likely in early 2011). However, the initial versions will not
  293. be heavily optimized (and thus not necessarily ready for production apps)
  294. until later (likely later 2011).
  296. Experimental Harmony features will begin showing up in Chrome (behind a
  297. flag) by midway through 2011, and will later be implemented simultaneously
  298. in V8 and JSC (Safari’s Javascript engine) to avoid a WebKit compatibility
  299. gap.
  301. Why do you have two projects? Why not just one?
  302. See the section above about why we’re pursuing a two-pronged strategy.
  304. What will Google developers be using?
  305. We will strongly encourage Google developers start off targeting Chrome-only
  306. whenever possible as this gives us the best end user experience. However,
  307. for some apps this will not make sense, so we are building a compiler for
  308. Dash that targets Javascript (ES3). We intend for existing Google teams
  309. using GWT and JSCompiler to eventually migrate to the Dash compiler.
  311. What if other browsers don’t follow us with Dash?
  312. Lars has promised to “sweet talk” the other browser vendors and, while we
  313. are all eager to see this, we recognize this is a very difficult road. Our
  314. approach is to make an absolutely fantastic VM/Language and development
  315. environment and build great apps that fully leverage it in order to help
  316. other browsers see the wisdom in following. Once Dash has had a chance to
  317. prove its stability and feasibility, we are committed to making Dash an open
  318. standard with involvement from the broader web community.
  320. However, in the event that other browsers don’t follow, Dash can still be a
  321. success. Developers that target only Chrome can rely on the Dash VM, and
  322. developers that target other browsers as well can still make use of the Dash
  323. compiler. In this event, the wider web will be stuck with Javascript as the
  324. standard language--and that’s precisely why we must continue investing in
  325. evolving Javascript.
  327. Why are you circumventing the standards process?
  328. We fully intend to cooperate fully with standards processes--the problem is
  329. that the current standard processes are limited to Javascript, which is not
  330. viable in the long term. Any effort with the historic baggage that
  331. Javascript has will be extremely limited. We need to make a clean break,
  332. make progress, and then engage the community.
  334. What will we say at Google IO about Dash/Harmony?
  335. Google deeply cares about the web. We care about making the web
  336. incrementally better today (Harmony) as well as making it substantially
  337. better in the future (Dash). Large scale applications should probably build
  338. on Dash; smaller-scale developers might want to stick with Harmony until the
  339. Dash standard gains ubiquity. Given that Dash is such a big bet we are
  340. likely to spend much more time at IO on Dash, though of course we will spend
  341. some time on the leadership position Google is taking in Harmony.
  343. --
  344. Cheers,
  345. --MarkM
  347. --
  348. Cheers,
  349. --MarkM
Add Comment
Please, Sign In to add comment