歡迎下載： AJAX——新手快車道

　　我有很濃厚的“地圖情結”，以前我寫過一篇《我的信仰地圖》，最近又做了一次關于Ajax的演講，名字叫做《Ajax技術地圖》。我一直以來的觀點是，世界是一個整體，在這個巨大的世界之中，任何事物、任何知識，任何觀點，都有其合理、自然的位置。理解這個世界的過程，就是逐步將需要了解的各種事物，在作為整體的一個世界中，找到其位置。了解這個位置的前后左右，相互關系，相互影響。這樣的理解世界的學習方式，我認為是最為有效的。所以當我在JavaEye看到關于《代碼大全》的廣告時，我的第一反應就是：這不是世界地圖嗎？
?
　　看了看他的目錄，竟然有35章之多？架構、分析、設計、編程、測試、重構、面向對象、調試、規范、管理、軟件質量控制、協作、優化、開發工具、注釋、甚至個性、開發藝術等等等等，只要是與軟件有關的，基本上他都寫到了。
?
　　說實話，我當時相當的不屑......可能嗎？居然有這么一個家伙，能夠像當年的托馬斯?阿奎那一樣，以一己之力，寫出《神學大全》？CSDN的網站上介紹這個Steve McConnell，在1998年的時候，被Software Development雜志的讀者評為軟件業最具影響力的三大人物之一，與Bill Gates、Linus Torvalds齊名。一個寫書的，能和兩個寫代碼的天才齊名？網站上的那些推薦的話，個個都是大名鼎鼎，個個都是推崇備至。作為我這樣一個有逆反心里的家伙來說，直覺上就是：“會不會呀，有這么牛嗎？”

?

　　當然了，我也不好多說什么，畢竟沒有看過書～～～

?

　　沒想到好事居然找上門來了，博文視點的魏泉是我要寫的那本Ajax書的責任編輯。而《代碼大全》也是他們負責出版的。那天他找到我，說是讓我看看這本書的書稿……看看能不能寫一篇書評。這等美差，我很爽快的就答應下來了。

?

　　一看之下，果然是很喜歡，作者的思考問題的方式，與我的方式相當的接近，都是盡可能將多種、甚至矛盾的事物，放在一個整體的環境中來理解。比如對于隱喻，用于描述軟件開發的特征的各種各樣的隱喻，其實各有其價值，如果能夠組合運用，自然能夠獲得一種平衡。正如作者所說：“使用隱喻又是件說不清楚的事情（fuzzy business）。你需要適當地引申它的含義，才能從其中蘊含的深刻啟發中受益。但若你過分地或者在錯誤的方向上引申了它的含義，它也會誤導你。正如人們會誤用任何強大的工具一樣，你也可能誤用隱喻，但它的強大的功效，還是會成為你智慧工具箱中的一個寶貴部分。”

?

　　這樣的一種看法，可以說“中正平和、深具智慧”，這是我們在大多數關于軟件開發的論述中，很難看到的。

?

　　再比如說，作者在第三章時給出的一個表格：三種常見的軟件項目種類，及其典型的良好實踐。就將軟件分為商業系統、性命攸關的系統以及性命攸關的嵌入式系統。然后指出對于這三類不同的應用，在開發手段、管理強度、設計、構建、測試、部署等等方面的差別化策略。這樣的分類，自然就避免了將各種開發手段，簡單的對立起來比較的方法，顯得更加具有說服力。

?

　　再比如說，全書給出了相當多的Check List，這樣的表格，實在是大有益處，借用地圖的隱喻來書，這樣的CheckList，就是一個一個的定位器，它能夠幫助你認清自己的位置，了解問題所屬的范疇，了解應該努力的大致方向。這樣的“開發工具”，真是獨一無二。

?

　　這本書我目前只看了前面的5～6章，實在沒有太多的發言權，不過我現在已經可以肯定，這是一本非常有價值的好書，我推薦所有沒有看過的朋友去看看這本名副其實的經典之作。

?

　　說實話，天下沒有免費的午餐，我這篇書評，也是屬于交差之作。人家出版社把樣書給你看，請你寫書評，當然希望你能說些好話?幸運的是，這些好話，的確都是我自己愿意說的。

 

