2009年11月18日 星期三

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 來信指教


就先這樣啦~ 囧>

沒有留言:

張貼留言