JavaScript的死與生
JavaScript 很流行，但它有先天缺陷。Brendan Eich 當初只花了10 天時間就把 JavaScript 設計出來了，作為 JavaScript 之父，BE 如是說：
與其說我愛 JavaScript，不如說我恨它。它是 C 語言和 Self 語言一夜情的產物。十八世紀英國文學家約翰遜博士說得好：“它的優秀之處并非原創，它的原創之處并不優秀。”
(摘選自阮一峰的翻譯：JavaScript 誕生記)
JavaScript 的不足，最明顯之處是語法。
糟糕冗長的語法
可選參數和默認值
- function(a, b, option) {
- option = 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
- var element = elements[i];
- LIB_addEventListener(element, 'click', function(event) {
- alert('I was originally number ' + i);
- });
- }
上面的代碼經常在面試題中出現，解決辦法是再包裹一層：
- for (var i=0, ilen=elements.length; 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
- var element = elements[i];
- let (num = i) {
- LIB_addEventListener(element, function(event) {
- alert('I was originally number ' + num);
- });
- };
- }
模塊
模塊模式是一種無奈的選擇：
- var event = (function() {
- // private variables
- var listeners = [];
- function addEventListener(f) {
- listeners.push(f);
- }
- function clearEventListeners() {
- listeners = [];
- }
- // ...
- // export the module's API
- return {
- addEventListener: addEventListener,
- clearEventListeners: clearEventListeners
- // ...
- };
- }());
如果原生支持該多好呀：
- 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);
- Employee.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 position = 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 多年后，再用上這些好用的語法嗎?
#p#
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') {
- ret = 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 蓄勢待發，但我相信許多其他成功的源碼語言將接踵而至。
你的想法呢？
原文鏈接：http://www.starming.com/index.php?action=plugin&v=wave&tpl=union&ac=viewgrouppost&gid=119&tid=1000002685
【編輯推薦】
