※ 引述《PsMonkey (痞子軍團團長)》之銘言： : →《Is GWT the future of web development?》 : 翻譯：http://pt2club.blogspot.com/2009/11/gwt-web.html : 原文：http://blog.balfes.net/?p=869 : →《Lost in Translation or Why GWT Isn't the Future of Web Development》 : 翻譯：http://pt2club.blogspot.com/2009/11/gwt.html : 原文：http://www.cforcoding.com/2009/10/ : lost-in-translation-or-why-gwt-isnt.html : 以下簡稱《Isn't Future》 : 讓我興起想要寫 GWT 推廣文系列的念頭 : （迷之聲：系列？ 誰知道你能撐幾篇... [毆]） : 在以傳統教學方式介紹 GWT 之前 : 先針對反對 GWT 的論點作一些思考 我個人最熟的是ZK，目前正在Survey GWT(看看可不可以把兩個合體，哈哈)。 在開戰(??)之前，先說明一下，我很喜歡GWT。 今天如果專案開發的情況是： 1. 一個B2C網站，需要同時多人上線、Content-Base導向。 2. 開發團隊熟諳Java Web 開發技術，有過Swing or SWT開發經驗。 3. 開發團隊具有資深硬底子的系統架構能力。 4. 開發時間足夠。 我會大力推薦GWT，因為國外有太多專案都以他作為backbone跟後端溝通。 而且，多數時間少直接寫Javascript確實開發效率比較好。 但是今天如果專案的情況是： 1. 企業用戶的內部MIS系統。 2. 開發團隊整體經驗較不充足。 3. 時間緊迫，專案需求分析範圍有限(通常是客戶的問題...哈哈) 4. 畫面客製化程度較低。 我會推薦ZK。 要說ZK vs GWT 上，哪幾點是我較『不喜歡』GWT的地方，那大概就是： 1. 跟Server端的合作是靠類似RPC的技術達成。 很多時候，一些事件做了就是要Server端做一堆動作，然後UI元件呈現效果。 這件事情比較起來ZK做的漂亮、簡單而且直覺。相較之下GWT只能RPC，這在 Event Listening 的programming上就比較囉唆了。常常一件多UI、Business 的操作會有好幾重的Annonymous Inner Class疊上去。 (不過ZK為了在這點上面漂亮簡單，也付出了代價。) 2. Swing Programming是唯一的選項。 雖然說ZK的ZUL(XUL Like Programming)對UI設計分析人員來講還是有點辛苦 ，但是這是受個三天教育訓練就可以克服的東西。而透過ZK的MVC架構也可以 確實解決Java code、Markup Language混雜一氣的問題。 相較之下，GWT在這方面UI設計分析人員的介入只能就個別元件的視覺化設計 去做調整，整體Usability、Color Code上面的調整還是完全要程式人員介入 才行。 (不過，這件事情大多時間都是小問題，因為台灣不管有哪些工作都是薪水最低 的那一個人做，哈哈哈~~~) 3. 人員素質要求高。 AJAX應用程式開發我覺得最可怕的地方是，當你大量使用後發現架構設計錯誤 時，你已經是千年身了，GWT幫你把Communication Channel 還有差勁的 Javascript造成的負擔減低，但是他要求UI架構的OO Design就跟Swing Programming時一樣要做好。 這對沒經歷過Desktop Application Programming的人來說有點硬。 (話說回來，我覺得用GWT用到像Google Wave一樣是特技動作，一般團隊沒那個 技術力別在實際專案中嘗試阿。) 我個人的結論是，GWT是非常重視基本、而且單純的架構設計。 他專注在如何利用Java OO的特性，減低Widget Design & UI Programming的負擔， 並以最低的侵入性，連接Client端UI與Server端 Business Logic。 在沒有Client JS衝突的情況，非常適合跟別人混用。 -- 我所信仰的科學是一種謙卑的理性，承認自身的無知與渺小才能觀察到世界在我們貧 弱的知覺上留下來的痕跡。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 123.194.174.175