GWT：序章—用？ 不用？ Java 的錯？

我注意到 GWT 是今年年初的事情
如果再不碰 AJAX 的技術，就準備骨灰罈把自己裝進去吧！[炸]

同時進了一家小工作室，於是跌跌撞撞
把開發環境從 PHP（CodeIgniter）+jQuery
先用 GWT 換掉 jQuery 以及畫面輸出，完成了兩個案子
最後是用純 GWT 完成了一個案子...　然後離職了 lol

雖然都沒用什麼高深的技術、案子也都不大
但也勉強能算是實做過
因此，我一直對 GWT 在台灣（或華文世界？）討論 & 資源很少
甚至連掀起一陣熱潮都沒有（例如像 Ruby，至少出了一堆中文書）
總覺得哪裡怪怪的

如果以 ptt.cc 當樣區
是說，除了 jQuery 之外，其他 AJAX/JavaScript的技術
Ext、YUI、dojo、DWR...　也沒看到什麼討論
Java 版上頭也幾乎是基礎的 J2SE 問題涵蓋了 80% 以上的討論
JSP 的問題也幾乎都「只是」JSP 的問題
zk, JSF 還有一堆東西，幾乎都不見蹤影

這會不會是 ptt.cc 的一種趨勢，除了西瓜效應之外
也停滯不前，或說對新技術的不在意 or 不敏感？
亦或是高手們覺得孤掌難鳴曲高和寡，問/講了也是白問/講？

ㄜ... 扯遠了...

最近沒有工作，加上這兩篇的 combo 連擊 XD

→《Is GWT the future of web development?》
翻譯：《GWT 是網頁開發的未來嗎？》

→《Lost in Translation or Why GWT Isn't the Future of Web Development》
翻譯：《轉換不完全—為甚麼 GWT 不會是網頁開發的未來呢？》
以下簡稱《Isn't Future》

讓我興起想要寫 GWT 推廣文系列的念頭
（迷之聲：系列？ 誰知道你能撐幾篇... [毆]）

在以傳統教學方式介紹 GWT 之前
先針對反對 GWT 的論點作一些思考
畢竟，知道敵人（？）怎麼想，是很重要的....
（雖然我覺得《Isn't Future》寫的實在... Lost in Words？ lol）

OK! Let's start...


＊　　　＊　　　＊


〔Java 是快過時的東西嗎？〕
GWT 是以 Java 語法作為開發語言
我們在寫 GWT 時，絕大多數是在寫 Java
只有在需要直接操作 JavaScript 時
才需要藉由 JSNI 來寫一些 JavaScript

《Isn't Future》強調 script 才是未來的主流
type safety 沒有也沒差
dynamic typing 可以少掉很多麻煩
JavaScript、Ruby、PHP 等等語言也寫出很多軟體、也沒有炸掉
在開發階段可以少些時間在等待

（這篇文章看到後來，比較像是在詰譙 Java　Orz）

我的程度無法討論 or 比較這些東西誰優誰劣
或著說，我的程度只能寫 Java
因為 Eclipse 這種等級的 IDE 可以幫我處理很多雜事
code assist 也好、open declaration 也好（撇開 OO 的部份）
至少我年初用 PDT 跟很久之前用 RDT
都沒有堪用有效的工具（據說是很難有？）

當然，script 語言如果封裝的好、能夠產生良好的 API doc
那麼這些東西或許就沒差？ 充其量就是腦袋要記得多一些東西？

但是，如果回歸商人的角度去想
為甚麼 Google 在選擇 GWT、Android 的開發語言
是用 Java 而不是用 Python？（即使是 App Engine 後來也？）
或是，理論上更多人會用的 C/C++？

話說回頭，「潮流」這回事情實在令人費解
很久以前的 Basic 系列都不用定義變數型態
後來 VB 可以不用定義、也可以強制定義、到後來就都要了
現在有人說，script 才是未來的主流
這中間的思維轉折，到底是怎麼一回事呢？

〔為甚麼我要學 JavaScript？〕
假設你會機械語言 [笑]
你會用機械語言當作軟體開發的語言嗎？

《Isn't Future》的答案是：

你應該要用機械語言；而不是用高階語言撰寫，再透過工具轉換成機械語言

中心思想是 Joel 的文章《The Law of Leaky Abstractions》
試圖論述一件事情：Java 不可能完整地轉成 JavaScript
這又可以拆成兩個部份來討論
一個是實作的能力、一個是語言本身的能力

