Dart：JavaScript的未来

最近在关注Dart语言，下面这篇文章译自这里，其实是2011年11月Google内部员工的一封邮件，邮件中提到的Dash，就是如今的Dart语言的前身。Google搞东西很有意思，思维似乎非常超前，总是能挖到现在火爆的东西的不足，然后搞一个新的东西代替它，真是凶猛异常。比如SPDY、V8、WebP、Go等等，有的成功，有的失败。还有，希望大家能从下面粗糙的译文中留意到，Google对于标准非常重视，谈论中也是霸气外露，希望把一切标准都控制在自己手里。

Subject: [Caja] 转发：从上周的JavaScript会议看JavaScript的未来
From: Mark S. Miller
Date: Nov 16, 2010 3:46:58 pm
List: com.googlegroups.google-caja-discuss

11月10号和11号，一簇Google团队展现了一组关于客户端语言JavaScript未来的观点。

这个文档就是结论，最初发布在Buzz。

请转发此信息给团队和朋友，这个内部的邮件列表，就是我们在Google范围内讨论这个文档和这些问题的地方。如果你要加入讨论，请订阅：https://groups.google.com/a/google.com/group/javascript-standard/topics。

结果摘要

JavaScript有一些根本性的缺陷，这些缺陷无法被修复，我们将采取两套策略来为JavaScript的未来做准备。

1. Harmony（低风险/低回报）：继续结合TC39（EcmaScript标准体）来发展JavaScript。
2. Dash（高风险/高回报）：开发一个新语言（Dash），以维持JavaScript的动态特性，但是可以拥有更高的性能，可以更好地被工具化，应用到大型系统中。把Dash推广成为开源的标准，并且让其它浏览器都支持它，开发者可以使用Dash工具，也可以通过一个交叉编译器来转成JavaScript以便兼容那些无法支持Dash本身的浏览器。

好吧，这是在一万英尺上空的概览，是该看看细节了（包括FAQ），继续……

——————————

未来用JavaScript来构建漂亮的web应用远不会像现在这么困难，创新的旋风已经从web挂到iOS和其他封闭平台上了。JavaScript从一开始就成为了web平台的一部分，但是web看起来已经长得过大了。Web开发者社区使用了大量的JS来改善平台的不足。复杂的web应用，也就是Google特别专注的，始终在平台、不容易被工具加工和历来的性能问题中挣扎。即使是业余开发者写的小众应用，也被迫在框架的混乱迷宫和不兼容的设计模式中寻找方向。

从历史角度来看，Web毫无疑问是成功的，web平台基本上发挥了它自己的长项。但是像正在极力改善的iOS平台告诉我们，必须继续完善它的，而不是停留在现在的高度上。JavaScript当今好端端地发展，但是看起来也不像一个长远的解决方案，是到改变的时候了。看看前面提到的这两条策略，有两种办法来解决这个问题，要么继续发展JavaScript，或者我们可以推广一种新的语言，致力于解决这些JavaScript天生难以被修复的问题。

发展JavaScript的选项相对是低风险的，但是即使最好的情况下，也要花好多年，并且由于JavaScript这些基础的问题（比如存在单独Number原语），历史已经告诉我们，不彻底革命，改良是走不通的。所以虽然是低风险的方案，回报也好不到哪里去。

那么革命的选项就是相当的高风险了，要去让那么多浏览器制造商满意，来支持这门新语言，这真是一个巨大的挑战。但是这也是唯一的办法。所以高风险意味着高回报，一个典型的跳蛙战略。

可是无论采用哪一种方案看起来都会失败。如果只采用改良的方案，web发展会蹒跚不前，并且逐渐难以和那些独立的非开放平台竞争。如果只采用革命的方案，一旦失败会导致我们处于不受欢迎的境地——JavaScript演进会减缓，甚至，失去支持，这些最基础的缺陷仍然存在，但是Google却失去了web的领导位置。

