Mark Watson:"The problem I am having is that I would very much like to settle on a single framework in order to reduce the effort of staying on top of too many tools and frameworks. [...]
I would like to be able to invest at most 100 hours of study time, and get back up to speed on a single framework, but I am not sure which to choose. GWT is very tempting but GWT does not cover all of the types of web applications and services that I am likely to be contracted to build. Seam looks good as an integrated framework, but I need to set aside a long weekend to give it a good preliminary evaluation."
Given what I know about Mark (working in Ruby) and his background (AI/Lisp, I have one of his books from college), I would recommend looking at Grails. Grails also has orthodox internals that will appeal to most shops that use Java - Groovy running with Spring, Sitemesh and Hibernate - so for example, the ActiveRecord style approach doesn't become a point of resistence, and even though Groovy is not the fastest language on the block, the framework is offloading plenty of work. Groovy has also the advantage of being syntactically closer to Java than Python/Ruby, which eases adoption - if you squint you might see Javascript, which gives interesting options for who builds server side web pages :)
I don't think Seam is the right choice if your background or productivity sweet spot is a Rails/Django style stack, though I'm sure it will be a popular framework for in-house work or 'post-modern' enterprise projects. JRuby/Rails I think will only get faster, fwiw.
Because our new projects involve only building RIA web apps, where we follow this model:
RIA + SOA
We don't use any web framework in the web server middle-tier at all.
MVC is entirely implemented in the RIA client-tier. The client merely does asynchronous services calls to the middle-tier, or responds to asynchronous messages pushed via BlazeDS from the middle-tier (in all cases, a closure handles the asynchronous result that arises - and has a fault closure to handle transport/network faults).
In the middle-tier we're running on Tomcat and have BlazeDS coupled to Spring Framework and its bridged to ActiveMQ JMS messaging (clients are proxied in by BlazeDS as subscribers to topics).
All we're using Spring Framework for is Spring Security, some Spring controllers, and its the IoC factory to BlazeDS (which BlazeDS can be used to let Spring instantiate beans to handle remoting calls, etc.).
So we don't need no stinking middle-tier web framework, to paraphase a popular street expression. RIA + SOA is simpler and better architecture to follow instead.
Previous Topic
