Java架構的老大們們談架構…沒有一人能忽視Ruby on Rails…

Jave Web Framework Sweet Spots
Java Web 架構的“甜點”

這是一篇很有趣的文檔，所以摘要一下，其實類似閱讀筆記，好像是3/25發布的：

不知怎麼翻譯Sweet Spots，難道翻譯為甜處、甜頭、蜜點、蜜穴？

這時基於對以下人的採訪：
JSF  Jacob Hookom
RIFE  Geert Bevin
Seam  Gavin King
Spring MVC Rob Harrop
Spring Web Flow Rob Harrop and Keith Donald
Stripes  Tim Fennell
Struts Action 1 Don Brown
Tapestry Howard Lewis Ship
Trails  Chris Nelson
WebWork  Patrick Lightbody
Wicket  Eelco Hillenius

原文在此：http://www.virtuas.com/articles/webframework-sweetspots.html

JSF(Jacob Hookom)
1、你認為你的framework的“甜點”在哪裡？他最適合哪種類型的項目？
當你希望瀏覽器程式像傳統型程式一樣工作的時候，你可以遵循標準並獲得大量第三方支援。它致力於降低複雜度。它允許你不與view和特定的action、參數傳遞、狀態傳遞、渲染打交道就可以進行高品質的開發，不管是否使用工具。
2、它不適合於什麼樣的情境？在這些情境你推薦什麼fremework？它是哪個？
它不適合大規模的、唯讀（其實指讀為主）的網站。在這種情況推薦Struts，因為知識庫豐富（應該指文檔和使用者群）。
3、在下面提到的framework中，你實驗過他們嗎？如果實驗過，你比較喜歡哪個？你不喜歡哪個？
Seam：
優點：非常簡單直接
缺點：對於大項目過於簡單；沒有模組化開發的好例子
Struts：
優點：巨大的文檔和使用者群；跟著它沒錯
缺點：狀態/行為的分離過於教條化
WebWork：
優點：比Struts便於使用
缺點：複雜的UI難於維護，UI代碼過於複雜（JSF作者對action Framework都攻擊這一點）
Tapestry：
優點：概念新穎；可以應付複雜的UI
缺點：對於一個組件化（JSF主要競爭者），它依然依附於page/action的概念
4、你的framework的未來會怎樣？對於使用者開發會有什麼方便使用的變化？你會原生支援Ajax嗎？你們計劃支援它了嗎？
他認為JSF這個標準下這些應該有第三方提供。JSF(2.0)會提供“Partial Faces Request”，它是Ajax實現。JSF也會增強annotation組建編程。
5、有對你們的framework的傳言需要澄清嗎？如果有，是哪個？
很多JSF書都拿Struts作為對比。他認為這不能體現JSF的特點。他認為Struts和WebWork能做到的JSF也能做到。
6、你對Ruby on Rails的看法如何？
它與WebWork一樣好用，它的CoC（Convention over Configration）和腳手架非常好用。他認為CoC可以被應用在任何framework，他認為這是RoR最大的優點。他還認為RoR會走上其它 framework的路（複雜性等），因為人們需要自己的擴充。