關於「實做的能力」，《Isn't Future》沒有明確地說些什麼
我想，如果 Google Wave （GMail？）是用 GWT 做出來
這部份大概也沒什麼好質疑的
理論上 JavaScript 能作的事情，GWT 都（可以）有對應的功能
（還有 JSNI 這個大絕招嘛... [炸]）

更進一步說，如果你用 GWT（剛好又會 Java 跟 Swing 基本概念 :P）
你將可以擺脫傳統寫網頁程式的困擾：要會一堆東西
(X)HTML、JavaScript、DOM、AJAX...
最後還來個該死的瀏覽器差異
也不用為了要處理上頭那一堆東西，再去學一個像 jQuery 的東西
（jQuery 的程式碼看起來像另一種語言 XD）
你就是在寫 Java，只不過出來的畫面是在 browser 上

當然，我認同文中說「好的程式設計師應該能很快的學會新東西」
但是，開發階段最痛苦的是那些藏在細節中的妖魔鬼怪
這跟學習能力好壞與否無關
唯有對該技術的深入瞭解才能稍微減輕 or 減少這種痛苦
我這種笨蛋，沒辦法掌握太多（各自獨立）的技術

《Isn't Future》大多數是在闡述很多 JavaScript 的語言特性
在 Java 當中是沒有的，而且有些根本作不出來。

問題是：為甚麼？ （盧廣仲：Rock!! [炸]）

如果功能都做得到，那麼語言特性真的有那麼重要嗎？
我們真的需要在 object 上頭隨意加掛 attribute 跟 method 嗎？
我們真的需要寫 first class function 嗎？

如果不是沒有也無損功能實做（最多囉唆點 :P）
那麼 Java 不能做出 JavaScript 的語言特性，又如何？
現在大多數的語言也沒有 goto 或是 jump 啊？

嗯... 還好我不會機械語言　:)

〔其他〕 上頭沒涵蓋的零散論點，集合在這裡
→GWT 內建 widget 醜到爆
如果你在意自己長得不夠美
只要體質好、本錢夠，整形技術可以讓你煥然一新

只要在 gwt.xml 拿掉設定，widget 預設的 CSS 就會移除
還原成 browser 最原始會呈現的樣子
要自己加掛 CSS name 當然沒有問題，剩下來是美術人員煩惱的事情

反過來說，我還沒看過什麼正式的網站
不去修改元件的外觀（Google 自己的網站不算 XD）

愛美不是罪，但是本末倒置是一種錯誤。

→compile 速度爆慢
GWT compile 成 JavaScript 的時候，真的是打混摸魚的好時光
但是在「全部使用 GWT」的情況下
開發階段根本不需要 compile

client 的變動，在 hosted browser reload 之後
跟改 PHP/JSP 然後重新 reload 的速度差不多
（重點是 GWT 只有「一頁」，PHP/JSP 有好多頁）

server 端的變動，需要 restart server
這跟改 web.xml、servlet 的狀況是一樣的
（GWT RPC，server 端是一個 servlet）
跟 GWT 的 compiler 沒啥關係

只有在 server 端不是使用 GWT RPC
因為 cross-domain 的關係，必須先 compile 成 JavaScript
放到實際 web server 上頭才能測試
（當時有弄出用 form submit 來暫時代替的奧步，可省下一些時間 XD，不知道有沒有其他方法？）
GWT 2.0 會對此做出改進
但是對純 Java（GWT）開發環境而言，其實就還好...

〔結尾 & 開始〕
《Isn't Future》並沒有說服我
還是選擇站在 GWT 這邊的　 \囧/

接下來，我會開始唬爛 GWT
盡量有系統地瞎掰出一些教學文章

如有謬誤之處，還請高手前輩們指點一二以正方家
如有疑問 or 建議，也歡迎版上討論 or 來信指教


就先這樣啦～ 囧>

轉換不完全—為甚麼 GWT 不會是網頁開發的未來呢？

原文網址：http://www.cforcoding.com/2009/10/lost-in-translation-or-why-gwt-isnt.html

最近我看到「GWT 是網頁開發的未來嗎？」這篇文章，裡頭假設 GWT（Google Web Toolkit）會是未來的趨勢，因為它引入了 type safety、會吸引既有的 Java 程式設計師，也提供一些 widget。

Google 最近有很多 widget 都是用 GWT，尤其是 Google Wave。對抗 Google 或是 Lars Rasmussen 這檔子事情，我當然會猶豫啦，但是我卻是抱持這種立場 \囧/。

