文章前半部分就談為什么會(huì )這樣，后半部分將列舉Javascript的10個(gè)設計缺陷。

我參考的文獻主要是Douglas Crockford的專(zhuān)著(zhù)《Javascript語(yǔ)言精粹》（JavaScript: The Good Parts）和Fredrik Holmström的文章《我對Javascript的抱怨》（My gripes with Javascript）。

一、為什么Javascript有設計缺陷？

這里有三個(gè)客觀(guān)原因，導致Javascript的設計不夠完善。

1. 設計階段過(guò)于倉促

Javascript的設計，其實(shí)只用了十天。而且，設計師是為了向公司交差，本人并不愿意這樣設計（參見(jiàn)《Javascript誕生記》）。

另一方面，這種語(yǔ)言的設計初衷，是為了解決一些簡(jiǎn)單的網(wǎng)頁(yè)互動(dòng)（比如，檢查"用戶(hù)名"是否填寫(xiě)），并沒(méi)有考慮復雜應用的需要。設計者做夢(mèng)也想不到，Javascript將來(lái)可以寫(xiě)出像Gmail這種極其龐大復雜的網(wǎng)頁(yè)。

2. 沒(méi)有先例

Javascript同時(shí)結合了函數式編程和面向對象編程的特點(diǎn)，這很可能是歷史上的第一例。而且直到今天為止，Javascript仍然是世界上唯一使用Prototype繼承模型的主要語(yǔ)言。這使得它沒(méi)有設計先例可以參考。

3. 過(guò)早的標準化

Javascript的發(fā)展非?？?，根本沒(méi)有時(shí)間調整設計。

1995年5月，設計方案定稿；10月，解釋器開(kāi)發(fā)成功；12月，向市場(chǎng)推出，立刻被廣泛接受，全世界的用戶(hù)大量使用。Javascript缺乏一個(gè)從小到大、慢慢積累用戶(hù)的過(guò)程，而是連續的爆炸式擴散增長(cháng)。大量的既成網(wǎng)頁(yè)和業(yè)余網(wǎng)頁(yè)設計者的參與，使得調整語(yǔ)言規格困難重重。

更糟的是，Javascript的規格還沒(méi)來(lái)及調整，就固化了。

1996年8月，微軟公司強勢介入，宣布推出自己的腳本語(yǔ)言Jscript；11月，為了壓制微軟，網(wǎng)景公司決定申請Javascript的國際標準；1997年6月，第一個(gè)國際標準ECMA-262正式頒布。

也就是說(shuō)，Javascript推出一年半之后，國際標準就問(wèn)世了。設計缺陷還沒(méi)有充分暴露就成了標準。相比之下，C語(yǔ)言問(wèn)世將近20年之后，國際標準才頒布。

二、Javascript的10個(gè)設計缺陷

1. 不適合開(kāi)發(fā)大型程序

Javascript沒(méi)有名稱(chēng)空間（namespace），很難模塊化；沒(méi)有如何將代碼分布在多個(gè)文件的規范；允許同名函數的重復定義，后面的定義可以覆蓋前面的定義，很不利于模塊化加載。

2. 非常小的標準庫

Javascript提供的標準函數庫非常小，只能完成一些基本操作，很多功能都不具備。

3. null和undefined

null屬于對象（object）的一種，意思是該對象為空；undefined則是一種數據類(lèi)型，表示未定義。

　　typeof null; // object

　　typeof undefined; // undefined

兩者非常容易混淆，但是含義完全不同。

　　var foo;

　　alert(foo == null); // true

　　alert(foo == undefined); // true

　　alert(foo === null); // false

　　alert(foo === undefined); // true

在編程實(shí)踐中，null幾乎沒(méi)用，根本不應該設計它。

4. 全局變量難以控制

Javascript的全局變量，在所有模塊中都是可見(jiàn)的；任何一個(gè)函數內部都可以生成全局變量，這大大加劇了程序的復雜性。

　　a = 1;

　　(function(){

　　　　b=2;

　　　　alert(a);

　　})(); // 1

　　alert(b); //2

5. 自動(dòng)插入行尾分號

Javascript的所有語(yǔ)句，都必須以分號結尾。但是，如果你忘記加分號，解釋器并不報錯，而是為你自動(dòng)加上分號。有時(shí)候，這會(huì )導致一些難以發(fā)現的錯誤。

比如，下面這個(gè)函數根本無(wú)法達到預期的結果，返回值不是一個(gè)對象，而是undefined。

　　function(){

　　　　return
　　　　　　{
　　　　　　　　i=1
　　　　　　};

　　}

原因是解釋器自動(dòng)在return語(yǔ)句后面加上了分號。

　　function(){

　　　　return;
　　　　　　{
　　　　　　　　i=1
　　　　　　};

　　}

6. 加號運算符

+號作為運算符，有兩個(gè)含義，可以表示數字與數字的和，也可以表示字符與字符的連接。

　　alert(1+10); // 11

　　alert("1"+"10"); // 110

如果一個(gè)操作項是字符，另一個(gè)操作項是數字，則數字自動(dòng)轉化為字符。

　　alert(1+"10"); // 110

　　alert("10"+1); // 101

這樣的設計，不必要地加劇了運算的復雜性，完全可以另行設置一個(gè)字符連接的運算符。

7. NaN

NaN是一種數字，表示超出了解釋器的極限。它有一些很奇怪的特性：

　　NaN === NaN; //false

　　NaN !== NaN; //true

　　alert( 1 + NaN ); // NaN

