前幾篇文章，我經常說Javascript的設計不夠嚴謹，有很多失誤。
今天的這一篇，前半部分就談為什麼會這樣，後半部分將列舉Javascript的10個設計缺陷。
我參考的文獻主要是Douglas Crockford的專著《Javascript語言精粹》（JavaScript: The Good Parts）和Fredrik Holmström的文章《我對Javascript的抱怨》（My gripes with Javascript）。
一、為什麼Javascript有設計缺陷？
這裡有三個客觀原因，導致Javascript的設計不夠完善。
1. 設計階段過於倉促
Javascript的設計，其實只用了十天。而且，設計師是為了向公司交差，本人並不願意這樣設計（參見《Javascript誕生記》）。
另一方面，這種語言的設計初衷，是為了解決一些簡單的網頁互動（比如，檢查"使用者名稱"是否填寫），並沒有考慮複雜應用的需要。設計者做夢也想不到，Javascript將來可以寫出像Gmail這種極其龐大複雜的網頁。
2. 沒有先例
Javascript同時結合了函數語言程式設計和麵向物件程式設計的特點，這很可能是歷史上的第一例。而且直到今天為止，Javascript仍然是世界上唯一使用Prototype繼承模型的主要語言。這使得它沒有設計先例可以參考。
3. 過早的標準化
Javascript的發展非常快，根本沒有時間調整設計。
1995年5月，設計方案定稿；10月，直譯器開發成功；12月，向市場推出，立刻被廣泛接受，全世界的使用者大量使用。Javascript缺乏一個從小到大、慢慢積累使用者的過程，而是連續的爆炸式擴散增長。大量的既成網頁和業餘網頁設計者的參與，使得調整語言規格困難重重。
更糟的是，Javascript的規格還沒來及調整，就固化了。
1996年8月，微軟公司強勢介入，宣佈推出自己的指令碼語言Jscript；11月，為了壓制微軟，網景公司決定申請Javascript的國際標準；1997年6月，第一個國際標準ECMA-262正式頒佈。
也就是說，Javascript推出一年半之後，國際標準就問世了。設計缺陷還沒有充分暴露就成了標準。相比之下，C語言問世將近20年之後，國際標準才頒佈。
二、Javascript的10個設計缺陷
1. 不適合開發大型程式
Javascript沒有名稱空間（namespace），很難模組化；沒有如何將程式碼分佈在多個檔案的規範；允許同名函式的重複定義，後面的定義可以覆蓋前面的定義，很不利於模組化載入。
2. 非常小的標準庫
Javascript提供的標準函式庫非常小，只能完成一些基本操作，很多功能都不具備。
3. null和undefined
null屬於物件（object）的一種，意思是該物件為空；undefined則是一種資料型別，表示未定義。
typeof null; // object
typeof undefined; // undefined
兩者非常容易混淆，但是含義完全不同。
var foo;
alert(foo == null); // true
alert(foo == undefined); // true
alert(foo === null); // false
alert(foo === undefined); // true
在程式設計實踐中，null幾乎沒用，根本不應該設計它。
4. 全域性變數難以控制
Javascript的全域性變數，在所有模組中都是可見的；任何一個函式內部都可以生成全域性變數，這大大加劇了程式的複雜性。
a = 1;
(function(){
b=2;
alert(a);
})(); // 1
alert(b); //2
5. 自動插入行尾分號
Javascript的所有語句，都必須以分號結尾。但是，如果你忘記加分號，直譯器並不報錯，而是為你自動加上分號。有時候，這會導致一些難以發現的錯誤。
比如，下面這個函式根本無法達到預期的結果，返回值不是一個物件，而是undefined。
function(){
return
{
i=1
};}
原因是直譯器自動在return語句後面加上了分號。
function(){
return;
{
i=1
};}
6. 加號運算子
+號作為運算子，有兩個含義，可以表示數字與數字的和，也可以表示字元與字元的連線。
alert(1+10); // 11
alert("1"+"10"); // 110
如果一個操作項是字元，另一個操作項是數字，則數字自動轉化為字元。
alert(1+"10"); // 110
alert("10"+1); // 101
這樣的設計，不必要地加劇了運算的複雜性，完全可以另行設定一個字元連線的運算子。
7. NaN
NaN是一種數字，表示超出瞭直譯器的極限。它有一些很奇怪的特性：
NaN === NaN; //false
NaN !== NaN; //true
alert( 1 + NaN ); // NaN
與其設計NaN，不如直譯器直接報錯，反而有利於簡化程式。
8. 陣列和物件的區分
由於Javascript的陣列也屬於物件（object），所以要區分一個物件到底是不是陣列，相當麻煩。Douglas Crockford的程式碼是這樣的：
if ( arr &&
typeof arr === 'object' &&
typeof arr.length === 'number' &&
!arr.propertyIsEnumerable('length')){alert("arr is an array");
}
9. == 和 ===
==用來判斷兩個值是否相等。當兩個值型別不同時，會發生自動轉換，得到的結果非常不符合直覺。
"" == "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
因此，推薦任何時候都使用"==="（精確判斷）比較符。
10. 基本型別的包裝物件
Javascript有三種基本資料型別：字串、數字和布林值。它們都有相應的建構函式，可以生成字串物件、數字物件和布林值物件。
new Boolean(false);
new Number(1234);
new String("Hello World");
與基本資料型別對應的物件型別，作用很小，造成的混淆卻很大。
alert( typeof 1234); // number
alert( typeof new Number(1234)); // object
關於Javascript的更多怪異行為，請參見Javascript Garden和wtfjs.com。
三、如何看待Javascript的設計缺陷？
既然Javascript有缺陷，數量還不少，那麼它是不是一種很糟糕的語言？有沒有前途？
回答是Javascript並不算糟糕，相反它的程式設計能力很強大，前途很光明。
首先，如果遵守良好的程式設計規範，加上第三方函式庫的幫助，Javascript的這些缺陷大部分可以迴避。
其次，Javascript目前是網頁程式設計的唯一語言，只要網際網路繼續發展，它就必然一起發展。目前，許多新專案大大擴充套件了它的用途，node.js使得Javascript可以用於後端的伺服器程式設計，coffeeScript使你可以用python和ruby的語法，撰寫Javascript。
最後，只要釋出新版本的語言標準（比如 ECMAscript 5），就可以彌補這些設計缺陷。當然，標準的釋出和標準的實現是兩回事，上述的很多缺陷也許會一直伴隨到Javascript存在的最後一天。
（完）