JavaScript的目的分析
2019-11-21 02:22:49
供稿：網友
從今天起，我將陸續將 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變更和數據獲?。╔MLHttpRequest）。
上古時代，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運行在：標準兼容的，無障礙的網頁中。