PPT的下載地址是：
http://www.ajaxcn.org/space/start/2006-03-13/1/Ajax%E6%8A%80%E6%9C%AF%E5%9C%B0%E5%9B%BE.pps

 

廣州游記和其他感想，就明天再補吧。

莊表偉 說:

JSVM，我覺得有一個方向可以嘗試去發展，就是瀏覽器中的對象管理，起到一個VM的作用

dlee 說:

問題就是你敢不敢去做小白鼠，或者叫做生活在剃刀邊上。對于一個嚴肅的項目，我做項目經理，是不會采用jsvm的。

莊表偉 說:

那為什么你就會采用prototype呢？

dlee 說:

prototype背后有強大的支持，而不是像jsvm那樣只有萬春華同志等很少的幾個鐵桿。

莊表偉 說:

為什么？你是看著哪邊人多去哪邊的嗎？

dlee 說:

你看那些叫喊"頂"、"支持"、"牛"的人會不會貢獻一行代碼。你太容易非黑即白了。當然不完全是這樣，不過支持能力是一個非常重要的考慮因素。

莊表偉 說:

我的意思是，JSVM，該不該用他，只能由我們看過他的代碼以后，來決定？

dlee 說:

你有能力維護所有的代碼嗎？

莊表偉 說:

我只是用他呀，又不是要改他

dlee 說:

我的意思是說，如果你在項目中使用了Spring，Rod Johnson玩累了，明天就宣布解散這個項目。你自己獨立去維護Spring的代碼。你去用什么啊，它只有很少的UI組件，其中還有問題。 你不要夸口這些自己都能開發好，我兩年前開發了一個比較好用的Grid，花費了一周多的時間。你自己去實現這樣一個組件后再說話。

莊表偉 說:

我不是用他的UI呀，而是用他的這個框架，來組織自己的代碼。

dlee 說:

你不用它的UI，有什么必要使用這個框架呢？dojo/prototype一樣可以做到啊，我是認為你這樣做引入了不必要的成本。況且你如何判定使用的UI庫在設計理念上與jsvm完全沒有沖突？

莊表偉 說:

OK，你現在已經有結論了，但是我還沒有仔細看過他的代碼呢，所以我現在還沒有結論，等我看過以后，自然會有一個結論的。

dlee 說:

在Ajax庫這方面，大部分人都跟我希望的一樣，需要一個全面的解決方案。你說的jsvm專精于做某個領域，我認為是行不通的。任何運行于瀏覽器的js框架都應該是為UI服務的。沒有實現過很多UI組件，如何檢驗它的這個架構設計的合理性？

莊表偉 說:

目前看來，prototype，也只是專精于基礎領域的，在它之上，另有script.aculo.us、Rico、Behaviour這樣的lib

dlee 說:

你喜歡擺擂臺，那么就擺個擂臺，大家都實現Grid組件，看看誰做得好。

莊表偉 說:

呵呵，這倒是個好辦法

dlee 說:

你可以跟醒來來詳細討論，問題不是你想想得那么簡單。做小白鼠也有好處，曉鋼就經常偷偷練習一些自己的獨門絕技。

莊表偉 說:

呵呵

dlee 說:

你可以將我跟他的沖突理解為主要在一個領域，就是我不認為解決他所說的兩個問題，需要這么重的方案。而且他的解決方案從JS開發者的角度看來也不是很優雅。

莊表偉 說:

嗯，這兩點，我基本上是同意的

dlee 說:

萬春華同志的興趣不在UI組件方面，這使得他偏離了瀏覽器JS誕生的使命。今天我跟醒來說過類似的意思。 我們的分歧不完全在技術本身上面。因為我們思考問題的思路差別很大，所以沒有出現很大的交集

莊表偉 說:

嗯，我比較理解你的意思了，但是，我不是很同意...

dlee 說:

你看過他們的代碼了嗎？

莊表偉 說:

看了一些

dlee 說:

代碼的模塊程度如何？有沒有可能將醒來說的一些部分完全去掉？

莊表偉 說:

哪些部分？

dlee 說:

我覺得他們如果做一些更加清晰的劃分，劃分出一個最小的core部分，而且像Spring那樣劃分成很多不同的jar，這樣會更好一些。最糟的情況是要么全有要么全無

 

  醒來 已經添加到此對話中。

 

dlee 說:

你既然對jsvm非常感興趣，就和醒來先詳細談談。我作為旁聽好了。

莊表偉 說:

呵呵，好的呀

醒來 說:

好啊，我 最近剛看了jsvm的源碼

莊，你覺得jsvm怎么樣

莊表偉 說:

我剛開始看他的代碼。說實話，我覺得他的js代碼寫得非常好，也很干凈、清楚。因此，這樣的一個人，寫出這樣水平的代碼的人，對于js的理解，肯定是相當深入的。

醒來 說:

代碼寫的是真不錯

莊表偉 說:

我以前曾經想當然的認為，他不了解js，只喜歡java，所以才會把js，扭曲成java的樣子這樣的想法，肯定是偏見。那么，在承認對方有足夠的智力與經驗的前提下，再來看他的代碼，我覺得更不該"斷然否定"，說他"一無是處"。

醒來 說:

我在javaeye 上提出了我的意見，我也認為他的代碼寫得很不錯，但是側重點有點不合時宜。現在真是有些像java虛擬機了，基本是一個classloader + class cache 的實現

莊表偉 說:

還有這個：

a) 獨立模式：standalone, 該模式下，當前頁面的jsvm獨立加載，不和系統中其他頁面的JSVM發生關聯。

b) 應用程序模式：application, 應用程序模式下的頁面會除了加載jsvm以外，還將構造一個Application的環境。其他模塊模式的頁面會共享Application的資源。

c) 模塊模式：module, 模塊模式的頁面必須運行在一個Application模式的頁面下。該頁面可以通過application框架共享資源以及訪問全局變量。

d) 自動模式：auto, 頁面根據環境自動選擇是獨立模式還是模塊模式。

我覺得很有點意思

醒來 說:

從名字上來講，jsvm倒是符合本意。但是java的成功不是只靠一個jvm的，我覺得 jdk 更關鍵

莊表偉 說:

現在的js庫，除了jsvm，都是以一個Page為單位運行的，鮮有"Application"的概念。而VM的提出，我認為，為將來合理的Browser Object Cache Layer，提供了可能

醒來 說:

我有點懷疑，這樣帶來的復雜性有沒有必要

莊表偉 說:

而且我還希望將來JSVM，能夠更好的支持請求任務隊列的管理，這樣的機制，JS的語法本身提供得并不夠好。還有多線程的管理，JS也沒有像Java那樣的，語法級的支持。

dlee 說:

我不大相信瀏覽器中的JS將來會被用在這樣的目的

醒來 說:

其實我覺得，這些應該是瀏覽器提供的功能，在瀏覽器未發展到這個程度之前，強迫javascript畸形的實現，不一定值得

莊表偉 說:

嗯，這是問題的關鍵...我前面的暢想，的確是我希望將來的JS，能夠支持的一部分

dlee 說:

是的，我們希望將來的JS引擎來提供這些基礎設施

莊表偉 說:

現在JSVM，也許能夠支持一部分，也許還不能夠，所以，說不定哪天JS 2.0出來，JSVM就沒有意義了

醒來 說:

所以對于jsvm的模式，應用程序模式還可以理解，模塊模式很難讓人明白有什么用

莊表偉 說:

這是一個思考模式的問題

假設你對于js本身不熟悉，要讓你合理、自然的劃分多個js文件，合理、自然的在該load的時候才去load，這就相當的費力

醒來 說:

所以我的意見就是，jsvm 希望吸引人來開發，應該要給出jsdk 差不多，一個jsvm 吸引不了人

莊表偉 說:

當然，更加正確的道路，當然是按照js的本性來做，提出某種"js loading design pattener"。但是，在經驗還沒有被總結成模式之前，模仿java式的代碼組織，不失為一種方案

醒來 說:

load js 的模式其實現在都是 用一個同步的xmlhttprequest 去加載js,然后eval。這個 dojo 和 prototype 都有提供基礎支持