Type Safety 跟 Static Typing
在 90 年代，type safety 跟 static typeing 的主宰地位幾乎沒被挑戰過，首先是 C 然後是 C++ 跟 Java（我知道還有這之前還有 Pascal、Algol-68 以及一卡車的語言）。Perl 是留鬍子、自信的系統管理者的名片。

相較於不夠力的硬體（當然是以今天的標準），越來越複雜的軟體以及效能問題，促使這種潮流。變數不用定義或是可變型態的想法，就像世界末日。

在 JavaScript、PHP、Python、Perl、Ruby 以及過去十年的其他語言（還有一些遠早於這些的語言）已經清楚地證明了，鬆散、動態的型態並不是世界末日。

吸引 Java 程式設計師
這裡論上聽起來不賴，但是我提出另一個觀點：如果你寫德語教科書的時候，你會用德文寫？還是先用英文寫然後再用個工具轉成德文？

任何人研究或是懂得第二語言都知道「有些事就是不能翻譯」。程式語言也一樣。JavaScript 有一堆內容是 Java 沒有的：first class function、closure、extendsion methods、意思差很多的「this」、anonymous object、dynamic typing 等等。

當你在寫「cross-compiler」會遇到的問題：

1. 最終產出的弱點與侷限性，會包含兩個語言的弱點（用數學的講法就是「A 聯集 B」，A、B 分別是兩種語言）
2. 最終產出的優點，會是兩個語言共同的優點（「A 交集 B」）
3. 慣用語不同
4. Abstractions are leaky（中文：抽象滲漏法則），Jeff Atwood 稱之為「所有的 Abstraction 都是失敗的 Abstraction」

這也是 ORM（例如 Hibernate）的根本性問題：Object-relational impedance mismatch。常常你花了半天的時間去調整正確 property、annotation、XML、VM 參數的組合，只是為了產生一個 query，但是兩行 SQL 就可以解決了。

另一個 GWT 的問題是：它誤導那些只會寫 Java 的程式設計師，讓他們以為可以不用學 JavaScript。

我的立場可以總結如下：GWT 把 JavaScript 當成一個需要解決的 Bug。

Widget 與成熟度
我曾經用 GWT 寫程式。widget 的選擇性實在讓人感到悲傷。GWT 標準的 widget 看起來十分嚇人、甚至可以說是糟糕透了。是有一些第三方的選擇，但是 ExtGWT 是一個非糟糕的 library、SmartGWT 看起來是一個比較好的選擇（實際上是一個社群的成果，而不是某個根本不懂 Java 泛型的人做的 GPL/commercial 授權的大雜燴）。除此之外，也沒有太多選擇。

JavaScript 有許多選擇：YUI、ExtJS（跟 ExtGWT 完全沒關係）、Dojo、jQuery UI、SmartClient 等等。不只選擇更多、而且也更成熟。

最重要的是開發速度
GWT 需要花上幾分鐘在組建（build）跟佈署（deploy）。因為某些因素，你無法「hot-deploy」class 跟 JSP。對於 PHP 跟 JavaScript 的開發者而言，組建跟部屬通常只是替換儲存的檔案，然後要 browser 重新 reload。

GWT 的 compile 過程是很粗暴的，所以在 1.6+ 跟 2.0 版對這部份做了重大的改進。draft compile、平行處理 compile 過程、optimized vs unoptimized Javascript、選擇輸出的 browser，這些在開發階段會有些幫助，但是每個部份卻又會增加 compile 的時間。

雖然只有在更改 service interface 才需要 compile 。純粹 client 端的改變可以在 hosted browser（GWT 2.0+ 可以在實際 browser）重新 reload 之後測試。技術上來說，在不改變 interface 的情況下，Server 端的改變應該不需要使 GWT 重新 compile，但是實做上卻可能是個問題（無論是用 Ant 或是 Maven）

為甚麼很長的 compile 時間會是個問題？

或是看看〈The Joel Test: 12 Steps to Better Code〉（中文：〈約耳測試：邁向高品質的12個步驟〉）的說法：

我們都知道知識工作者進入「狀況」(flow，也被稱作in the zone)時工作效果最佳，這時候他們會完全與環境脫離，全心專注在工作上。他們忘記時間並透過絕對專注產出極佳成果。他們所有豐富的產出也都是在這個時候完成的。作家，程式人員，科學家，甚至籃球球員都會告訴你進入「狀況」的情形。

