從今天起，我將陸續將 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打開的窗口不能小於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運行在：標准兼容的，無障礙的網頁中。