RIFE(Geert Bevin)
1、你認為你的framework的“甜點”在哪裡？他最適合哪種類型的項目？
你可以付出10%的工作量，得到其它framework的90%的……，它是一個full-stack framework（如RoR）。它吸收了成熟的分層架構的架構，並將共同的優點彙集在一起。提供了web continuation，POJO驅動的CRUD產生，可擴充的基於組建的架構，無session的狀態控制，關注REST作為API，雙向無邏輯模版 引擎，整合了內容控制架構（CMS？）。每個層次的組建提供了可複用性（AOP，site，sub-site，page，widget，portlet 等）。適合於團隊快速開發公用Web項目，適合喜歡開發可複用組件的人。
2、它不適合於什麼樣的情境？在這些情境你推薦什麼fremework？它是哪個？
團隊中的每個人都有其它framework的知識，難於培訓他們。開發狀態相關的伺服器端Web組件，而不是用RIA或Ajax去實現。第三方支援很重要 的情況下（可憐RIFE使用者群還不大）。他推薦這種情況下使用JSF。或者在XML為主要發布形式的情況下，推薦Cocoon。
3、在下面提到的framework中，你實驗過他們嗎？如果實驗過，你比較喜歡哪個？你不喜歡哪個？
他實驗過WebWork，JSF，Wicket。他喜歡WebWork的簡單，但是不喜歡它的模版方式（tag的template，應該），它也不提供組件封裝。他認為JSF的工具支援非常吸引人。Wicket的純Java實現很不錯，可惜XML配置很不爽。
4、你的framework的未來會怎樣？對於使用者開發會有什麼方便使用的變化？你會原生支援Ajax嗎？你們計劃支援它了嗎？
關於Ajax，RIFE剛剛整合了DWR，而且選定以後也使用這個。整合Dojo，Scriptaculous，Prototype都很容易整合進來。
5、有對你們的framework的傳言需要澄清嗎？如果有，是哪個？
這些錯誤理念：1、RIFE的XML配置繁瑣 2、RIFE是continuations server 3、RIFE重新造輪子沒有提供新鮮東西 4、RIFE的模版文法很蹩腳過於簡單和業餘 5、RIFE是基於request的framework 6、RIFE的功能太多，學習曲線陡峭
6、你對Ruby on Rails的看法如何？
RoR對Java社區的衝擊非常棒，元編成也得到了信任。RoR沒什麼特殊之處，也沒有從Ruby語言獲益很多。
我討厭：它的模版。Partials（RoR中的組件）。URL的分散處理。Active Record提供了從資料庫schema而來的DSL，但是卻不是從domain model而來。沒有l10n和i18n支援。手動狀態轉換。不能在JVM運行（……）。實際上腳手架產生了實際代碼。Ruby缺少工具和IDE。

Seam(Gavin King)
1、你認為你的framework的“甜點”在哪裡？他最適合哪種類型的項目？
擁有豐富使用者互動體驗的應用。方便實現多視窗的操作，回退的支援，單視窗多工作區，無狀態瀏覽。對商務流程（BPM）的整合是獨一無二的。Seam方便使用資料驅動的ORM。遵循JSF和EJB3，多任務支援（多視窗/多工作區），BPM的領先解決方案。
2、它不適合於什麼樣的情境？在這些情境你推薦什麼fremework？它是哪個？
不適合只是將資料從資料庫顯示到網頁的應用，這時應該使用PHP或RoR。不適合需要設計特別的HTML組件的情況，此時應該選用Tapestry或Wicket。還在使用JDK1.4的人們。還有那些喜歡Struts的人（嘿嘿，夠狠）。
3、在下面提到的framework中，你實驗過他們嗎？如果實驗過，你比較喜歡哪個？你不喜歡哪個？
JSF：喜歡他的事件/互動模型。喜歡他的EL和模型繫結。不喜歡那麼多XML（為什麼沒有annotation）。建立自己的controls太難了。
Tapestry：非常好。form驗證是它的殺手鐧！模版方式很有創意。不過非基於POJO的組件模型則讓我對它失去興趣。
RIFE：這個東西很怪，但是有創業也有趣。我想進一步學習。如果學習先要自費武功:D
Struts：這個東西的模型view綁定太複雜了。東西已經過時了。
WebWork：比Struts好一點，不過也過時了。XWork曾經是個很好的實現，不過現在也過時了。
4、你的framework的未來會怎樣？對於使用者開發會有什麼方便使用的變化？你會原生支援Ajax嗎？你們計劃支援它了嗎？
Portal支援。遠程架構Seam Remoting Framework（Ajax）。模版訊息的工具支援。以後還要整合ESB，計劃引擎和非同步支援。
5、有對你們的framework的傳言需要澄清嗎？如果有，是哪個？
這些都不是真的：JSF不能處理GET requests。JSF post後無法redirect。JSF不能與REST共存。
6、你對Ruby on Rails的看法如何？
它是PHP的很好替代品。如果它有一個正經一點的持久化層它就可以和Java競爭了。

