ZhangJinglin

Groovy繼承了Java的所有資源，并以自身強大的語法特性使開發(fā)更高效。
Grails基于極為成熟的經典框架，并對其進行了extreme封裝（extreme封裝，引用了‘江南白衣’的術語），使用戶感覺不到底層實現，無需配置，高效開發(fā)。而且性能比RoR好很多。
下面是Grails和RoR的性能比較：
http://www.aygfsteel.com/BlueSUN/archive/2007/03/24/106002.html
事實勝于雄辯。

事實是groovy運行之前都需要預編譯，像訪問jsp之前一頓那樣，這是讓我火大之一，為啥不搞成直接運行的？每次測試還要讓我等那么一頓的時間。

第二，grails的代碼與測試時間明顯比ror慢很多，看控制臺輸出明明還是做了cache的，可還是慢，估計是因為先啟動jvm，然后預編譯groovy的結果，要知道ror宣稱的是開發(fā)速度提高，每次都頓啊頓的，讓自己的信心大減。

第三，感覺groovy的語法還是沒有ruby靈活，省略括號調用method只能省略一級，如果要嵌套調用方法，比如print dosomething param，這樣就不行了，還要老老實實地添上括號，唉，總是感覺沒那么順心。

性能比較就算了，畢竟是網絡開發(fā)，聽說瓶頸都是數據庫那里。現在還在觀望grails的發(fā)展。groovy倒是已經裝在機器上，啥時候想實驗一些類和方法，就直接groovysh來調用，比再去建個class省事。

@xyz20003

您說的不無道理，但我想補充幾句：
Groovy的預編譯有一個好處您或許沒有體會到，那就是防止程序運行到一半才報coding錯誤，這樣其實已經為您節(jié)省了很多時間了 :)
當然您也可以將Groovy文件編譯為class文件，這樣就可以省去運行前的編譯了。

至于grails的啟動比較慢，這的確是一個事實，但我們也不可忽視Grails的reload功能，也就是說，只要運行了你的程序之后，無需重啟web server，你的修改可以立刻生效，所以Grails實施的是‘先苦后甜’的策略。您如果用它開發(fā)過項目的話，就可以體會到了 :)

至于語法的靈活性，我持保守態(tài)度，過于靈活的語法使程序很難維護，這相信您也有所體會吧 :) Java的語法過于笨拙，而Ruby，Python的語法過于靈活，所以Groovy做個折衷，以Java的語法為基礎，將Ruby和Python中真正有用的特性添加進來，所以可以這么說，Groovy是動態(tài)Java，但由于‘Java’這個商標問題，不能叫Dynamic Java.

@山風小子
呵呵~感覺光動態(tài)還不夠，我們需要的使用上得到真正的便利，而不是為了使用某某技術這種幌子。

預編譯的問題，從jsp開始我一直是非常反感的，這么說吧，調試錯誤從某種方面來說，更依賴于開發(fā)人員的經驗。而幫助開發(fā)人員調試語法錯誤的應該是ide工具，而不是簡陋的編譯器。

至于動態(tài)reload，這個并不是我希望討論的范圍內，畢竟tomcat等servlet容器都支持動態(tài)reload，但你修改了關鍵配置文件還是需要重新啟動的。即便是ror，你改了數據庫配置，也是要重新啟動的。

不過既然說到grails的reload，我也加上兩句，還是預編譯的問題，你修改了groovy或者gsp，再訪問頁面，總是能感到一段休克時間，這就是預編譯的占用時間了，而像freemarker這種模板就不會出現這種問題，再說了freemarker也都支持cache，而開發(fā)階段又可以把cache關閉，開發(fā)階段不影響調試，發(fā)布階段不影響效率。這多好？現在想想，要是java能設置個開關，能控制是否使用預編譯就好了。

反正感覺groovy on rails還是太不成熟了。再觀望一端看看。

@xyz20003

groovy的預編譯會將.groovy文件編譯為優(yōu)化過的.class，在編譯的時候會消耗點時間，但以后運行起來就快很多了，所以也不能完全否定了，您說對吧 :)

至于reload，我想您不會頻繁的改數據庫配置吧，一旦定了用什么數據庫，username和password，url，driver也就定下來了，而修改這些配置的幾率很小，因此reload這個功能在開發(fā)調試中能很好的發(fā)揮作用的 :)

groovy1.1會對compiler的性能進行調優(yōu)，到時您或許就不會感覺到預編譯了 :)

Grails將在Groovy完全支持Annotation(Groovy1.1將支持Annotation)之后，集成Guice，提高整體性能，包括啟動速度，到時您不妨再試試，體驗一下Grails的樂趣 :)

其實，真正的探討ROR和Grails之間的問題，可能像探討JavaEE和.NET之間問題一樣。
現在的問題是，ROR已經發(fā)布到了1.2，可是Grails只有0.4，好像馬上要發(fā)布0.5了。從技術成熟度上說，恐怕要差和大一塊，如果我們能夠理解ROR的開發(fā)理念，而關注Grails的發(fā)展，等到Grails成熟后，我想可就是另一種結果了。
更為關鍵的問題是，Grails建立在Java基礎上，這是一個ROR無可比擬的優(yōu)勢，試想如果Java不是建立在更好的C++上，C++不是建立在C上，今天的C++或者Java也許只是小語種，呵呵。
我學習ROR的時候，看的就是Agile web development with rails，（好像地球人都看這本），我驚奇Rails的開發(fā)效率，我迷惑Ruby的語法。我發(fā)現，我想要學好Rails必須深入學習Ruby，一個我從來不知道的語言。所以學習進度也是很慢。
在學習Grails的時候，看的時InfoQ 的grails getting started，只用了很短的時間就初步掌握了。而且用了1天半就完成了一個資源下載系統(tǒng)，而且可以評論，雖然很初級，但卻是工作在完全的Java環(huán)境下，總之，就是快樂。
用ROR的確快樂，但有時卻很痛苦（不熟悉Ruby），Grails卻給我持續(xù)的快感。
我想寫這個系列，主要是想用ROR的思想來對比了解Grails，畢竟ROR已經很成熟了，Grails的資料都很少。
初步設想可能包括（二）基本開發(fā)過程的比較（三）控制器的比較（四）視圖的比較（五）域模型的比較（這個是重點）（六）Ajax的比較（七）Ruby 與 Groovy的比較
不知道有沒有精力完成，工作太多......

@zhangjinglin
非常期待您接下來的一系列文章 :)