問題是要進入「狀況」不是那麼容易。如果你有試著計時，平均大概要15分鐘才能開始全速工作。有時如果你累了或是那一天已經有很多創造性的成果，會根本無法進入「狀況」，然後看看網頁玩玩俄羅斯方塊打混過完一天。

還有一個問題就是很容易脫離「狀況」。噪音、電話、同事的中斷(特別是這一點)都會讓你脫離「狀況」。假設有個同事問了一個問題讓你中斷了1分鐘，實際上卻會讓你完全脫離「狀況」，得再等半個小時才能回復生產力，結果你的整體產能都出問題了。如果你身在一個喧鬧的BULLPEN環境中(像那些一窩蜂(caffeinated)網路公司最愛營造的典型)，行銷部門在程式人員旁對著電話大喊，你的產能就像一直被中斷的知識工作者一樣顛簸，永遠無法進入「狀況」。

即使是一分鐘的 compile 也會讓你脫離「狀況」。即使像 Jeff Atwood 這種毫無道理卻死命堅持厭惡 PHP 的人，也有如看到曙光、自命為「徹底的 Scripter」。

不是每個應用程式都像 GMail
我認為 Web 應用程式某些部份跟 GMail 一樣。它的特色是（幾乎）只有一頁、常常模仿一般應用程式。傳統的網頁需要使用越來越多的 JavaScript，但是 HTML 頁面間仍然需要倚賴標準的 HTTP 傳輸。

GWT 是一個針對 Web 應用程式的技術。載入的時間很久（因為 JavaScript 動輒超過 1MB），但是這沒啥關係，因為在整個過程當中，你只載入一個頁面一次而已。在載入時間這點，傳統網頁是更常見的，對 GWT 而言不是問題。

即使你把討論範圍縮小至 Web 應用程式，在我的經驗當中，就算最大的 Web 應用程式還是可以用 JavaScript library 來管理。

現在的程式碼的規模都很巨大，我也許可以瞭解 GWT—至少算是 type check—的價值。不過，我寧願用 JavaScript 處理 dynamic loading 而不是用 GWT 2.0+ code splitting。相較之下，YUI 3 dymanic loading 有精練 JavaScript 語法以及 first class function。

Layers 與 Value Objects
Java 程式設計師喜歡 layer 不是什麼秘密。你才弄了一個 Presentation Layer、Controller Layer、Repository Layer 接著有人又建議你需要有 Database Abstraction Layer、Service Layer、Web Service Layer 以及 Messageing Layer。

當然，你在這些 layer 之間傳遞資料時，無法使用某些 value object，所以你便寫了一堆照本宣科的東西：

public class TranslationUtils {
 public static CustomerVO translate(Customer customer) {
  CustomerVO ret = new CustomerVO();
  ret.setName(customer.getName());
  ret.setDateOfBirth(customer.getDateOfBirth());
  //...
  return ret;
 }
}

或是你使用一些 reflection（甚至是 XML）的 property 複製機制。顯然的，類似的事情被認為是一個好的作法（至少是普遍的作法）。理所當然會出現的問題是， interface 會用到的 class 是有相依關係的。

更多的 Java 程式設計師有一個偏好，擔心從來沒有發生事情：抽換 layer 或是分別在不同的地方實做。

我堅信這些程式碼是害蟲。這種東西越少越好。因此，我認為透過可以依需要動態變更的方式傳遞 object，比寫一堆死板複製 property 來的好；因為單純跟單調的事情是容易出錯的，偏偏自動化工具沒辦法（至少無法完全）處理這些細微差異。

在 JavaScript，你可以直接對 class（所有 instance 或是你覺得適合的 instance）掛上 property 跟 method。Java 沒有支援這個功能，就讓 GWT 出現一個問題：你怎麼用你的 presentation object？像 ExtGWT 的 library 就乾脆把所有東西（包含 JSON）經過一些轉換之後都變成 Map（那還有 type safety 嗎？）

關於語言特性
管理者跟員工常常太重視你（應徵程式設計師）使用的語言及 framework。好的程式設計師可以馬上學會新的東西，程式語言也是同樣的道理。基礎的控制結構在一般的操作是相同的（至少在兩個語法與功能相近的語言上）。

語言特性就比較難。很多寫 Java、C++ 或 C# 的人，當他們用像 PHP 之類的語言時，會試著重新作一些在他們「母語」裡頭的行為。這幾乎總是會出錯。

OOP 是最常誤用的語言特性。PHP 不是 OO（比較好的描述方法是「object capable」）；另一個是討厭全域變數。在 PHP 裡頭沒有多少東西是 global，而HTTP request 大多數時候是純粹是 procedural。就像 Joel 在〈How Microsoft Lost the API War〉（中文：〈微軟如何輸掉 API 戰爭〉）所說：