Spring MVC(Rob Harrop)和Spring Web Flow(Rob Harrop and Keith Donald)
1、你認為你的framework的“甜點”在哪裡？他最適合哪種類型的項目？
Spring MVC：
穩定可擴充，支援了i18n、檔案上傳、異常處理，這些穩定的支援給開發人員堅實的工作基礎。是最佳實務，告訴你怎麼做是最好的。與Spring整合，領先 的 IoC遠生支援。支援，Spring社區活躍和龐大。Struts開發人員可以平滑過渡。適合多種項目，可選的多種result類型。
Spring Web Flow：
內建任務處理引擎，支援線性處理過程中的持續狀態。抽象，減少開發的關注點。適合多種項目類型，外掛程式支援Spring MVC、Struts、JSF等。
2、它不適合於什麼樣的情境？在這些情境你推薦什麼fremework？它是哪個？
Spring MVC：不適合需要組件化開發的情境。它是一個request驅動的MVC。那些情境推薦JSF或Tapestry。
Spring Web Flow：處理線性頁面流，不適合一般的“自由瀏覽”。當然Spring Web Flow可以與request驅動或者組件驅動共存。
3、在下面提到的framework中，你實驗過他們嗎？如果實驗過，你比較喜歡哪個？你不喜歡哪個？
Spring架構支援Struts和JSF整合。
4、你的framework的未來會怎樣？對於使用者開發會有什麼方便使用的變化？你會原生支援Ajax嗎？你們計劃支援它了嗎？
Spring MVC：簡化JSP標籤。更多的MVC配置schema。CoC風格的預設控制器、URL影射、view，學習Rails和Stripes的優點。增強資料繫結和驗證（支援範型綁定）。Portlet支援。Spring也要接受Ajax，使用DWR庫。
Spring Web Flow：一大堆，關心的可以自己看……
5、有對你們的framework的傳言需要澄清嗎？如果有，是哪個？
Spring MVC難於配置。在Spring 2.0，將會改善，可以使用自己定義的基於schema的配置。
6、你對Ruby on Rails的看法如何？
Spring MVC：RoR非常有趣。不過現在就拿出來用還有點幼稚。這裡舉了個例子，關於變數的複數形式的處理，RoR會使用這樣的CoC風格來處理變數list， 而Spring MVC也實驗了種種風格，但是受到的結果卻很差。人們認為英語的複數很古怪，沒有一定的規則，所以會帶來混亂，如（person -> people）。所以Spring MVC設計了變數+List的命名，personList更加明確，雖然這樣不酷，但更好用。就是說Spring MVC要取其精華去其糟粕。

