最近在关注 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 未来的观点。
请转发此信息给团队和朋友，这个内部的邮件列表，就是我们在 Google 范围内讨论这个文档和这些问题的地方。如果你要加入讨论，请订阅：https://groups.google.com/a/google.com/group/javascript-standard/topics。
结果摘要
JavaScript 有一些根本性的缺陷，这些缺陷无法被修复，我们将采取两套策略来为 JavaScript 的未来做准备。
- Harmony（低风险/低回报）：继续结合 TC39（EcmaScript 标准体）来发展 JavaScript。
- 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 设计的指导思想：
- 性能：性能是必须的特性，所以有必要创造一个虚拟机来避免 EcmaScript 的性能问题。
- 开发者易用性：保持动态、容易上手、不需要编译等等被业余开发者所喜爱的 JavaScript 特性。
- 工具能力：语言本身要容易被工具支持（比如可选类型支持），大型项目需要代码的易读性，以便进行重构和快速寻找调用点。Dash 的工具其实不需要非常高效，对小项目的开发者来说，文本文档搞定都可以。
Dash 也需要具备一定的安全性，但是这一点不能和上面三点矛盾。
Dash 设计主要包含以下几个部分：
- 浏览器的虚拟机：我们希望 Dash 可以以一种本地客户端语言的方式，像 JavaScript 一样在所有浏览器中跑起来。
- 前端服务器：可以用在服务端直到 Google 的全部前端页面。这要求一个大型应用对前后端大统一。
- 交叉编译器：要能够跑在 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 部分略，后续会继续写介绍 Dart 的文章。）
Cheers, MarkM
文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》