文章內容如下：
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 superclasss 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。我們來談談它。
CoffeeScript
為什麼CoffeeScript如此火爆？我到現在為止也沒想明白。是因為給空白賦予瞭意義，還是帶箭頭的函數語法？每念及此，我的胃就忍不住波濤洶湧。CoffeeScript有很多新特性：default parameter values, rest parameters, spread, destructuring,fixing the whole implied global mess… CoffeeScript很多特性是Harmony規范的一部分，有可能在未來瀏覽器中直接支持。CoffeeScript 能讓人立刻滿足。
@pyronicide在Twitter上說：#coffeescript 支持函數默認參數值，這太令人興奮瞭。
在TXJS 2011大會上，Douglas Crockford 也表示：CoffeeScript無疑是個好東東。
CoffeeScript: Accelerated JavaScript Development 一書的作者說：
@trevorburnham
[…] CoffeeScript 不是將 JS 變成 Ruby 或 Python,而是通過一套語法，來更好地發揮JavaScript內在的優秀。
Douglas Crockford 認為 JavaScript 有好的方面，並開發瞭JSLint工具來保證開發者遠離JavaScript中的糟粕。JSLint允許的語法子集值得擁有自己的名字，我們不妨稱之為GoodScript.
ECMAScript 5則引入瞭 “use strict” 指令來限制with等語法的使用。
CoffeeScript, GoodScript, ECMAScript 5的目標是一致的：遠離糟粕，同時提供有用的、安全的語言特性給你。
GoodScript沒有提供新特性，ECMAScript 5的嚴格模式，大部分瀏覽器還不支持。然而，我們不想等待。
剩下的選擇是CoffeeScript。好處：
特別適合web開發。這可能是其他JavaScript編譯器沒做或做得不好的地方。
CoffeeScript對JavaScript的封裝適度。這樣能使得編譯後的代碼比較容易閱讀，調試也就不那麼困難瞭。
CoffeeScript看起來就像是書寫JavaScript代碼的一套宏。
CoffeeScript的編譯器提供客戶端版本。這樣，使用者可以自由選擇，開發者也可以快速開發新功能，而不受標準的局限。由社區的願景和需求推動CoffeeScript的發展，這很不錯。
發明自己的語言
你可以去做，這會是一個很好的練習。作為JavaScript編譯器的開發者，將擁有無上榮耀。
發明自己的語言，危險之處在於：你認為最終你將比JavaScript做得更好。語言設計很難，我敢打賭你的語言很難擴大市場份額。CoffeeScript尚未進入青春期，就已經有抱怨的聲音瞭。
你可能會為自己的編譯器能編譯出簡單、可讀的代碼而驕傲。可是，一碰到特殊情況，你就會鬱悶得想撞墻。
你的語言裡將會出現慣用法。接著，你馬上會發現有人會破壞這些慣用法（除非你的語言剛好支持宏）。
風涼話就不多說瞭。立刻去開發自己的語言吧，你會成為一個很好的程序員。
作為編譯目標語言，JavaScript缺少什麼？
作為編譯目標語言，JavaScript重獲新生。在 JSConf.US talk中，Brendan Eich表示：Harmony規范的目的是讓JavaScript成為更好的編譯目標。
編譯後的JavaScript有可能比手寫的JavaScript運行效率更低，這就和編譯後的C有可能比手寫的匯編語言效率更低一樣。幸運的是，JavaScript的瓶頸主要在DOM操作上，語言本身的效率損耗相對可以接受。雖然話是這麼說，但一些高效的源碼語言編譯後，由於JavaScript本身的問題，可能極其低效，以致於無法在真實環境中使用。Harmony規范中已經有部分特性能保證避免這類問題。
合理的尾部調用
function isEven(number) {
if (number === 0) {
return true;
}
else {
return isOdd(number – 1);
}
}
function isOdd(number) {
if (number === 0) {
return false;
}
else {
return isEven(number – 1);
}
}
isEven(100000); // InternalError: too much recursion
上面的代碼，在目前的瀏覽器中運行，會堆棧溢出。
可以通過蹦床(trampolines)技巧來優化：
function bounce(ret) {
while (typeof ret === function) {
retret = ret();
}
return ret;
}
function isEven(number) {
if (number === 0) {
return true;
}
else {
return function() {
return isOdd(number – 1);
};
}
}
function isOdd(number) {
if (number === 0) {
return false;
}
else {
return function() {
return isEven(number – 1);
};
}
}
bounce(function() {return isEven(100000);}); // true
通過bounce 方式，在運行 isOdd(99999)時，isEven(100000)已經完成並從堆棧中退出瞭，因此不會造成溢出。
幸運地是，ECMAScript Harmony已經考慮到瞭這一點，會自動進行優化。這對程序開發者和編譯器開發者都是有益的。
Lambdas
lambda並不神奇。簡言之，lambda就是可調用的東西，比如function,但需要遵守TCP（Tennent一致性原則，Tennent’s Correspondence Principle）。TCP要求：用一個緊鄰的lambda對表達式或代碼塊進行封裝，不會改變被封裝的代碼的含義。
很顯然，JavaScript 的 function 不是 lambda:
function one() {
return 1;
}
one(); // 1
封裝後，返回值發生瞭變化：
function one() {
(function() {
return 1;
}());
}
one(); // undefined
對於接受兩個參數並將其求和的代碼塊，lambda 語法提議寫成：{|a, b| a + b}
對於上面的例子，采用 lambda 封裝將保證返回值和封裝前一樣：
function one() {
({||
return 1;
}());
}
one(); // 1
lambda 塊的稻草人提案目前還沒有提升到 Harmony 規范中，讓我們一起努力吧。
瀏覽器缺少什麼？
JavaScript的興衰存亡離不開瀏覽器。JavaScript的新生，也需要瀏覽器的靠譜支持。
Mozilla發起瞭一個SourceMap項目，這可以使得在調試編譯後的代碼時，能映射回源碼的對應代碼行。這太cool瞭，能極大的減少調試成本。
聽說Webkit的小夥子們也在幹同樣的事情，可惜我找不到任何證據瞭。
通曉數種語言
JavaScript在瀏覽器上的壟斷，意味著前端程序員都會同一門語言。然而，編譯器的差異性，會使得CoffeeScript程序員，很難立刻看懂基於Traceur的JavaScript代碼。
這種分歧不可避免。比如有C,同時有C++和Objective-C等各種語言。Java也一樣，基於JVM還可以選擇Clojure或JRuby。微軟意識到這一點，開發CLR.C#,Basic,IronPython等都可以運行在CLR上。
前端中的溝通障礙並非新鮮事物。一個Dojo程序員，難以立刻明白基於jQuery或YUI的代碼。
擁有多種源碼書寫語言會增加社區的溝通障礙。程序員仍需要瞭解JavaScript.至少一段時間內程序員還需要懂得JavaScript。但在短短幾年後，他們可能會更瞭解其他源碼語言。
總結
能有機會目睹JavaScript的新生，是件很棒的事情。在JavaScript編譯的競爭中，很難說誰會最終贏得市場份額，但毫無疑問，這肯定會很有趣。如今，CoffeeScript蓄勢待發，但我相信許多其他成功的源碼語言將接踵而至。