Stripes(Tim Fennell)
1、你認為你的framework的“甜點”在哪裡？他最適合哪種類型的項目？
與Spring MVC、WebWork等相同。它提供高品質action驅動的架構的同時，盡量簡化配置，增進開發效率。Stripes適合複雜的資料互動的場合。這種情況下綁定驗證的強項就完全體現出來了，能夠很好的處理form和map轉換等。
2、它不適合於什麼樣的情境？在這些情境你推薦什麼fremework？它是哪個？
所有的action驅動的framework都適合使用者在非Ajax驅動的情況下在一個頁面進行松關聯（loosely related）和無狀態互動的情況。適合每次都重新整理的頁面。管理多視窗間持續狀態的應用會比較麻煩，此時應該選擇JSF。不過我認為90%以上的Web 程式都是前者，JSF只適合剩下的那9%，AJAX對於管理無狀態UI更加適合。用戶端不需要AJAX，則可以看看Wicket，它更加簡單。
3、在下面提到的framework中，你實驗過他們嗎？如果實驗過，你比較喜歡哪個？你不喜歡哪個？
用過Struts、WebWork、Spring MVC。其中Struts做過商業項目，不過這個東西帶來的麻煩遠比帶來的效率提升要多。它認為這些MVC都有三個缺點：暴露了過多的複雜性給可發者。沒 有提供足夠的開發便利性，沒有提供足夠多的錯誤和提示資訊，也沒有date格式化等小的便利（其實有）。穩當太差。
4、你的framework的未來會怎樣？對於使用者開發會有什麼方便使用的變化？你會原生支援Ajax嗎？你們計劃支援它了嗎？
1.3要加入Inteceptor，實現AOP功能。驗證系統要加強。支援Ajax。我還在尋找一個好的Ajax/javascript庫。
5、有對你們的framework的傳言需要澄清嗎？如果有，是哪個？
這些觀點：1、Stripes使用了annotation代替XML，只是換湯不換藥：由於中繼資料更接近代碼，所以修改預設的配置非常方便，不像XML那 樣複雜，這是實質的變化。2、Annotation意味著你只能有一套配置：我認為90%的action都有自己的一套配置！Stripes會根據繼承關 系尋找Annotations，子類的annotation會覆蓋父類的，因為像validation都是可以繼承的，如果特別需要還可以覆蓋。這樣很合 理。在1.3中允許validations基於UI事件進行。它向後相容，不需要可以不用。
6、你對Ruby on Rails的看法如何？
我認為Java社區有很多可以從RoR學習的地方。Stripes學習了RoR的前端部分，開發人員可以減少配置量。但是RoR的RHTML讓我想到了以前 的 JSP中混亂的scriptlet。而後面的ActiveRecord是一個很好的理念，實現的也很好。ActiveRecord比Hibernate等 複雜的ORM工具要容易理解，因為這樣的特點RoR才引起了這麼大的波瀾。

Struts Action 1(Don Brown)
1、你認為你的framework的“甜點”在哪裡？他最適合哪種類型的項目？
文檔和使用者基礎，書籍和背後的支援。容易僱到人（也容易找工作）。雖然其他項目的理念比這個要先進，但是這些不算什麼。實際上，Web層是很容易也很直接的。
2、它不適合於什麼樣的情境？在這些情境你推薦什麼fremework？它是哪個？
如果你需要portlets或者複雜的頁面（顯示很多東西），那麼Struts要麼無法工作要麼太枯燥。這種情況你需要一個基於組件的framework，如JSF、Tapestry/Wicket。
3、在下面提到的framework中，你實驗過他們嗎？如果實驗過，你比較喜歡哪個？你不喜歡哪個？
這些我基本都實驗過，他們每個都工作的很不錯。
4、你的framework的未來會怎樣？對於使用者開發會有什麼方便使用的變化？你會原生支援Ajax嗎？你們計劃支援它了嗎？
Struts Action 2基於WebWork2，很快會開始。現在已經支援Ajax了，我們在尋找更加容易的開發方式，JSF支援（Struts Shale），continuation支援，還有支援更多的指令碼語言（BSF擴充指令碼撰寫Action）。
5、有對你們的framework的傳言需要澄清嗎？如果有，是哪個？
Struts太過時了，而且也不酷，難於使用。但是你可以自己修改或者擴充它。我認為團隊對於你的限制遠大於framework對你的限制。
6、你對Ruby on Rails的看法如何？
不需要D&D工具，旨在協助開發人員提高開發效率的好例子。我們在Action 2中將學習它的先進理念。