莊表偉 說:

不是如何loading。而是，我現在有幾百K的js文件，如何切分成合理的大小，然后在需要的時候去調用他們

醒來 說:

這個想法是對的，也是jsvm值得肯定的地方

我的主要意見是說它提供的 jsc 的形式有點雞肋，同時缺乏簡單高效的工具類，所以吸引不了開發人員。jsvm2 的代碼里有 1/3 就是為了支持這個自創的jsc語法

莊表偉 說:

這是...敗筆...。jsc我也不喜歡，混雜了部分js語法和部分java語法...還不如僅僅規定一個必須的頭部，其他的完全采用js語法呢。還有一點我覺得是這個萬兄在那里暢想，就是JSVM打算支持多種語法的設想，工作量太大了。

dlee 說:

不過萬春來同志說這個可以不用

醒來 說:

所以我建議索性拋棄jsc，以萬兄的javascript功力，寫一部分有用的工具類，我覺得不會有人真的愿意用 var map = new HashMap(), map.put(k, v); 這樣的方式寫js

莊表偉 說:

對的

dlee 說:

所以我剛才說：

我覺得他們如果做一些更加清晰的劃分，劃分出一個最小的core部分，而且像Spring那樣劃分成很多不同的jar，這樣會更好一些。最糟的情況是要么全有要么全無。

醒來 說:

jsc 是可以不用，但jsvm 加載了接近80k的js就為了支持jsc, 沒有意義啊

莊表偉 說:

他現在是有多個js的，只是他core的部分太大了

醒來 說:

莊，如果你去看runtime.js 就知道了，jsvm2其實把jsc都預先編譯了，否則效率一定太低

現在甚至還有一些觀點，不要把js分得太多，因為要激發太多的http連接，反而響應性更不好。畢竟js的加載是同步的 ，這各ajax的異步核心思想有沖突。

dlee 說:

這個考慮也是很有道理的

莊表偉 說:

激發太多的http連接？還是激發太多的同步http連接？

dlee 說:

那個所謂的classloader就是向服務器請求一個包含js類的文件，然后evaluate。而且也要考慮evaluate的執行效率

醒來 說:

每一個import 就是一個http 連接。當然，jsvm 考慮到了cache

dlee 說:

對的，就是發出一個xmlhttp請求

莊表偉 說:

其實，他完全可以將自己的jsdk，做成一個jsc文件，一口氣load進來

dlee 說:

不是多個連接，這個要看服務器怎么配置。其實支持http1.1的瀏覽器和服務器都是保持長連接

醒來 說:

jsvm的cache 也有些問題，他所謂的application模式，在不同的瀏覽器上實現各不相同，ie是js源碼用ie的htc 技術保存的，ff 是存cookie。cookie 的容量是有限制的，所以cache 主要是針對 ie。

dlee 說:

可能是在同一個http連接上發送多個http請求，這些請求需要排隊

莊表偉 說:

OK，我提一個方案，你們看是不是可以作為"最佳實踐"之一：

對于多個異步請求，可以讓他分次異步提交。

對于多個同步請求，應該將多個請求打包以后一次提交。

這個作為"請求隊列管理"的一部分

醒來 說:

道理應該是這樣，jsvm里好像沒有這樣的控制，import語句也沒有這么智能

莊表偉 說:

其實jsvm應該這么做，比如他load一個jsc文件進來，里面的import語句可能有一堆，就應該是一口氣load其他的jsc，不該再分多次了

醒來 說:

我總覺得 線程/隊列 這些該是瀏覽器的事情，用js開發很不保險

莊表偉 說:

你看過我寫的那個RSSReader的代碼嗎？里面就有一個請求隊列的

醒來 說:

jsvm做不到，因為load的jsc里又有import 語句，這是遞歸的

莊表偉 說:

不是遞歸，是分層的

醒來 說:

要么js語言升級，要么瀏覽器升級，我總覺得現階段就想讓ajax完全達到替代桌面應用的程度是不可能的

莊表偉 說:

這個當然是不可能的...

醒來 說:

所以在現階段，還是不要搞復雜了，多線程和隊列能用到的地方畢竟不多