所以，唯一的解决办法就是要并行地执行这两个策略。当跳蛙的尝试成功，就是说，它已经成为市场上主要浏览器都支持的开放标准的时候，web程序员就可以拥有一个可行的JavaScript替代品。Harmony：改良JavaScript，Google会继续保持它在开放web标准的领导地位。Harmony是EcmaScript在TC39协议达成的名字。我们的JS++项目（Parkour项目的一部分），会加入Caja项目的成果，以改进Harmony。同时，我们会专注于改进公共Harmony文档，尽快提交外部标准委员会，Chrome也要尽可能地作为支持的典范。

为了帮助加速可能漫长的标准化进程，内部的Harmony措施会实验性地以一种允许写真实代码的方法来使用V8预处理器原型化新特性。具体措施还未定。我们需要和浏览器厂商（比如Mozilla）一起合作，来获取试验阶段的支持，给出更大的压力来加速Harmony标准化和广泛化的进程。Harmony会被V8和JSC（Safari）同时实现，以避免出现WebKit兼容性的空白。

只专注于Chrome的开发者预计能在2011年中期看到Harmony的一些特性在Chrome上的支持。顾及所有浏览器的开发者得要等好些年才能获得Harmony的直接支持，所以标准化进程是相对缓慢的。要让Harmony开发者更多地关注于这些早一些行动的浏览器，我们需要加强source-to-source转换器（比如Caja的ES5-to-ES3转换器）来转换大量的Harmony到早期版本的JavaScript上面。

Harmony会继续以JavaScript改良的身份去推广，它的支持者是希望在web平台上写标准JavaScript的开发者。GWT、JSCompiler，以及Caja将继续提供工具来支持Harmony。Dash：推翻重建的工作会尽可能保留如今在互联网非常成功的部分，但是要弥补那些公认的不足。

Dash设计的指导思想：

1. 性能：性能是必须的特性，所以有必要创造一个虚拟机来避免EcmaScript的性能问题。
2. 开发者易用性：保持动态、容易上手、不需要编译等等被业余开发者所喜爱的JavaScript特性。
3. 工具能力：语言本身要容易被工具支持（比如可选类型支持），大型项目需要代码的易读性，以便进行重构和快速寻找调用点。Dash的工具其实不需要非常高效，对小项目的开发者来说，文本文档搞定都可以。

Dash也需要具备一定的安全性，但是这一点不能和上面三点矛盾。

Dash设计主要包含以下几个部分：

1. 浏览器的虚拟机：我们希望Dash可以以一种本地客户端语言的方式，像JavaScript一样在所有浏览器中跑起来。
2. 前端服务器：可以用在服务端直到Google的全部前端页面。这要求一个大型应用对前后端大统一。
3. 交叉编译器：要能够跑在JavaScript平台上，这样才能广泛应用。具有Dash虚拟机的平台则不需要转换，直接可以解析Dash，这样就获得了性能优势。其中一个好办法是让Dash代码编译后编程Harmony。

Dash的终极目标是要替换JavaScript，成为开放web平台上的通用语言。我们会主动向程序员和其他所有的浏览器厂商宣传和推送标准化信息，希望能够获得全面采用。这个工作的决策是困难的，但是我们愿意竭尽所能帮助它成功。

当其它浏览器都支持的时候，我们就要把它晋升为web平台上开发的正式语言；在这以前，编译器允许开发者聚焦到别的浏览器上。

Dash语言是由Lars Bak和他的Aarhus工作室的团队设计的，Bruce Johnson在亚特兰大的团队会负责工具，而STP的Pavel Feldman则为Dash和Harmony提供web检测级别的支持。

Dash文档会在2011年第一季度完成。开发者可以只关注Chrome，这样可以看到很多特性在一年内加进Chrome的Dash去。如果关注所有浏览器的话，就得等Dash的交叉编译器了，这个时间情况不好说，也许好多年，直到其他浏览器厂商都支持。

尽管Dash还是处在比较早的阶段，发展还是很迅速的。你可以从这个演讲中找到提议的更多细节：https://docs.google.com/a/google.com/present/view?id=c6b9wv4_27fzwwsddk&revision=_latest&start=0&theme=google&cwj=true。

（FAQ部分略）

Cheers, MarkM

文章系本人原创，转载请注明作者和出处

注：本博客已经迁移到个人站点 http://www.raychase.net/ ，欢迎大家访问收藏，本ITEye博客在数日后将不再更新。