Tapestry(Howard Lewis Ship)
1、你認為你的framework的“甜點”在哪裡？他最適合哪種類型的項目？
我想Tapestry對於中等規模或者大規模的應用會帶來很多好處（甚至你可以在單頁面的應用程式中獲得好處）。這裡有允許你建立新的組件的良好工具。 Tapestry不關心資料從哪裡來，很多“項目類型”都基於切面（aspect）（如CRUD vs. RSS feed vs. etc.）。我認為Tapestry非常容易與IoC整合（HiveMind或與Spring），方便進行測試。
2、它不適合於什麼樣的情境？在這些情境你推薦什麼fremework？它是哪個？
我在其它Java framework中沒有找到到強於Tapestry的優點。但是對於RoR，我自己沒有使用過使用，很難說RoR中的項目應該是什麼樣子。我沒有仔細對 比過RIFE，它看起來受了RoR影響，尤其是類似ActiveRecord的資料訪問層。但是如果你的應用需要特定的URL格式，那麼在 Tapestry中奮戰勝算不大。
3、在下面提到的framework中，你實驗過他們嗎？如果實驗過，你比較喜歡哪個？你不喜歡哪個？
在這兩年來我沒怎麼嘗試過Tapestry以外的東西。我沒怎麼學習RoR，因為時間太有限了。
4、你的framework的未來會怎樣？對於使用者開發會有什麼方便使用的變化？你會原生支援Ajax嗎？你們計劃支援它了嗎？
Tapestry 4.0有很好的Ajax支援，通過Tacos庫。而Tapestry 4.1還要進一步強化這方面的支援。
Tapestry 5.0提供了明顯的改進：沒有abstract類（Tapestry的怪癖:）。沒有強迫的繼承關係。對屬性進行annotation而不是方法。沒有 XML，只有模版和annotaions。只能類裝載，自動尋找類的變化。最小化API，超越annotaion。面向方面（Aspect- oriented）模組構造，使用mix-ins。
5、有對你們的framework的傳言需要澄清嗎？如果有，是哪個？
Tapestry 3.0還不容易測試，4.0改善了一些。Tapestry只是個人秀；實際上我們有很多活躍的貢獻者。Tapestry的學習曲線非場陡峭。它只有漂亮的 模版實現；實際上Tapestry的特點在於狀態管理（允許Object Storage Service狀態，而不是多線程的單例來管理requests之間的游離和持久狀態）
6、你對Ruby on Rails的看法如何？
很有影響力。但是模版的實現非常醜陋。我聽到了很多意見，關於RoR的優缺點。基於我的基本理解，這些觀念對Tapestry 4產生了影響（它對Tapestry 5影響更深）。
RoR 意味著限制了你的選擇：如果你選擇RoR那麼就要尊旬它的實踐（CoC..），看起來你的錢會花的恨值。這些類似Microsoft的哲學。而Java更 崇尚給你更寬鬆的選擇，不限定你使用的工具，但是曖昧的說這需要你對你的工具理解更深。不僅對Tapestry，還對於JEE、Spring這寫 entire stack的架構，需要從RoR學習，不僅提供工具，還需要提供整套的解決方案。

Trails(Chris Nelson)
1、你認為你的framework的“甜點”在哪裡？他最適合哪種類型的項目？
Trails 的應用程式只需要Web介面和持久化的domain model就可以了。Trails給你的domain model快速的提供一個介面，除了POJO自己不需要附加的代碼。Trails允許你修改介面的外觀和行為，包括驗證、i18n、安全。這些都不需要 java代碼產生，不喜歡代碼產生的人應該感覺很舒適。
2、它不適合於什麼樣的情境？在這些情境你推薦什麼fremework？它是哪個？
Trails 講究夠用就好。它允許你快速交付，問問你的客戶：“這樣夠好嗎？”。這會改變你的工作流程，當然這不是可以覆蓋所有需求的解決方案。當UI需求很高， Trails沒有優勢。我認為Trails適合於混合的應用，對於管理員他們只需要夠用就好，那麼就可以使用Trails。其它的部分我們可以訂製開發， 我們在使用Tapestry、Hibernate、Spring來實現這些部分，Trails正是基於它們。對於非互動的應用，Trails也不適合，如 報表應用，可以考慮Eclipse BIRT。
3、在下面提到的framework中，你實驗過他們嗎？如果實驗過，你比較喜歡哪個？你不喜歡哪個？
我用Struts很多。它曾經是偉大的framework。主要的缺陷是它不能自動幫定資料到domain model。我也研究過JSF，它比Struts強，但是自訂群組建非常難。Tapestry非常便於自訂群組建，尤其對於建立高階組件（有其它組件組成 的）非常方便，Trails正在使用它。
4、你的framework的未來會怎樣？對於使用者開發會有什麼方便使用的變化？你會原生支援Ajax嗎？你們計劃支援它了嗎？
對於Trails來說我們站在巨人的肩膀上。Tapestry在ajax功能作了很多努力，所以Trails也不難與其共舞。但是我們需要建立更多的例子 來示範這些。我們也致力於讓Trails容易介入到已經進行的項目中。以後Trails還要加入基於執行個體的安全（instance-based security）（目前正在使用基於角色的role-based），還有method invocation。
5、有對你們的framework的傳言需要澄清嗎？如果有，是哪個？
Trails是對RoR的移植。Trails的名字來自Rails。它是基於Rails的理念，但不是對它的移植。
6、你對Ruby on Rails的看法如何？
我認為我們有很多需要從RoR學習的地方，那將協助我們享受開發Web程式的愜意。

