GWT相關歷程
在認識GWT之前，03，04年，我也用SSH，厭倦。。。無所謂的頁面跟着頁面跳轉，無所謂的request.getAttribute.....
而後用JSTL標籤，以爲自己能做套標籤出來，當作萬金油來使用，感覺JSTL無所不能；頁面倒是寫的很少了，然而杯具纔剛剛開始，無休止的維護標籤，客戶要求越來越多，維護的難度越來越大，滾雪球式的複雜度
而後使用JSF，開始對JSF期望值很高，重型。。。坦克式的開發，頁面越來越大，一個頁面可以達到幾M，功能倒是很強，服務器和客戶端的效率都消耗在處理無休無止的HTML海洋裏面了
再往後拋開JSF吧，自己玩JS，JQuery，這玩意倒是不錯，雕蟲般的開發；自己寫的代碼往往只有自己能維護，稍微疏漏一點，自己也忘了，調試的不方便，團隊能力的參差不齊，往往是個人在裏頭，如同掉進井裏的牛。。。
再後頭FLEX吧，做了些小玩意，感覺圖像處理實在不錯，雖然AS有點詭異，也能慢慢適應吧，可是這玩意不能做大了，不然光是加載就得氣死個人。。。
後頭認識GWT，但是那會自己也幾乎不做web開發了，認爲還不錯，就是控件太少。。。
若干年後重拾起來，纔有了smartGWT，GXT等等第三方控件，恰巧朋友有點小玩意要做，就用這個試試吧
GWT的幾個特點：
1，類富客戶端：一次加載，受用無窮；當java被轉化成JS代碼，緩存在客戶端，只是第一次加載時緩慢一點，而後基本只有數據在服務端和客戶端之間傳輸，沒有龐大的HTML流；實在是手機平板等等流量消耗品的福音；問題就是在版本經常發佈時候，可能客戶端有old緩存，導致一些莫名其妙的行爲
2，面向對象：幾乎純java的開發，可以用到幾乎所有java開發面向對象的種種優勢，使人忘記了這是在做web開發；團隊中只需要一兩個JS高手來維護一些比較苛刻的問題，並不用全部都瞭解JS開發，降低了開發門檻；這裏頭需要注意的問題是，腦袋要時刻清晰哪些是服務端代碼，哪些是客戶端代碼；要時刻記得手裏的代碼是不是會變成js代碼；RPC調用的異步方式也會在開發之初造成障礙，異步方式和同步方式在處理回調時候，會覺得比較彆扭，會在時序中迷失；客戶端數據緩存的度要掌握好，刷新和不刷新，這是個問題；客戶端組件的生命週期，只有在折騰，單步調試和教訓中吸取經驗；GWT的DEV方式，也比較考驗開發機的性能和開發者的耐性；GWT不完善的log，以及組件和GWT版本間的衝突也往往讓人撞牆；
3，組件的舍取：主流的組件主要有smartGWT和GXT；這幾乎是一個門派的兩個分派；smartGWT從界面上來說技高一籌，界面比GXT專業許多；和smargGWT比起來，GXT顯得很山寨了；但是smartGWT大部分實現採用了JSNI，當出現問題和需要單步調試時候，對開發者來說是個噩夢，smartGWT收費限制和侵入服務端的設計，也讓開發者相當不爽；GXT能夠滿足大宗口味，2.2以前的LGPL還是能夠讓人接受，3.X看狀況吧，拭目以待
關於開發面上的東西，大致就這些，沒有完美的東西，只有適合自己的東西吧