與其設計NaN，不如解釋器直接報錯，反而有利于簡(jiǎn)化程序。

8. 數組和對象的區分

由于Javascript的數組也屬于對象（object），所以要區分一個(gè)對象到底是不是數組，相當麻煩。Douglas Crockford的代碼是這樣的：

　　if ( arr &&
　　　　typeof arr === 'object' &&
　　　　typeof arr.length === 'number' &&
　　　　!arr.propertyIsEnumerable('length')){

　　　　alert("arr is an array");

　　}

9. == 和 ===

==用來(lái)判斷兩個(gè)值是否相等。當兩個(gè)值類(lèi)型不同時(shí)，會(huì )發(fā)生自動(dòng)轉換，得到的結果非常不符合直覺(jué)。

　　"" == "0" // false

　　0 == "" // true

　　0 == "0" // true

　　false == "false" // false

　　false == "0" // true

　　false == undefined // false

　　false == null // false

　　null == undefined // true

　　" \t\r\n" == 0 // true

因此，推薦任何時(shí)候都使用"==="（精確判斷）比較符。

10. 基本類(lèi)型的包裝對象

Javascript有三種基本數據類(lèi)型：字符串、數字和布爾值。它們都有相應的建構函數，可以生成字符串對象、數字對象和布爾值對象。

　　new Boolean(false);

　　new Number(1234);

　　new String("Hello World");

與基本數據類(lèi)型對應的對象類(lèi)型，作用很小，造成的混淆卻很大。

　　alert( typeof 1234); // number

　　alert( typeof new Number(1234)); // object

關(guān)于Javascript的更多怪異行為，請參見(jiàn)Javascript Garden和wtfjs.com。

三、如何看待Javascript的設計缺陷？

 

 
1：兼容性低

 

在WWW 上有很多瀏覽器，如Netscape Navigator,Mosaic和HotJava等，但每種瀏覽器支持JavaScript的程度是不一樣的，支持和不完全支持JavaScript的 瀏覽器在瀏覽一個(gè)帶有JavaScript腳本的主頁(yè)時(shí)，效果會(huì )有一定的差距，有時(shí)甚至會(huì )顯示不出來(lái)。

 
結果，javascript的開(kāi)發(fā)人員常常需要針對不同的瀏覽器開(kāi)發(fā)不同的版本。無(wú)形中工作量增加，而且基本上全都是重復性的工作。這是我們所不愿意看到的

 
2：造成內存泄漏
JavaScript是內存管理的語(yǔ)言。這意味著(zhù)JavaScript具有內置的信息包收集功能，因此能夠抽取不再有引用路徑使用的變量并重新分配這些變量所使用的內存。

作為基本工作原理這很好，但是在模型對象和察看元素之間互相引用時(shí)，由于這些循環(huán)引用，你就不能依靠這個(gè)功能來(lái)實(shí)現你的內存使用最優(yōu)化。從原則上講，對象為零，則元素為零，但是如果這時(shí)從元素到對象的向后引用，那么信息包搜集器不會(huì )動(dòng)這些對象。

現在，問(wèn)題出來(lái)了：在文件對象模型中，任何文件樹(shù)中的DOM節點(diǎn)都可能被樹(shù)中的其它元素引用，不論其是否被其他對象所引用！因此任何在信息包收集器中經(jīng)過(guò)標注的被DOM節點(diǎn)向后引用的對象，在這一方向必須為空，否則其內存就會(huì )一直處于已分配狀態(tài)。而實(shí)際上，程序員常常忽視這點(diǎn)。這就是為什么很多大型網(wǎng)頁(yè)游戲打開(kāi)后內存嗖嗖的往上飚。

3：對流媒體的支持

無(wú)，只能使用內嵌其他播放器的方法。
 

Javascript最初的設計目標是“讓網(wǎng)頁(yè)動(dòng)起來(lái)”。這一點(diǎn)，它已經(jīng)實(shí)現了，而且還有一些突破。但是，“動(dòng)起來(lái)”只是“動(dòng)起來(lái)”，這是不夠的。在Javascript面對Rich application的時(shí)候，它就有些力不從心了。
 

現在，如果要討論javascript的發(fā)展，不應該局限于Javascript，而應該從HTML(DHTML),DOM,Javascript,CSS聯(lián)合考慮。從瀏覽器應用程序（請原諒我發(fā)明了這個(gè)詞“瀏覽器應用程序”）的角度出發(fā)。

 

 

 

既然Javascript有缺陷，數量還不少，那么它是不是一種很糟糕的語(yǔ)言？有沒(méi)有前途？

回答是Javascript并不算糟糕，相反它的編程能力很強大，前途很光明。

首先，如果遵守良好的編程規范，加上第三方函數庫的幫助，Javascript的這些缺陷大部分可以回避。

其次，Javascript目前是網(wǎng)頁(yè)編程的唯一語(yǔ)言，只要互聯(lián)網(wǎng)繼續發(fā)展，它就必然一起發(fā)展。目前，許多新項目大大擴展了它的用途，node.js使得Javascript可以用于后端的服務(wù)器編程，coffeeScript使你可以用python和ruby的語(yǔ)法，撰寫(xiě)Javascript。

最后，只要發(fā)布新版本的語(yǔ)言標準（比如 ECMAscript 5），就可以彌補這些設計缺陷。當然，標準的發(fā)布和標準的實(shí)現是兩回事，上述的很多缺陷也許會(huì )一直伴隨到Javascript存在的最后一天。

---