WebWork(Patrick Lightbody)
1、你認為你的framework的“甜點”在哪裡？他最適合哪種類型的項目？
一般來說，WebWork一般適合小的團隊，它們願意保持一雙髒手，學習開元工具如何使用。WebWork不面向“輪椅程式員”，那些人只喜歡拖拽式的開 發。WebWork給花時間學習它的人回報。例如，直到輸入和輸出的人（閱讀了參考文檔，那樣很好）能夠容易的建立ActionMapper和 Configuration實現來提供“慣例”代替配置（CoC）的方便。我最近的例子中，URL是這樣 “/project/123/suite/456/test/create”影射到 “com.autoriginate.actions.project.suite.test.CreateAction”，然後自動的傳遞參數： projectId=123、suiteId=456。而Result是“[action].jsp”或者“[action]-[result]. jsp”，也可以通過annotation來配置。
也就是說，WebWork是你的應用程式framework中的最佳基礎工具。在這種情況以外也很好，但是目前不算最佳的“甜點”。
除去這些一般的，WebWork對於正在建立需要外掛程式和擴充的產品的人是必備的。例如JIRA、Confluence、Jive Forums。因為WebWork支援廣泛的模版語言（Velociy和FreeMarker），完整的tag支援，模組寫好後非常容易插入。一個jar 包就可以包括所有的action和view（得益於ftl的classpath支援）。最終的效果很好：在Confluence中你可以通過管理介面上傳 一個jar，這個plug-in就會自動部署。這是因為Atlassian（Confluence、Jira的小組）非常瞭解這個framework，並 且作了很多的貢獻。
2、它不適合於什麼樣的情境？在這些情境你推薦什麼fremework？它是哪個？
與其它action framework相同，WebWork在控制狀態和wizards上比較弱。如果你寫了很多長的wizards，JSF可能是比較好的解決方案。我還想 說，文檔還需要改善（參考文檔還不錯，但是教程、cookbooks和FAQ還比較差），如果沒有一個WebWork高手作為項目領隊，新手可能會敬而遠 之。
對於非常簡單的程式，我推薦使用簡單的JSP或者Spring MVC，如果使用者接受Spring的話。但是總的來說，我認為在action framework中WebWork是最好的。
3、在下面提到的framework中，你實驗過他們嗎？如果實驗過，你比較喜歡哪個？你不喜歡哪個？
我 實驗過RIFE、Spring MVC、Struts、Spring Web Flow，還有一點點Tapestry。我發現RIFE的概念很優秀，但是它的實現不怎麼樣。不難想象Geert還是使用“m_”作為欄位的首碼。它看起 來不像Java。模版難住了我，所以就沒有繼續看。
Spring MVC還可以，但是它是一個非常簡單的framework實現。WebWork的資料繫結（WebWork世界中稱為類型轉換）要強多了，而且是自動的 （而Spring需要自己寫property editors）。在Spring中的view替換支援泰有限了，而WebWork中的UI tags在Spring中壓根沒有提供。Spring中你可以使用JSP 2.0輕鬆的寫自己的tag，但是不支援其它的語言。
Spring Web Flow：XML讓我抓狂。太過火了，不管Keith的主張，它“不支援任何的Web framework”。這個web framwork迴避掉了WebWork、Spring MVC、Struts或者其它framework中的99%。我倒不是說這是個壞主意，但是我應該誠實的說它是一個完整的架構。
Tapestry 很優雅，但是HTML 屬性（jwcid）惹人厭。我接受這種理念，且實踐中這會帶來一些好處（Shale也有相似的地方）。但是實際上，我發現 “HTML/CSS開發人員”和“app開發人員”一般是同一個人，Tapestry就架設如此。實際上，由於Ajax的推動，我想越來越多的“程式邏輯”會 被嵌入到UI；這樣的話，Tapestry的模型就不那麼適宜了。
4、你的framework的未來會怎樣？對於使用者開發會有什麼方便使用的變化？你會原生支援Ajax嗎？你們計劃支援它了嗎？
在Struts Action 2.0我們希望：更好的文檔。支援標準（如果可以，我們希望用JSTL代替OGNL，但是首先要保證不會有功能損失）。增強AJAX支援，提供更多的widgets：如自動完成。解除配置地獄；提供更多的選擇，如我們開始所說的CoC。
5、有對你們的framework的傳言需要澄清嗎？如果有，是哪個？
他需要很多的配置：我已經示範過，通過CoC風格，它可以做的比Rails更好（Rails的管理部允許內嵌controllers）。
6、你對Ruby on Rails的看法如何？
非常重要的一點是，我要說RoR不能與大多數的framework對比，除了RIFE和Seam。對比RoR和WebWork就相當於對比Hibernate和JDBC。一個是full stack，另一個只是stack中的一部分。
另一個重要的問題：DHH是個怪胎，但是聰明的怪胎。它的高效率無可爭辯，它被稱為Rails。
好的，我們不說這個，隨便說說別的：
我使用Rails建立了一個小的app。我把它扔掉並很快用Java重寫了。我認為Rails可以讓你的app中的80%快速完成；而剩下的20%比前面 80%需要花的時間還多。當然程式開發就是這樣。腳手架非常酷，尤其是ActiveRecord在運行時改變類。但是後來你需要寫UI、自訂的驗證規 則，自訂安全影射等等。一個基於CRUD的app能夠在30分鐘內運行並不意味著你能以這個速度完成它。
Rails的web framework部分相比於WebWork很可怕。實際上根本無法比較。它的實現更接近於Spring MVC的簡易功能。
完整的stack非常棒。他們在這方面做得很好，這裡Java還有差距需要追趕。WebWork是web stack，但是持久化解決方案並不確定。所以最大的問題在於即使WebWork和SiteMesh提供了如配置動態讀取和動態類reloading， Spring、iBatis和Hibernate並不提供。它們至少需要提供配置重讀取後才可以發展出類似Rails那樣的功能。類似的， Hibernate和iBatis對WebWork等的請求提供的支援不夠。對於一個類，我可以不需要再xwork.xml中進行配置，但是持久化引擎並 不允許我們這樣做。當這些功能能夠同時具備，沒準一個complete stack的架構就會推出。
要求快5倍10倍是愚蠢的。可靠的工程師都知道開發產品的時候最大的警力都花費在構思代碼上，而不是書寫代碼。定義需求，擷取反饋，市場定位，定義資料庫結構，映射使用者介面。不管使用什麼語言，你需要思考很長時間。沒有語言或者架構能夠提升思考的速度。
最後，Rails提供了：用指令碼語言良好實現的stack。Python、Perl尤其是PHP中的其它架構還沒有成熟。我認為“PHP猴子”們還有很多 事情要做，他們通常不是很有才乾的工程師。（可能我翻譯錯誤了，希望糾正）。在指令碼語言中提供良好的架構，人們能夠實現設計精良的app並的到回報（因為 指令碼語言的特點）。不只是“管理代替配置CoC”甚至是整合stack，Java需要的是立刻反射出變化的能力。很多Java開源領袖認為“修改 web.xml”的重新載入是一種方法。這種智力遊戲應該結束了。我們不僅僅需要設定檔和類的重新載入，我們需要社區給Sun足夠的壓力，使其能夠在下 一代的JVM中提供熱插拔（HotSwap）的能力。或者，更加複雜的程式模型，如OSGi，需要進一布被社區所接受。當然我並不希望走那條路線。

