JavaScript的目的分析

ppk是我所景仰的一位web开发者，原因无它，只是因为作为一个JavaScript的开发者来说，他涉及的领域包括web标准，可用性，无障碍等，正是其他开发者所不关注或者故意忽略的。并且，他写了很多案例测试不同的浏览器，总结出JavaScript的接口（API）兼容性，成为JavaScript开发者重要参考资料，几年如一日，这种钻研精神是很多人所缺乏的。

ppk在今年9月出版了他的书，我从去年起就在等的书。今天拿到手，迫不及待地把第一章阅读完毕。果然让人充满惊喜，他的功力非同一般。虽然只是一个初学者，但我认为我已经走在正确的学习道路上。我想，我若能将学习心得分享，能让正在学习的人看到，可以一起交流一起进步，尽管我不敢确保你能从我这里得到什么启发，但我可以确信，我这些笔记会比你拷贝粘贴代码的学习方式更正确。

这本书有十章，章名都简洁明了，分别是：目的，背景，浏览器，准备，核心，BOM, 事件，DOM, CSS更改和数据获取。从来没有一本书能如此简洁地明确JavaScript的方方面面，因此学习不会有太大负担。前言不宜过多，下面就开始我的第一章学习笔记。

开篇宗义：JavaScript的目的是，为网页增加特别的一层可用性。听起来很简单，但这条黄金定律经常被人误解。就算编写有用的JavaScript, 开发者可能还是没能结合适当的情景：Web标准运动发展下，与当代无障碍的HTML页面的配合。更为不妙的是，有些开发者不是为网页增加一层可用性，而是用整层取代之，后果是，如果浏览器不支持JavaScript, 网站就完了。

概念概述

JavaScript是一门由浏览器解释的脚本语言。它通过在客户端而不是服务器端处理某些交互，比如表单验证，创建新菜单来给网站增添可用性。传统的网页交互是，客户端的一举一动都必须经过服务器端的出来才能反馈回来，漫长的等待会让用户崩溃。而JavaScript可以在客户端代替服务器端做某些事情（最明显的，表单验证），从而提高用户体验。

随着时代的发展，JavaScript能够处理越来越多的交互。问题出现了，JavaScript能做这么多事情，到底要多用还是少用？这就有了富与瘦的对决。是整个页面都用JavaScript来控制交互还是只增加些许的JavaScript来增强可用性？就是说，尽可能地使用JavaScript还是有所节制，甚至不用？

瘦客户端很大程度上依赖于客户端－服务器的通讯，而富客户端尽可能限制额外的数据通讯。

哪种方式更好？尽管富客户端带来一些可用性益处，但瘦客户端可能是更“标准”的JavaScript用法。Web被认为是文档集合，而不是界面集合。最明显的证据是，浏览器有后退前进的功能让你在文档中跳转而界面会有么？浏览器可以收藏（书签）文档而界面可以么？从无障碍来说，瘦客户端也更少出错。

这种非平衡性是很难解决的。富客户端当然也可以在更高级的界面做到前进后退，或者收藏，也可以做到完美的无障碍。这必须需要大量的额外工作，但不是每个项目都有超出预算的时间或金钱。此外，太过专注于可用性而忽略无障碍也是一个问题。

那么JavaScript的目的是为富客户端还是瘦客户端服务？答案是：看情况。得看你的网站，你的受众，你的JavaScript水平。

 

技术概述

JavaScript分为六个方面，分别是核心（Core），浏览器对象模型（BOM），事件（Events），文档对象模型（DOM），CSS变更和数据获取（XMLHttpRequest）。

上古时代，NetScape领头之时，NetScape3是事实标准。

当代却没有这么简单。ECMA标准化JavaScript Core, W3C标准化DOM，而BOM尚在WHAT-WG的标准化中，W3C也刚有了XMLHttpRequest的第一份草稿。今天，BOM依然遵循NetScape3的事实标准，而XMLHttpRequest还是遵照Microsoft的原始规范。

JavaScript的目的在于为网站增加可用性，而不是破坏用户的隐私和安全。因此JavaScript不允许读写用户的文件（cookies除外），采取同源策略，只允许来自相同域的交互。不允许读取历史记录，不能为上传文件的表单设置值，由JavaScript控制的窗口关闭需经用户确认，由JavaScript打开的窗口不能小于100×100的窗口，不能移出屏幕之外。

 

JavaScript的历史

探寻历史才能让我们知道JavaScript为什么会被误解得如此深。JavaScript的创造者是Brendan Eich，首次在NetScape 2中实现。它的目的是创建一门足够简单的语言让开发者能容易地为网页增加交互，只要把代码拷贝过来调整一下就可以。这确实令人赞叹，很多JavaScript开发者是从拷贝粘贴开始的。

不幸的是JavaScript生错了名字，也生错了语法。最初它叫LiveScript，但1996年的时候Java炙手可热，NetScape想搭顺风车，于是某产品经理（我想知道她／他是谁，呵呵），命令更名，命令Brendan Eich让“Javascript像Java”。这让很多人误认为JavaScript是Java的低级版，不能引起严肃程序员的关注。

1996年之时，NetScape 3是王，Microsoft只能照抄。这是一个难得的和谐期，当然，那时候浏览器比起现在来“瘦”了，仅限于表单验证，鼠标轮换的一些小花招而已。

接下来就是影响深远的浏览器大战了。为了争夺市场，两家浏览器纷纷实现不同的东西，谁都想成为事实标准。最有名的就是NetScape 4的document.layer和IE 4的document.all（忘记它们吧！）。它们让DHTML流行起来。

1999年Microsoft以推出良好支持CSS和DOM的IE5胜出，NetScape的让位终于有足够的时间让一场革命发生，那就是CSS。WaSP首先从CSS入手，而很多专家也发现／发明了许多浏览器的补救办法，让这场革命成为可能。

2003年，一些先锋们在CSS革命的影响下开始探索新的JavaScript风格，更多地关注无障碍，改观人们对它的坏名声，那就是unobstrusive——把JavaScript从HTML结构层分离出来，遗憾的是，那些在浏览器大战存活下来的程序员可能还没有发现这条新道路。

2005年，Ajax热潮为JavaScript社区注入新的血液。但某些方面，Ajax太像DHTML了，无障碍，是很多Ajax应用的难言之隐。这个热潮趋向于关注技术（如何Ajax），而可用性和交互（为何Ajax）却被低估。最后，各种肿胀的库（现在称为框架）迅速发展起来。

Ajax依然全速前进，但这会像DHTML一样结果，人们渐渐失去兴趣，它们会土崩瓦解。

JavaScript兴衰史好像有一定的“定律”支配，我们能打破这个怪圈吗？不管如何，JavaScript开发者在寻找各种酷代码和华而不实的框架之外，更应该调整自己的行动，让JavaScript运行在：标准兼容的，无障碍的网页中。