This post originated from an RSS feed registered with Java Buzz
by Matt Raible.
Original Post: So Struts is Dead, huh?
Feed Title: Raible Designs ~ We Build Web Apps
Feed URL: http://static.raibledesigns.com/500.html
Feed Description: Opinions and tips on how to build web applications using Java. Currently using Hibernate, Struts, XHTML, CSS, Ant, JUnit and XDoclet.
So most folks think Struts is Dead, huh? I've got news for you folks. Struts has been dead since 2002. For that matter, most Java frameworks have been dead for the last year. Most folks think Struts is dead because there won't be any new and whiz-bang features added in future releases. I'm willing to bet the other Java Web Frameworks won't add any whiz-bang features in the next few years either. Sure, WebWork might get a little XMLHttpRequest lovin' for client-side validation, and Tapestry might get pretty URLs - but both of these are features that these frameworks should've had in the first place. So what's the big deal? At least the Struts Developers have the guts to stand up and say "we're in maintenance mode". Shouldn't all framework developer's be able to say this? It's really quite an accomplishment.
IMO, the only developers that shouldn't be saying this are Tapestry and JSF folks. Both of these teams should be saying - "we're going to make our frameworks easier." If these frameworks are going to be the future of Java web development, there's some work to do. The JSF folks should be saying, "we're going to fix all the stuff that's broken". This "stuff" includes POST for everything, lack of bookmarkability, and bad validation messages (the good news is the validation messages should be fixed in JSF 1.2). I think Tapestry needs some simplification too. In my experience, most Tapestry pages (by design) require 4 files. One for the Java class, one of the HTML template, one for the page specification and one for the i18n keys. This should be easier. It'd like to see two required files (template and Java class) and the others are optional. Maybe annotations could eliminate the page specification? I think there's a lot to be learned from frameworks like Ruby on Rails: default everything, allow overriding.
I think that Shale will be good, but only if it learns from the other MVC frameworks available. If I were on the team, I'd take the good things from all the others: IoC, Interceptors, HTML templates, etc. I wouldn't stop there either - there needs to be good examples of how to integrate it with middle-tier frameworks like Spring, Hivemind and EJBs. Often developers will take examples as recipes - so the more detailed and simple, the better. The Struts developers have quite an opportunity to make something great, let's hope they don't just create another framework.
Previous Topic