Wicket(Eelco Hillenius)
1、你認為你的framework的“甜點”在哪裡？他最適合哪種類型的項目？
我認為有5點：Wicket是以代碼為中心的：可以在view層進行OO編程。組件是完全自管理的：容易建立和重用。概念的分離是清晰的也是強迫的。乾淨的模版。開發伸縮性大-就像OO一樣。
2、它不適合於什麼樣的情境？在這些情境你推薦什麼fremework？它是哪個？
Wicket不適合UI很簡單且唯讀場合。這時頁面指令碼更加適合，比如JSP，或者JSF。如果你需要無限的延展性，你可能需要狀態無關的實現。從1.2版開始，Wicket也有無狀態頁面的概念，這樣延展性與其它framework差不多了。
3、在下面提到的framework中，你實驗過他們嗎？如果實驗過，你比較喜歡哪個？你不喜歡哪個？
JSF：
優點：基於組件。工業背景。工具支援。一些擴充讓他更容易使用。它允許你從傳統JSP升級到JSF。
缺點：它缺少其它API的優雅。以JSP為中心。配置很多而且代碼很難看。有很多種實現。它讓我回憶起EJB1/2，以廠商為中心等等。
RIFE：沒用過，說了一大堆。
Seam：不是一個真正的Web framework。類似JSF擴充。如果使用EJB/JSF/JBoss組合，這個選擇很好。但是不遵循JSR 227/235。
Tapestry：很好，4.0版本好了很多。我把它推薦給我所工作的公司。Wicket更加以編程為中心。而Tapestry更加pragmatic。
Trails：從來沒用過。
Spring Web Flow：framework本身很好，但是我不喜歡它的stacking。如果用工作流程，我希望選擇一個如jBMP的方案。我也不喜歡以流為中心的解決方案，認為這樣很過程化。
WebWork、 Spring MVC、Struts：Model 2的framework糟透了。我用過幾年，也對Maverick貢獻過代碼，但是我徹底失去興趣了。Model 2 framework太過程化了，這些程式員不知道怎麼用OO編程。我寧可僱傭一個Swing編程的人也不會去選擇一個使用Model 2 framework編程的人，因為Swing編程的人寫的程式一般更漂亮。……如果讓我從這些Model 2 framework中挑一個出來，我選擇Stripes，它拋棄了model 2中的一些不好的方面。
4、你的framework的未來會怎樣？對於使用者開發會有什麼方便使用的變化？你會原生支援Ajax嗎？你們計劃支援它了嗎？
我們將會支援Java5。我們會增強Spring支援，複雜的許可權認證支援，和基於角色的參考實現，還會提供原生AJAX支援，URL載入（nice URLs），無狀態頁等。
我們的市場佔有率不高，但是使用者群在提高。我正在寫“Wicket In Action”（Manning出版）正在籌劃中，今年夏天會出版。
5、有對你們的framework的傳言需要澄清嗎？如果有，是哪個？
關於伸縮性的問題是第一位的。程式的可伸縮型一般是由資料庫效能差或者緩衝策略查詢最佳化並發等問題。伺服器端延展性並不一定不可擴充，可以通過叢集來繼絕。……
6、你對Ruby on Rails的看法如何？
我喜歡我看到的Ruby，如果我有時間我還會仔細把玩它。如果不是Wicket的問題，我希望更多的實踐RoR。……