导读：本文根据《JavaScript is Dead. Long Live JavaScript!》这篇文章翻译而来。
文章内容如下：
JavaScript的成功得益于在正确的时间出现在正确的地点。JavaScript的兴起与浏览器的支持息息相关。你瞧，VBScript就没这么好运气。
JavaScript很流行，但它有先天缺陷。Brendan Eich当初只花了10天时间就把JavaScript设计出来了，作为JavaScript之父Brendan Eich如是说：
| 与其说我爱JavaScript，不如说我恨它。它是C语言和Self语言***的产物。十八世纪英国文学家约翰逊博士说得好：“它的优秀之处并非原创，它的原创之处并不优秀。” |
JavaScript的不足，最明显之处是语法。
糟糕冗长的语法 可选参数和默认值
- function(a, b, option) {
- optionoption = option || {};
- // ...
- }
上面的代码中，option是可选参数，当没有传递时，默认值是{}.然而，传递的option值有可能是假值(falsy值)。严格来写，得如下判断：
- function(a, b, option) {
- option = arguments.length > 2 ? option : {};
- // ...
- }
注意：option = typeof option !== 'undefined' ? option :{}也有可能是错误的，因为传递过来的可能就是undefined。当不需要b参数，删除后，基于arguments.length 的判断很容易导致忘记修改而出错：
- function(a, option) {
- option = arguments.length > 2 ? option : {};
- // ...
- }
如果能增加以下语法该多好呀：
- function(a, b, option = {}) {
- // ...
- }
Let
闭包很强大，也很恼火：
- for (var i=0, ilen=elements.length; i<ilen; i++) {
- var element = elements[i];
- LIB_addEventListener(element, 'click', function(event) {
- alert('I was originally number ' + i);
- });
- }
上面的代码经常在面试题中出现，解决办法是再包裹一层：
for (var i=0, ilen=elements.length; i<ilen; i++) { var element = elements[i]; (function(num) { LIB_addEventListener(element, 'click', function(event) { alert('I was originally number ' + num); }); }(i));}
如果直接支持let语法该多好呀：
for (var i=0, ilen=elements.length; i<ilen; i++) { var element = elements[i]; let (num = i) { LIB_addEventListener(element, function(event) { alert('I was originally number ' + num); }); };}
模块
模块模式是一种无奈的选择：
如果原生支持该多好呀：
- module event {
- // private variables
- var listeners = [];
- export function addEventListener(f) {
- listeners.push(f);
- }
- export function clearEventListeners() {
- listeners = [];
- }
- // ...
- }
- (function() {
- import event;
- // ...
- }());
继承
JavaScript要通过原型链来实现继承：
- function Employee(first, last, position) {
- // call the superclass constructor
- Person.call(this, first, last);
- this.position = position;
- };
- // inherit from Person
- Employee.prototype = Object.create(Person.prototype);
- EmployeeEmployee.prototype.constructor = Employee;
- // define an overridding toString() method
- Employee.prototype.toString = function() {
- // call superclass's overridden toString() method
- return Person.prototype.toString.call(this) +
- ' is a ' + this.position;
- };
如果能写成下面这样该多好呀：
- class Employee extends Person {
- constructor(first, last, position) {
- super(first, last);
- public positionposition = position;
- }
- update(camera) {
- return super.update() + ' is a ' + position;
- }
- }
感悟
ECMAScript委员会已意识到JavaScript在语法层面上的不足。在Harmony规范中，以上所有语法均已提案。
我们什么时候才能使用以上语法呢？
只要有宏（Macro）
Lisp语言的宏特性非常强大。通过宏，你可以根据自己的喜好定义想要的语法格式。宏特性使得Lisp成为一门“可编程的编程语言(the programmable programming language)”.
JavaScript没有宏。给类C语言添加宏特性，目前依旧是个研究课题，很有难度。
只要有宏，我们就可以自定义语法。但JavaScript的宏特性遥遥无期，还是找找其他路子吧。
Harmony
Harmony规范里的语法扩展，可能是我们所有人的梦。Harmony有可能成为ECMAScript 6规范。在这之前，我们需要等待，耐心等待。
截止2011年5月，w3school显示IE6的市场份额还有2.4%。Net Market Share 显示IE6占有10.36%市场份额。还有IE7的市场份额也不少。这些老旧浏览器短期内不会退隐市场，对于商业公司来说，比如Amazon，不可能放弃这批用户。糟糕的现状。（中国大陆更惨，IE6/7还占有40%多市场份额）
我们不能寄期望于“IE该死”这类呼吁来让用户升级。听到过一种说法：IE用户仅会在更换电脑硬件时，才升级浏览器。悲催的是，对于普通用户来说，收email,上Facebook,Twitter,现有的硬件已足够。没有理由让他们去花一笔钱。
Goggle Apps最近宣布，从2011年8月开始，将停止支持IE7.
通过各种保守估计，Amazon的网站开发者，用上Harmony语法扩展，要一直等到2023年！
风华正茂的你，愿意等待10多年后，再用上这些好用的语法吗？
JavaScript已死
死因：分号癌。(semicolon cancer.作者的调侃，意指语法导致JavaScript死去)
通过上面的分析可以看出，宏特性实现太难，Harmony规范的实现则遥遥无期。大量程序员开始书写JavaScript,其中有很多人已经厌倦或开始厌倦JavaScript冗长糟糕的语法。我们需要新的语法，我们不想等待！JavaScript，作为源码编写语言，已经死了！
JavaScript先生，你曾有过辉煌的统治。我们与你，有过甜蜜的回忆，一起产出过很多有趣的应用。祝福逝者安息。
JavaScript长存
程序员喜欢掌控自己的命运。作为源码编写语言，JavaScript已死。我们可以选择或创造另一种更好的源码语言，将其编译成ECMAScript 3的语法格式。
JavaScript的新生，是作为编译目标(compilation target)。
编译成JavaScript的语言
能编译成JavaScript的语言有很多。我在1997年时，收集过一份列表。包括：
- JavaScript扩展语言：已死的 ECMAScript 4, Narrative Script, Objective-J.
- 已存在的语言：Scheme, Common Lisp, Smalltalk, Ruby, Python, Java, C#, Haskell等。
- 还有一些崭新的语言：HaXe, Milescript, Links, Flapjax,专门为web 编程而设计。
在这些编译器项目中，Goggle的GWT Java-to-JavaScript编译器有可能是最成功的一个。然而悲剧的是，现实项目中，很少看到GWT的身影。原因如下：
1.维护成本很高。编译器可能有bug.假设你在一个大型项目中，发现了编译器的一个bug,作为维护者，除了维护源码，你还得维护编译器。天哪，你有这个本事吗？你有这个本事，CEO也不愿意花这个钱呀。
2.调试麻烦。Firebug报了一个错，报的是编译后的行号。老板站在你背后：赶快啦，小伙子！可是这该死的编译后代码，究竟对应哪一行源码呀？
3.招聘不到人。假设你使用Objective-J开发一个项目，但人手不够。赶紧招人，HR说1000个人里面，只有100个听说过Objective-J,另外900个只听说过JavaScript.结局是你每找一个新人，都得先培训一把，真是糟糕透顶。
虽然编译器有以上各种不是，但各种编译器依旧如雨后春笋大量涌现。毫无疑问，编写JavaScript编译器非常酷。给我报酬，我也想写一个。
在上面的编译器列表中，有一个非常有名的引起过很大轰动的：CoffeeScript。我们来谈谈它。