我覺得dlee強調的對的，現在需要的是組件

語言級別的東西，就讓js語言和瀏覽器標準去慢慢支持吧

莊表偉 說:

我理解你們所認為的"輕重緩急"了。根本的觀點在于："急于將瀏覽器中應用，推向完全的桌面應用，并不現實"。立足于"更好的瀏覽器端應用"，而非"盡可能像桌面應用的瀏覽器端應用"，這么說來，當務之急自然是UI控件的完善與豐富

dlee 說:

我覺得瀏覽器中js誕生的使命就是改善交互和UI

醒來 說:

對，就是這個意思

dlee 說:

而且我從項目開發負責人的角度，更希望一個全面的解決方案。不是什么都需要我去做集成

莊表偉 說:

JSVM的問題，不在于他語法上像Java，而在于他的目標上像Java！

dlee 說:

也可以這樣來理解

醒來 說:

ajax 里的cache 應該是去cache 數據，用來cache js代碼，意義多大呢，所以jsvm太技術化了

dlee 說:

在Ajax in Action中，提出了一種獨占式應用。就是像Word一樣，可能每天都要用上幾個小時。目前的Ajax技術，包括一些基礎框架，還很難達到這個要求。所以確實需要這樣一類基礎架構，但是我們認為這些支持最好由瀏覽器和JS引擎來提供。

莊表偉 說:

看來我們已經初步達成共識了

醒來 說:

js 就是用來操作DOM的，不要讓它承擔太多重任，xmlhttp本來也不是 js的一部分，瀏覽器的擴展而以

dlee 說:

我發現現在很多人有一個通病。就跟我在那個ajax和model2框架的討論中說的那樣。毫不思考地就將一種技術或者架構用于設計意圖之外的場合。其實把IFrame用于異步請求也是這個情況

醒來 說:

對jsvm 的建議就是拋棄jsc，完善它自己的面向對象架構，并提供工具類支持，這樣才有可能和 dojo 有競爭。所以在國外是稱為  tricks,  是有貶義的意思，但翻譯成中文，變成竅門，反而有了褒義了

dlee 說:

Ajax in Action的作者稱作hacky的做法，帶有貶義

dlee 說:

令Ajax顯得與眾不同的地方不是它所使用的技術本身，而是通過使用這些技術所帶來的新的交互模式。我們所習慣的傳統的Web交互模型并不適合于獨占式的應用，只有打破了這種交互模型，新的可能性才會慢慢浮現出來。

這是Ajax in Action的一句話，說得非常有道理。我們看到如此眾多的人都對Ajax感興趣不是偶然的。現在我們處在web app發生革命性變化的前夕

莊表偉 說:

嗯，我更關注：慢慢浮現出來的這些可能性中，哪些是正道，哪些是邪道

醒來 說:

我是覺得一定要擦亮眼睛，多從用戶的角度想問題

莊表偉 說:

這是對的

AJAX——新手快車道

 

前言

 

AJAX是什么？

 

首先、AJAX是一種很酷的技術，一旦采用了AJAX，就能讓你的Web頁面，你的網站，甚至連同你們公司，都變得很酷。在Web2.0的時代里，不使用一點AJAX技術的網站，就會顯得很老土，很落伍。

 

但是，這樣的理解，其實是很膚淺的。僅僅是從一個外行，從一個使用者的角度出發，來理解AJAX，就像我在本書的第一章AJAX我也行中那樣，開發出很愚蠢，甚至都沒有資格被稱之為AJAX應用的純IE、XMLHTTP應用。

 

AJAX更酷的一點在于，對于傳統的Web開發人員來說，AJAX所運用的，是更加先進的，更加標準化的，更加和諧高效的，完整的Web開發技術體系。遵循這樣的體系開發Web應用，能讓你的開發過程變得更加輕松，也能使你們的開發團隊，顯得很酷。在Web2.0的時代里，還在采用過時的技術來開發Web，會顯得很老土，很落伍。

 

