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仍然是世界上唯yi使用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的设计缺陷？

 

 
1：兼容性低

 

在WWW 上有很多浏览器，如Netscape Navigator,Mosaic和HotJava等，但每种浏览器支持JavaScript的程度是不一样的，支持和不完全支持JavaScript的 浏览器在浏览一个带有JavaScript脚本的主页时，效果会有一定的差距，有时甚至会显示不出来。

 
结果，javascript的开发人员常常需要针对不同的浏览器开发不同的版本。无形中工作量增加，而且基本上全都是重复性的工作。这是我们所不愿意看到的

 
2：造成内存泄漏
JavaScript是内存管理的语言。这意味着JavaScript具有内置的信息包收集功能，因此能够抽取不再有引用路径使用的变量并重新分配这些变量所使用的内存。

作为基本工作原理这很好，但是在模型对象和察看元素之间互相引用时，由于这些循环引用，你就不能依靠这个功能来实现你的内存使用最优化。从原则上讲，对象为零，则元素为零，但是如果这时从元素到对象的向后引用，那么信息包搜集器不会动这些对象。

现在，问题出来了：在文件对象模型中，任何文件树中的DOM节点都可能被树中的其它元素引用，不论其是否被其他对象所引用！因此任何在信息包收集器中经过标注的被DOM节点向后引用的对象，在这一方向必须为空，否则其内存就会一直处于已分配状态。而实际上，程序员常常忽视这点。这就是为什么很多大型网页游戏打开后内存嗖嗖的往上飚。

3：对流媒体的支持

无，只能使用内嵌其他播放器的方法。
 

Javascript最初的设计目标是“让网页动起来”。这一点，它已经实现了，而且还有一些突破。但是，“动起来”只是“动起来”，这是不够的。在Javascript面对Rich application的时候，它就有些力不从心了。
 

现在，如果要讨论javascript的发展，不应该局限于Javascript，而应该从HTML(DHTML),DOM,Javascript,CSS联合考虑。从浏览器应用程序（请原谅我发明了这个词“浏览器应用程序”）的角度出发。

 

 

 

既然Javascript有缺陷，数量还不少，那么它是不是一种很糟糕的语言？有没有前途？

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

首先，如果遵守良好的编程规范，加上第三方函数库的帮助，Javascript的这些缺陷大部分可以回避。

其次，Javascript目前是网页编程的唯yi语言，只要互联网继续发展，它就必然一起发展。目前，许多新项目大大扩展了它的用途，node.js使得Javascript可以用于后端的服务器编程，coffeeScript使你可以用python和ruby的语法，撰写Javascript。

后面，只要发布新版本的语言标准（比如 ECMAscript 5），就可以弥补这些设计缺陷。当然，标准的发布和标准的实现是两回事，上述的很多缺陷也许会一直伴随到Javascript存在的后面一天。

---