JavaScript 的目的
从今天起，我将陆续将 ppk on JavaScript 的读书心得发布到这个 blog 上。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 打开的窗口不能小于 100x100 的窗口，不能移出屏幕之外。
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 运行在：标准兼容的，无障碍的网页中。