從今天起，我將陸續將 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運行在：標準相容的，無障礙的網頁中.