我們很多人都認為1990年代最大的戰爭就是程序化程式設計與物件導向程式設計間的戰爭，而且我們認為物件導向程式設計能讓程式師的生產力大幅提升，我當時也是其中之一，而有些人到現在也還是這麼認為。不過結果我們錯了，物件導向程式師設計是很方便的好東西，不過並不能像它承諾地大幅提升生產力。真正讓程式師大幅提升生產力的，其實是那些會替你自動管理記憶體的程式語言。

重點是 Java 跟 JavaScript 分別有非常不同的特性。設計良好的 JavaScript 程式跟設計良好的 Java 程式所作的事情是相當不一樣的，所以在把 Java 轉換到 JavaScript 時，會失去一些東西，因為語言特性是沒辦法自動轉換的。

結論
Script 會是未來的趨勢。一堆的組建跟部屬步驟，無論是以行業趨勢或是最佳產能的角度，都已經是過時了。這樣的趨勢已經發展許多年了。

一次性 compile 的語言（像 C/C++，Java 跟 C# 是 compile 成一個中介的格式所以不算）佔了軟體開發的大多數，包含我們現在使用的網頁 browser、OS、Database、Web Server、VM 等等。現在他們被「semi-compile」管理平台（主要是 Java 跟 .Net）取代。這些語言會有適合它們的領域，但是會被以 script 為基礎的語言所取代。

GWT 用電報這方法，試圖找出最好的方法來實做大規模、高效率的全球訊息交換系統，但是其他人已經改用 Email 了。

========
譯註：大多數電腦領域的名詞都不翻譯，build 跟 deploy 則是為了中文語意而亂翻 XD。原文引用「Joel on Software」的部份，中文翻譯是直接引用中文版的對應段落。

說實在的... 這篇看起來筆調很輕鬆活潑
但是我寧願翻譯學術論文... 實在翻譯的好痛苦阿阿阿阿 <囧>

GWT 是網頁開發的未來嗎？

原文網址：http://blog.balfes.net/?p=869

有非常多的人看過、玩過、或聽過 GMail 以及其他像 Google Wave 的應用程式。是否曾經納悶這些應用程式是怎麼做出來的？那你應該去看一下 Google Web Toolkit（GWT）。我從上個禮拜開始瘋狂地寫 GWT，我必須承認它非常有趣，應該會有很多支持它的理由。當你在開發 web 應用程式時，可以用到 Eclipse 這個 IDE 的所有好處，而且你寫的語言卻是 Java，你就會認同我了。最棒的是，你可以重頭到尾都在寫 Java，但是最後 compile 的結果卻是一個以 JavaScript 做出來美妙 web 2.0 應用程式。GWT 的 compiler 支援絕大多數 Java 語言的內容。

你可以看一下 GWT API Reference 導覽，實際感受一下 UI 可以好到什麼樣子。基礎的 widget library 也可以馬上讓你用用看；如果基礎的 widget 沒辦法滿足你，你也自己弄一些 custom widget。我覺得做的實在很棒的是 i18n 的技術（雖然我並沒有處理過很多 i18n 的東西）。講到 debug 那更是不得了，你現在可以輕鬆在 Eclipse 用正統的 debugger 來開發、debug 你的 JavaScript 應用程式。GWT Compiler 只產生一些 JavaScript 跟 HTML 檔，與其他公開的 resource（例如 CSS、圖檔）分開。在 deploy 時，你需要做的就是把這些東西放到你的 web server 上。

為甚麼 GWT 可以這麼酷咧？我想關鍵點在於它會吸引 Java 開發者，而且在轉成 JavaScript 的時候還會幫你作最佳化。你會得到一堆混淆過後的 JavaScript 檔案，且已經針對主要的 browser 作最佳化—這些常常是你得先知道怎麼作，然後常常還得自己手工處理的煩人事。你還可以把你做的東西掛進 GWT SDK 當中。為自己的產品及開發人員，建立自己的 service、UI 元件。還有還有，GWT 是 open source 的，你可以在 Apache 2.0 license 的規範下使用 & 修改它。

我相信我們會聽到更多 GWT 的東東，我也希望聽到關於這個 Web 2.0 開發方式的不同意見。

========
原文下面還有一堆 comment，就懶得翻譯了 XD
作者後來又 po 了一篇補刀的文章，也可以順便看看