Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

RECENT ENTRIES


Tag Cloud


abbie appfuse birthday denver family grails gwt jack java javascript jsf linkedin maven montana roller skiing softwaresummit spring springmvc struts2 travel trish vacation webframeworks wicket
« Made it home! | Main | Generate your iBATIS... »
Monday January 31, 2005

So Struts is Dead, huh?

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.

Posted in Java at Jan 31 2005, 06:48:01 PM MST 13 Comments
Comments:

Have you looked at how the ASP.NET model works, it's much like what you are requesting of Tapestry. I'm just playing the devil's advocate for the Microsoft side.

Posted by Nick Parker on January 31, 2005 at 08:37 PM MST #

I think Tapestry 3.1 is going to be more (r)evolutionary than you give it credit. Here's Richard Lewis-Shell's comments:
From where I sit, the 3.1 changes look bigger than any changes Tapestry has seen in my time with it. Which is to say that the way I think about using Tapestry has changed little since the 0.2.x days, but '3.1' looks like it will force something of a re-think - for the better.
The new design will support so much more than is possible in 3.0. I can see the main code base staying compatible with JDK 1.3 and annotation support as a n additional jar that plugs into the necessary pipelines. Simplification is definately happening as well; everything in 3.1 is getting simpler and more consistent. I'm also beginning to see web app development as primarily about moving data around during and between requests ... and again, 3.1 vastly improves this, offering many more (and more efficient) conduits than just OGNL (which is still indispensible). I think your goals are good, and my long term, post-3.1, vision is even more encompassing (it includes freedom from extending framework classes), but I bristle at the notion that Tapestry is not making vast forward progress.

Posted by Howard Lewis Ship on January 31, 2005 at 09:52 PM MST #

You're mis-representing Struts developers - AFAIK no-one has said "we're in maintenance mode".

Link to the annoucement made on the Struts Developers List regarding the Shale sub-project is below.

Posted by Niall on January 31, 2005 at 10:00 PM MST #

I think tapestry has a bright future. Howard and I share a common influence in that we both were Web Objects developers. I'm not as smart as Howard ;) but after years of ATG JHTML, Struts and other frameworks I'm happy to see Tapestry bring back the simple component model that WebObjects had. I think tapestry will end up going far beyond WebObjects with the inclusion of HiveMind. Struts did a good service to the community. But I will no longer reccomend its use, however it has won the heart of the industry at large for now and by sheer volume of the number of installations I think it is premature to call it 'dead'. From all I can discern I would agree that Tapestry 3.1 is a major release rather than a 'patch' of sorts. I will be reccomending that my clients consider moving to Tapesty. There is a real gain with Tapestry in that it steers you out of the mess of Struts and JSF. You simply need to learn Tapestry and the precedent with Tapestry is one of solid and stable growthy instead of the Struts team which is now balkanizing into Struts classic and Struts shale. I think I just plain hate struts. Any long time struts developer will have some reasons to share with you about its' shortcomings. This is no comment about the struts development team, I used to lurk on the struts-dev list and there were alot of talented folks around in the early days....I hope others will be lending their effort to Tapestry as well.

Posted by Daniel Honig on January 31, 2005 at 10:54 PM MST #

Matt, Do you really think Struts is mature enought to get into maintenance mode? Claiming all the broken/ill design to be the Good Architecture? If thats what Struts developers think, then yes, Struts was dead from the day one they thought so. May be "preservation mode" would be te right term. I am not saying JSF or any other web app frmwrks are great. It would be nice to add the StrutsLive features to Struts. But then again, its like performing a CPR on a Corpse. :-)

Posted by Chakra Yadavalli on January 31, 2005 at 11:41 PM MST #

Succesful frameworks tend to be extracted from equally succesful projects, take Ruby on Rails and Basecamp for example. Starting a new framework from scratch is much harder because the pragmatic approach you get when you have a real need in a real project is missing. Borrowing proven features of other frameworks does not drive innovation...

Posted by Zsolt on February 01, 2005 at 02:35 AM MST #

For desktop like application(this concern a lot off application), framework like millstone, or webonswing ar really powerful don't forget them http://www.millstone.org/ webonswing.sourceforge.net/ Regards, Marc

Posted by Marc Godin on February 01, 2005 at 08:02 AM MST #

Your last paragraph is 100% true. Lets hope that they(the Shale team) is thinking as you are!

Posted by Kris Thompson on February 01, 2005 at 08:21 AM MST #

I'm more interested in what Shale would bring to the table that other frameworks (Tapestry, Webwork2, etc.) don't have? Is it going to be ASP.Net for Java (like JSP vs. ASP)? And will companies (and headhunters) accept it more because it's called "Struts Shale" instead of just "Shale"? Maybe Howard should rename Tapestry to "Struts Tapestry" so more companies consider it for new development ;-)

Posted by Ken Yee on February 01, 2005 at 09:40 AM MST #

no matter what, i'll still love and use Struts unless our client requests something else. :)

Posted by sj on February 01, 2005 at 02:39 PM MST #

http://theserverside.com/news/thread.tss?thread_id=31665

Posted by Vic on February 08, 2005 at 01:27 PM MST #

oops

Posted by Vic on February 08, 2005 at 01:28 PM MST #

Struts Shale is a great opportunity for a bunch of folks to run out and write Struts Shale books ;-) Levity aside, I think that Craig migrated a lot of good ideas from Struts into JSF, and now he's going back and removing the overlap from Struts. Freed from the need to be backwards compatible, he's also going to snarf up every good idea that he can find from other frameworks... Based on past performance, the Shale/JSF combo should be quite usable. As I understand it, Shale will not be JSF agnostic. You won't be able to replace JSF with something else (like you can replace JSP with Velocity in Struts). Hopefully he will support JSF without JSP as suggested by Hans Bergsten.

Posted by John Reynolds on March 11, 2005 at 01:27 PM MST #

Post a Comment:
  • HTML Syntax: Allowed