[翻譯] GWT 的優點與缺點

看板Translate-CS作者 (痞子軍團團長)時間11年前 (2013/04/11 04:06), 編輯推噓2(201)
留言3則, 3人參與, 最新討論串1/1
原文網址:http://www.gmarwaha.com/blog/2011/05/09/gwt-pros-and-cons/ 譯文網址:http://blog.dontcareabout.us/2013/04/gwt.html 註:原文寫於 2011.05.09 BBS 版以 markdown 語法撰寫 ______________________________________________________________________ 我愛 JavaScript。[jQuery] 跟 [MooTools] 出來之後, 讓我對 JavaScript 的愛又增加了好多倍。 如果要我對所有我開發的 web application 做出選擇, 我會從上面兩個 framework 當中選一個。 但是在這一行,我不得不一次又一次地屈服於客戶的壓力、 用他們選擇的技術來作業,無論他們的選擇對或錯 (付錢就是老大啊...... Orz)。 有一個客戶讓我接觸到 [GWT] 的世界。 [jQuery]: http://jquery.com/ [MooTools]: http://mootools.net/ [GWT]: http://code.google.com/webtoolkit/ 幾年前當 GWT 剛發佈的時候,我曾經試了一下。 我不怎麼喜歡,所以我甩了 GWT 就再也沒回頭看過它一眼。 但是在過去六個月用 GWT 作業之後,我對這個 framework 有稍微不同的印象。 我仍然不會說 GWT 是什麼拯救世界的神兵利器, 但至少它沒有我想像的那麼糟糕。 我把對這個 project 的觀察結果紀錄下來,好的壞的都有, 對之後要導入 GWT 的開發人員來說可能有點用處。 優點 ==== 1. 如果你對 Swing 或 AWT 是有經驗的老手, 那不用考慮、用 GWT 就對了。 在這個背景條件下學習曲線會是最小的。 1. 即使你在 Java GUI 方面沒啥開發經驗, 有多年對付 server side 的 Java 經驗, 也能在開發 GWT application 時派上用場。 1. 你可以把工作都交給 client、減少騷擾 server, 以建立反應迅速的 web application。 1. 雖然有眾多的 JavaScript library、大多數都是稱職好用的, 但許多傳統的開發人員無法理解它們的真正威力。 請記得,像 JavaScript 這種強大的語言是一把雙面刃。 如果你不知道怎麼使用它,你甚至不知道怎麼清理你製造出來的混亂場面。 1. 你可以把一個傳統的 web application 漸進地轉移程 GWT application, 這兩個不是互斥關係。 你可以用 JSNI 這種聰明的技巧去載入你已有的 JavaScript function。 不過趁早把它們轉移到 GWT 是比較好的作法。 1. GWT 的 IDE 支援度好到不能再好了。 Java IDE 已經在過去十年中成熟了, 成為世界上最好的 IDE 之一,GWT 可以直接獲得這些優勢。 1. 看看這精美的 debug 整合工具,你絕對會想擁有一套的。 成熟的 Java IDE 提供的 debug 支援度可以讓任何人轉而選擇 GWT。 1. IDE 內建的 Java code 重構功能可以直接派上用場, 讓你在任何時候都能維持簡單的設計。 要在 JavaScript 作這件事會讓你心臟衰弱。 1. IDE 的語法 highlight、錯誤檢查、程式碼自動完成快速見...... 完全就是樂勝啊。 1. Google 正在積極發展 GWT(譯註:......)。 我們知道這個 project 不會隨便死掉(譯註:......)。 直到現在,他們對這個 project 做了很多跟這個領域的未來有關的承諾。 (譯註:............) 1. GWT 的社群也是一大利多。 每天在 StackOverflow、討論區、wiki 以及個人 blog 都有相關討論。 用對關鍵字,一個簡單的搜尋就可以導引你到正確的方向。 1. GWT 是一個深思熟慮的 API,沒有東西是倉促拼湊出來的。 這有助於開發人員快速理解抽象化的部份,使用起來也很直覺。 1. server 與 client 之間的資料傳輸, 你可以使用 GWT 內建的通訊協定, 完全不需要知道資料是怎麼包裝怎麼發送。 如果你想要有更多掌控權,你一定可以改用 XML、JSON 或是其他可行的格式。 即使是用 JSON,你不需要用不直覺的 Java-JSON library。 透過 JSNI 直接用 JavaScript 來「eval」JSON,這招夠帥了吧... \囧/ 1. 能使用標準的 Java static code 分析器, 像 FindBugs、CheckStyle、PMD 等等 來監控程式碼與設計的品質也是一項優勢。 在成員經驗值參差不齊的團隊中,這是很重要的。 1. 你可以使用 JUnit 或 Test NG 來作 unit test, 用 JMock 或其他 mock library 來 mock 相依性。 如果你已經上手了,那麼依循 TDD 就很簡單易懂。 雖然 JavaScript 有 unit test framework, 像是 jsunit 跟 qunit... 得了吧... 有多少人已經再用或是想要用它們? 1. GWT compiler 產生跨 browser 的 JavaScript 程式碼。 現在講這個東西的行銷人員可能會被打。 它已經變成一個基本需求,而不是奢侈品。 1. GWT compiler 會對產生的程式碼作最佳化、 移除沒用的程式、甚至混淆 JavaScript 程式碼...... 這一切只需要一個動作就完成。 1. 雖然 compile 的時間真天殺的久,不過在開發過程中不會遇到。 有一個特別的 hosted mode 透過 browser plugin 直接用 Java bytecode 產生輸出結果。 這也是你可以用 Java debugger 來抓 client side bug 的主要原因。 1. 藉由一些 project(像是 Smart GWT、Ext GWT 等等) 可以取得一些第三方的豐富元件 (譯註:原文是 rich third-party control)。 它們設計的不錯、容易使用、而且有佈景主題。 所以,如果既有元件無法符合你的需求, 你應該在這些 project 當中找找看。 有極為渺茫的機會可以在這些元件中找到解決的方法。 即使它們沒辦法解決,你還是可以自己作一個。 1. GWT 強調「能保持狀態(stateful)的 client 與不保持狀態(stateless)的 server」這個概念。 這導致有很多使用者同時存在的 server 負載量盡可能地減少, 而只有一個使用者在運作的 client 端負荷加重。 1. i18n 跟 l10n 用 GWT 來作是相當簡單的。 In fact locale based compilation is taken care by the GWT compiler itself. (譯註:翻譯不能... Orz) 這很難說是一個只能在 client 端使用的 framework。 1. GWT 內建支援 browser 的「上一頁」功能,即使在 AJAX 之下也可以。 如果你是 AJAX 開發人員,我幾乎可以聽到你鬆了一口氣的聲音。 這不用付出什麼代價。 缺點 ==== 1. GWT 是一個快速發展的 project,所以有好多版本散落各處。 許多函數、interface 跟 event 已經捨棄不用了, 當你還有其他工作要作時,還要跟上腳步就不會太愉快。 1. 一開始有很多 GWT 的書,最近就沒那麼多了。 舉例來說,我找不太到 GWT 2.0 的書,結果只能看 Google 文件。 我同意 Google 文件良好又完整,但是比不上一本好書。 1. 寫 GWT 不有趣。 畢竟 GWT 裡頭都是 Java,而寫 Java 不是很有趣。 如果全部的 layout 跟自訂的控制方式都要用 Java 寫, 你可以很輕鬆地讓一個程式老手哭哭。 隨著 GWT 2.0 導入 UiBinder,這個問題解決了,但是你得學新語法。 1. Java 轉成 JavaScript 的速度相當地慢, 這是選擇 GWT 的一個明顯缺點。 1. 我個人偏好用 HTML 撰寫結構,然後用 CSS 上樣式。 用 HTML 的作法是乾淨且直接的,我多年來的經驗就是這樣做的。 但在 GWT,我被迫用一種特有的方法來作相同的事情。 對我而言 GWT 沒有解決樣式與校正不一致的狀況, 這些加在一起就是個大問題。 因此,我超痛恨在 GWT 裡頭寫 layout。 不過從 2.0 開始,有 UiBinder 跟 HTMLLayout (譯註:沒有 HTMLLayout 這個 widget,不確定原作者要說啥?), 我覺得回到了自己熟悉的領域。 1. 要進入 GWT 需要一些 serious commitment level, 因為 client 技術的一個改變就可能需要完全重寫你的 application, 這跟其他 client side 的 framework 是完全不同的。 1. 沒有一個用 GWT 開發 application 的明確方法。 到底是一個 application 只用一個 module? 還是一個 page 就用一個 module?還是介於這兩者之間? 這些設計模式發展遲緩,所以通常人們傾向在同一個 module 裡頭開發, 直到 module 大到不能階受才重構成幾個 module, 但為時已晚,重構不會像之前那麼簡單。 1. 把呈現的方式跟程式碼混在一起,這不科學, 雖然傳統桌機的 GUI application 是這樣作。 但是近來,即使桌機的 application framework (像是 Flex、Silverlight)也採用 XML 為基礎的描述方法, 讓呈現方式從邏輯中分離出來。 我覺得 GWT 1.x 版有這個缺點, 在 2.0 版導入 UiBinder 之後,我想這個缺點可以劃掉了, 儘管有另一個痛苦的 XML 語言得學。 1. 你常常要寫 3~5 倍多的程式碼, 而其他像 jQuery 的 client side library 很簡單就可以做完。 1. 你應該要記得,GWT 對 HTML 的抽象化還不夠完整。 你仍然得了解 application 產生的 DOM 結構,如此一來才能掛上樣式。 而且 GWT 會讓結構看起來更可怕。 1. GWT 的優勢僅對 Java 開發人員有效。 對於用 .net、PHP 的人啥都沒有。 1. 如果你已經感受過 JavaScript 的威力、 並且知道正確使用下所帶來的優勢, 那麼像 Java 這種笨拙的語言會讓你好像斷手斷腳一樣。 -- 錢鍾書: 說出來的話 http://www.psmonkey.org 比不上不說出來的話 Java 版 cookcomic 版 只影射著說不出來的話 and more...... -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.25.24.228 ※ 編輯: PsMonkey 來自: 114.25.24.228 (04/11 04:07)

04/11 13:12, , 1F
編號為什麼都是1啊?
04/11 13:12, 1F

04/11 19:36, , 2F
markdown 語法阿... 這樣寫起來比較快 XD
04/11 19:36, 2F

04/12 00:24, , 3F
校正->對齊 ?
04/12 00:24, 3F
文章代碼(AID): #1HPSPKTy (Translate-CS)
文章代碼(AID): #1HPSPKTy (Translate-CS)