AJAX的相關組成技術，每一個都已經出現了N年以上了，對這些技術的組合運用，也遠遠早于AJAX這個名詞出現之前。所以，我真正敬佩的，并非提出
AJAX這個縮寫的Jesse James Garrett。而是那些早在N年以前，就已經在探索、實踐的先行者，他們始終在追求的：是更好的用戶體驗，以及更好的開發體驗。這樣的精神，才是最可寶貴的，也是最值得我們學習的。許多年過去以后，當我們再回頭來看當年的這些熱門技術，也許早已經變得老土，變得落伍了。在這樣的歷程中，哪些人會成長為高手？會成長為大師呢？就是那些永不滿足，永遠在追求更好的用戶體驗，永遠在追求更好的開發體驗的人！

 

新手如何上路

 

軟件開發這個領域，永遠都在飛速發展，大家都必須不斷的學習新的知識、技能、框架、IDE、甚至新的語言。傳說中的骨灰級高手們，就像傳說中的大俠，任何武器、哪怕是一塊木頭到了他們手里，也能發揮驚人的威力，人家練了幾十年的看家本領，他們隨手使來，也竟然像是打娘胎里就開始練了一樣。為什么？

 

就算不吹那么玄的，平常我們能夠碰到的那些老手，在學新東西的時候，也比那些新手學得更快，理解得更深，運用得更熟練。而新手們呢？往往就會漫無頭緒，焦頭爛額，以一副張著茫然的大眼睛的經典表情，出現在各大論壇的新手求助區里。他們欠缺的，究竟是什么呢？為什么老手學新東西，就沒遇到那么多困難呢？

 

泛泛地說，自然是經驗上的欠缺。仔細地說來，又可以分為三個方面：

 

一、本質，一種技術與另一種技術之間，往往會有本質上的相通之處，當你對一種技術的理解與思考越來越深入時，學習一種新技術也會更加容易。觸類旁通，舉一反三的能力，就是來自于對于技術本質的追尋。

 

二、地圖，本質上或多或少的相通，也提示著我們技術之間的相互關聯，當你了解的技術越多，了解得越是深入，在你的內心，就能建立起越發清晰的技術地圖。各種知識都有一個自然、合理的位置。那么當一個老手要學習一門新技術的時候，他其實并非在探索一個全新的、未知的領域，而是有很多脈絡可尋，也很多已知可以幫助他們快速了解未知。

 

三、技巧，面對同樣的未知，面對同樣的難題，新手們一籌莫展，而老手們卻掌握著更多的技巧和手段，幫助他們試探可能性、縮小問題的范圍、迅速定位問題、不犯明顯愚蠢的錯誤、甚至能夠列舉出更具命中力的搜索關鍵詞，而這些技巧，都幫助老手在前進的道路上，更少跌倒，即使跌倒，也能更快的爬起來。

 

作為一本寫給新手的入門書籍，我們希望展現給讀者的，是一個老手如何學習新技術的過程。我們相信，這樣的一個學習過程，對于新手來說，是更具有價值的。

 

何謂快車道

 

必須老老實實的承認，我吹牛了！老手雖然會比新手學習得更快一些，但是也同樣會碰到麻煩，遇到障礙，感覺頭痛。如果沒有真正的專家的指導，我不可能如此迅速地將AJAX掌握到目前這樣的程度，要真是讓我自學三個月，然后就寫出書來的話，那真是在騙錢了。

 

老手能夠快速學習的另一個重要的訣竅是：認識很多牛人朋友J

 

如果沒有李錕與趙澤欣的專家級指導與幫助，如果沒有與李錕AJAX結對編程的體驗，如果沒有三個人在MSN上無數次的長聊，我想要在短期內建立起：

 

對于AJAX本質的理解；

對于整個AJAX以及相關技術地圖的理解；

對于AJAX編程開發所需要的很多技巧、手段的掌握；

幾乎是不可能的。

 

如果沒有（N多需要感謝的人）的（N多方面的幫助），我們這本書，也不可能以現在這樣的深度，以（N個月）內完成的速度，送到讀者的面前。

 

希望這本書，能夠對大家快速學習AJAX，有所幫助。

 

這是我原來寫的前言，自我感覺，寫得還是不錯的。可惜啊，這最后幾段，現在看來是用不上了。