Javascript诞生记:C语言和Self语言一夜情的产物
"1994年,网景公司(Netscape)发布了Navigator浏览器0.9版。这是历史上第一个比较成熟的网络浏览器,轰动一时。但是,这个版本的浏览器只能用来浏览,不具备与访问者互动的能力。......网景公司急需一种网页脚本语言,使得浏览器可以与网页互动。"网页脚本语言到底是什么语言?网景公司当时有两个选择:一个是采用现有的语言,比如Perl、Python、Tcl、Scheme等等,允许它们直接嵌入网页;另一个是发明一种全新的语言。 这两个选择各有利弊。第一个选择,有利于充分利用现有代码和程序员资源,推广起来比较容易;第二个选择,有利于开发出完全适用的语言,实现起来比较容易。 到底采用哪一个选择,网景公司内部争执不下,管理层一时难以下定决心。 3. 就在这时,发生了另外一件大事:1995年Sun公司将Oak语言改名为Java,正式向市场推出。 Sun公司大肆宣传,许诺这种语言可以"一次编写,到处运行"(Write Once, Run Anywhere),它看上去很可能成为未来的主宰。 网景公司动了心,决定与Sun公司结成联盟。它不仅允许Java程序以applet(小程序)的形式,直接在浏览器中运行;甚至还考虑直接将Java作为脚本语言嵌入网页,只是因为这样会使HTML网页过于复杂,后来才不得不放弃。 总之,当时的形势就是,网景公司的整个管理层,都是Java语言的信徒,Sun公司完全介入网页脚本语言的决策。因此,Javascript后来就是网景和Sun两家公司一起携手推向市场的,这种语言被命名为"Java+script"并不是偶然的。 4. 此时,34岁的系统程序员Brendan Eich登场了。1995年4月,网景公司录用了他。 Brendan Eich的主要方向和兴趣是函数式编程,网景公司招聘他的目的,是研究将Scheme语言作为网页脚本语言的可能性。Brendan Eich本人也是这样想的,以为进入新公司后,会主要与Scheme语言打交道。 仅仅一个月之后,1995年5月,网景公司做出决策,未来的网页脚本语言必须"看上去与Java足够相似",但是比Java简单,使得非专业的网页作者也能很快上手。这个决策实际上将Perl、Python、Tcl、Scheme等非面向对象编程的语言都排除在外了。 Brendan Eich被指定为这种"简化版Java语言"的设计师。 5. 但是,他对Java一点兴趣也没有。为了应付公司安排的任务,他只用10天时间就把Javascript设计出来了。 由于设计时间太短,语言的一些细节考虑得不够严谨,导致后来很长一段时间,Javascript写出来的程序混乱不堪。如果Brendan Eich预见到,未来这种语言会成为互联网第一大语言,全世界有几百万学习者,他会不会多花一点时间呢? 总的来说,他的设计思路是这样的:
(1)借鉴C语言的基本语法; (2)借鉴Java语言的数据类型和内存管理; (3)借鉴Scheme语言,将函数提升到"第一等公民"(first class)的地位; (4)借鉴Self语言,使用基于原型(prototype)的继承机制。所以,Javascript语言实际上是两种语言风格的混合产物 ----(简化的)函数式编程+(简化的)面向对象编程。这是由Brendan Eich(函数式编程)与网景公司(面向对象编程)共同决定的。 6. 多年以后,Brendan Eich还是看不起Java。 他说:
"Java(对Javascript)的影响,主要是把数据分成基本类型(primitive)和对象类型(object)两种,比如字符串和字符串对象,以及引入了Y2K问题。这真是不幸啊。"把基本数据类型包装成对象,这样做是否可取,这里暂且不论。Y2K问题则是直接与Java有关。根据设想,Date.getYear()返回的应该是年份的最后两位:
var date1 = new Date(1999,0,1); var year1 = date1.getYear(); alert(year1); // 99但是实际上,对于2000年,它返回的是100!
var date2 = new Date(2000,0,1); var year2 = date2.getYear(); alert(year2); // 100如果用这个函数生成年份,某些网页可能出现"19100"这样的结果。这个问题完全来源于Java,因为Javascript的日期类直接采用了java.util.Date函数库。Brendan Eich显然很不满意这个结果,这导致后来不得不添加了一个返回四位数年份的Date.getFullYear()函数。 如果不是公司的决策,Brendan Eich绝不可能把Java作为Javascript设计的原型。作为设计者,他一点也不喜欢自己的这个作品:
"与其说我爱Javascript,不如说我恨它。它是C语言和Self语言一夜情的产物。十八世纪英国文学家约翰逊博士说得好:'它的优秀之处并非原创,它的原创之处并不优秀。'(the part that is good is not original, and the part that is original is not good.)"来自: 阮一峰的网络日志 该贴已经同步到 血のばら的微博
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); //25. 自动插入行尾分号 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存在的最后一天。 来自: 阮一峰的网络日志 该贴已经同步到 血のばら的微博
作为新一代Web语言,HTML5凭借丰富应用、跨平台等特点被公认为未来网页技术的发展方向,并且被全球多家主流厂商寄予厚望。然而,在已经过去的一周, 风头正盛的HTML5却遭受了不小的打击。国外媒体爆料,HTML5在Cookie上的巨大漏洞,将可能短时间内挤爆用户的硬盘。这无疑是给支持HTML5的浏览器厂商泼了一盆冷水,也让用户对于HTML5少了一分“迷信”,多了一分理性。
HTML5漏洞遭曝光
3月4日,国外媒体的一则报道引发了广泛关注。美国22岁的开发者发现了HTML5的一个致命漏洞——大量的Cookie文件的产生将在很短的时间内挤爆用户的硬盘。据这位开发者解释,HTML5的标准中,可以允许网页在用户电脑中保存比过去多的自己定义数据(方式为Cookie)。过去每一个网站可以保存4KB的数据,而HTML5网站根据规范可以保存的数量为2.5MB~10MB不等。比如,用户每次登录Chrome会保存2.5MB的数据,火狐和Opera会保存5MB,而IE则会保存10MB。同时,根据HTML5的技术规范,网站的子域名在发生登录时,必须共享使用网站的Cookie数据保存空间(不得另开空间),可是Chrome、Safari、IE等浏览器没有遵守这一规则。
或许在很多人看来,如今的硬盘容量足够大,就算浏览器厂商不遵守规则,最终产生的数据量也根本算不了什么。然而令人意想不到的是,如果恶意网站进行精心编码,将会借此侵占用户全部的硬盘空间。根据曝光者进行的概念性攻击模型显示,仅仅需要16秒钟,海量的Cookie文件就占用了用户1GB的硬盘空间。这样的结果意味着,你的平板电脑或者手机的硬盘将因此而“挤爆”。
为了让业界更加重视HTML5存在的隐形安全问题,曝光者已经发布了一组代码来利用该漏洞,并专门创建了一个名为Filldisk的网站。同时,他还将此事件报告给了受到影响的浏览器开发商。不过值得一提的是,目前国内浏览器厂商360已经宣布,在第一时间修复了该漏洞,而用户只需升级浏览器版本就可以保证自己免受攻击。
HTML5的漫漫之路
虽然HTML5的漏洞修复工作已经展开,但是这件事情的发生还是给业界提了一个醒儿,作为一项刚刚兴起的技术,HTML5的安全问题需要给予更多关注,尽管早在2011年相关机构和组织就已经开始考虑HTML5的安全问题,并制定了一些技术规范,可是随着HTML5的普及和应用,更多的安全漏洞将出现。而只有充分暴露和修正,未来才能够有足够的安全。
其实,除了安全问题,HTML5的发展还存在诸多的挑战和障碍。3月12日的一则消息,让业界对于HTML5的发展又多了一份担忧。微软对外宣称,将在Windows RT和Windows 8默认启用Flash。对于这一改变,微软的解释是目前绝大多数的Flash内容网站开始兼容Metro下的触摸,使得触摸体验、性能和电池寿命都实现了极大改进,而业界看好并认为可能取代Flash的HTML5,却自2008年第一份草案正式公布后,发展十分缓慢,仍处于完善中。因此在HTML5产品并没有想象中发展那么迅猛的情况下,再加上Flash确实得到了优化,微软在IE10中默认启用Flash,有助于提高用户体验。
从2012年Facebook放弃HTML5,并放言“压宝HTML5是Facebook最大的错误”,到曾经高调支持HTML5的微软也不得不在IE10中默认启用Flash,再加上被媒体高度曝光的漏洞问题,HTML5的发展正在被投下更多的阴影。尤其是在目前标准尚未完善、市场博弈暗流涌动的情况下,人们不禁要对HTML5的未来打上问号。
不过,从长远看HTML5的优势仍然非常明显,主流厂商对其的支持也将发挥更大的作用,且不论HTML5和Flash是否将形成替代关系,HTML5对Web应用的丰富也终将使其在移动互联网时代展现更多“锋芒”。