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的特點在于狀態管理（允許對象存儲狀態，而不是多線程的單例來管理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。……