原文網址：http://my2iu.blogspot.com/2011/01/gwt-isnt-good-environment-for-html5.html
譯者註：這篇並沒有寫的很好，甚至後兩段已經脫離主題，變成是在思考 JavaScript 的 coding style 與 IDE 協助開發的問題。不過頭幾段倒是給我們一些關於 GWT browser plugin 的運作原理與問題，故潦草一翻，順便當成是腦力復健 [慘笑]
去年我在 XNA 上頭寫了一個小遊戲，因為沒人玩，所以我開始把它轉換成使用 HTML5 特性的網頁遊戲。最初遊戲是用 C# 寫的，若要將它網頁化，我覺得最簡單的方法是用 Java 改寫，然後用 GWT 轉成 JavaScript。GWT 是一組 Google 提供的工具，讓你可以用 Java 寫網頁，然後它會把程式碼轉換成跨 browser 的 JavaScript 碼。
在快速看過 GWT UI frame，我發現這遠比預期的好上很多。不過很可惜的是，我發現目前 GWT 2.0 版在開發 HTML5 的遊戲方面，並沒辦法運作的很好。問題在於 development mode 中，GWT 並沒有實際將程式碼轉成 JavaScript。它會以 Java 的方式執行，然後使用一個中介層來轉換成 JavaScript ojbect 或是 browser 的 DOM，並將結果轉換回 Java 裡。起初我以為這沒啥影響，因為只有在呼叫一卡車 DOM API 或是因為某些原因要儲存一堆東西在 JavaScript object 當中，這才會是個問題。偏偏在我的 HTML5 遊戲當中就都遇到了 Orz。我在 HTML5 的 canvas 上畫了一堆東西，需要呼叫一堆 API。我也使用 JSON 來儲存遊戲資料，也就是說要用 JavaScript object 的形式存一堆東西。
結果就是，在 development mode 當中，我的遊戲執行速度慢到爆炸。這在 Chrome 上特別嚴重，因為 sandbox 的設計讓 Chrome 的 GWT development plugin 在 browser 跟 Java code 之間轉換特別慢。如果換到 Firefox 上頭就還能忍受，不過我發現我最佳化的方向有誤。看起來似乎在 development mode 才會跑的很慢（像是用 JSON 作遊戲存檔超慢讓 browser 噴了 timeout），如果實際 compile 成 JavaScript 就會很跑的很快。將 Java 碼轉換到 browser JavaScript 引擎上運作的負擔，讓開發人員很難確定遊戲實際跑起來會是啥樣子。
我明白為甚麼 GWT 會設計成這樣。JavaScript debugger API 可以讓 GWT 這類的工具將 JavaScript 碼的行數跟變數與程式設計師寫的 Java 碼作對應，但是大多數的 browser 並沒有公開這類 API。好在像 Firefox 這類的 browser 變得越來越成熟而有這類的 API，所以我期待未來有人可以重寫 GWT，可以在 development mode 時實際轉換 Java 碼變成 JavaScript，而且還是可以作 debug。
在這段期間，我會用 GWT 完成我的遊戲，然後回頭寫純 JavaScript 遊戲。我發現 JavaScript 的自由格式、非結構化性質是沒啥生產力的，但我也疑惑 Java 的 static type 會是解決這問題的最好方法嗎？當我在寫 Smalltalk 時，所有東西都可以是 dynamic type，但寫起來還是相當有效率。Smalltalk 把程式碼用很結構化的方式組織起來，所以讀程式碼或是在裡頭找東西都很容易。到目前為止，我寫的 JavaScript 程式碼風格太自由了，導致即使搭配 JDST 的 Eclipse 也無法分析的很好，只能用簡單的方法瀏覽程式碼。也許我該嘗試用比較結構的方法來寫程式，然後找看看是否有合適的編輯器可以建立出有用的架構，從而讓我讀寫 JavaScript 碼時更有效率。
