In response to Paul’s last post, “Struts is the new Mini”. Paul I can see where you are coming from, but choosing tomorrow’s winners from yesterday’s successes has never been a winning strategy in immature markets. Many organizations have already abandoned Struts 1.x. The only organizations left using Struts 1.x are the slower corporations, and when these organizations finally get around to moving to a newer framework they’ll have a variety of mature technologies to choose from (and a lingering sense that they probably don’t want to repeat the mistakes of Struts 1.x). The real question people using Struts 1.x are going to be asking themselves, is, “How did I get stuck with a framework that didn’t evolve?” We’re talking about software, and unlike my 1999 Camry LE, there’s no reason why software should be discarded after 160,000 miles.

Struts 2 and Brand Continuity

The Struts community took a revolutionary approach as opposed to an evolutionary approach - they didn’t try to launch series of incremental model redesigns in an attempt to create a seamless transition to the “Struts + WebWork (aka Struts 2)”. They’ve only recently realized this and they have some brand repair to do in the next few months. Shale was the real brand opportunity, and for at least a year or two, everyone was talking about “Shale is the new Struts, should we move to Shale?”. Shale didn’t gain developer support or customer traction, and, in the end, the customer demanded an evolutionary approach. In the world of brand marketing you don’t risk a successful brand by introducing too much change all at once. The Toyota Camry is a good example.

Toyota redesigned the brand incrementally (’92, ‘97, ‘02, ‘07) and made dramatic changes to the car without changing the basic interface, but because they took small steps, they’ve preserved the brand. As a consumer, you conceptualize the Toyota Camry as a single continuous product line, but at the technical level the differences between a 1999 Camry and a 2007 Camry Hybrid are dramatic. My 1999 Camry is (almost) a completely different model than a 2004 Camry, and an entirely different car from the 2007 Camry Hybrid. (And the styling differences between standard Camrys and the newer sporty Camrys imply a purposeful brand distinction) Even with these changes, if I’ve had a good experience with my 99 Camry, I’m more likely to just buy an ‘07 Hybrid. On the other hand, the differences between Struts 1.x and Struts 2 break brand continuity, and, even though Struts 2 is a quality contender, you should consider it a new entry on the market. Struts 2 and Struts 1 might both be considered family sedans, they both might have the same odometer and steering wheel, but it’s a different drive train and don’t just assume that you are going to take it into the same mechanic. Struts is the new Mini in 2004, and the analysts are withholding judgment until we get a sense of the resale value. And, admittedly, the interface for a car is much simpler than the interface to a web application framework (steering wheel, ignition, and gas pedal vs. web.xml, struts-config.xml, and JavaBeans), so the automotive analogy shouldn’t be carried too far. read on…

Shop around before you buy a Mini - they are expensive

Now is a better time than ever to sample the crowd of frameworks. (You can get a 2007 Stripes with no money down and no interest payments until 2009*). If you end up going with Struts 2, then more power to you. I’m sure Struts 2 is a fine framework, but it would be a mistake not to evaluate the market. Anyone considering changing web frameworks should try some of the following steps before making a decision:

• Try out Stripes and Struts 2 - Take a look at Stripes. Read Stripes vs. Struts by Tim Fennell. Then take a look at Struts 2. Stripes has a good following, and it was developed to address Tim’s issues with Struts. As you look at Struts 2 look at some of the responses to Struts 1 that are out there. I’m not suggesting either; I’m just recommending an objective search and a skeptical eye.
• Try out a Component-oriented Approach - Give either GWT or Tapestry or Wicket a try. Tapestry has been around longer than Wicket, but Wicket has great momentum. From my own experience, Wicket has very capable Ajax facilities that scale very well with increased complexity. The main disadvantage of a component framework for someone used to Struts 1.x is that it will take you some time to understand the approach. Once you do, it will make perfect sense. Don’t choose until you’ve taken GWT for a test drive.
• Try out a Scripting Approach: Use Rails or Django - Eventually, Rails is going to be an option on the JVM (whether you like it or not), evaluate it now and you’ll be able to make a more informed decision as this option starts to become a reality over the next few months. Also, don’t shy away from solving simpler problems with Ruby on Rails. Ruby on Rails is a great way to prototype and you might find that it frees up more time for you to tackle the interesting problems in Java.
• Read about ASP.NET and other platforms - I know you don’t like this, but check out the web application options from Microsoft, if you are building reports, look at SQL Server 2005 Reporting Services. I’m not recommending you adopt a Microsoft stack, and I don’t wish SQL Server on anyone. But, you need to be familiar with what the other half of the industry is using.
• Read about Java Server Faces - Another component approach. Personally, I have yet to meet anyone who is excited about JSF; on the other hand, I have met many people who are excited about all of the projects mentioned previously (including ASP.NET). Know that if you do want to use JavaServer Faces there is integration with Struts 2.
• Others - Please evaluate some other contenders, and do us all a favor, blog about them once you’ve given them a fair chance. If you are looking for a comprehensive list, read this.

Consider buying two cars

The answer to the question, “what framework do you use?” is no longer a single valued return parameter. It’s more of a “Well, my wife drives an Outback, but we have a Minivan for longer trips”… And, if someone asks you, “What framework we should use?” Your answer should include at least two values: “${action framework of your preference} for action-oriented systems, and ${component framework of your preference} for component-oriented systems”. Or maybe it should have three values, adding “${silly, Swiss army knife scripting framework} for prototypes and impossible last minute projects”. Underlying all of this is (likely) Spring, Spring has become the de facto standard for plumbing in most applications, and this has helped to disaggregate web application frameworks from persistence layers and services. Because every framework must integrate with Spring, it has reduced the upfront investment costs associated with switch between different web frameworks - you can switch to Wicket or Tapestry easily because you can just wire up your existing code (hopefully). There is no “One True Way” (except emacs and Spring J )

Unfortunately, that’s not how this industry works, instead what we tend to produce are single minded partisans who latch on to the first thing they learn and then start flame wars on O’Reilly blogs. A blog post like this tends to produce a series of impassioned fights over how RSF is better than Wicket, and how someone “doesn’t appreciate my agenda”. (Go ahead, scroll down after a few weeks, and you’ll see them. They’ve probably read the first two paragraphs and then decided to respond by saying, “Tim, you are ignorant because you haven’t used RIFE, don’t you know that RIFE is the answer to Rails”…Yes, I’m very ignorant, thank you….and, No, I don’t have an agenda.)

These days, I’m using…

…Rails for the simple prototypes, Spring MVC for a more formalized MVC in Java, and Wicket for the serious AJAXy web interfaces. (…behind the scenes, Spring for everything…) Wicket has really proven itself to be a valuable framework given some time. At first I was convinced that it was code heavy, but after giving myself a few weeks to grok it, I’m sold on the approach. In Wicket, banging out a Flash Video widget or some script.aculo.us integration is easy once you’ve digested the essence of the framework. Both Rails and Wicket lend themselves to AJAX, and I’ve found that it is easier to create mega-AJAX complexity in Wicket than it is in Rails - even with RJS. That being said, the only way to really know Wicket was to follow the example, there’s a lot of documentation but until you see the code in action, it won’t make sense to you.

In Conclusion

Trumpeting Struts because “that’s what I’ll need to find my next job” is a specious argument at best (argument to spurious similarity). It is an appeal to common sense that assumes that because Struts 1 was such a success Struts 2 must be the logical next step. Also, assuming that Struts is going to be around for the ages because of some built-up conceptual inertia assumes that we operate in an industry full of incurious corporate drones. Yes, there are a lot of organizations who play follow-the-leader on risky architecture decisions, but, at the same time, the “leaders” aren’t necessarily putting weight behind Struts 2.

The sad truth is that Struts 1.x is going to be around like an undead zombie for a number of years. There are a number of organizations that are going to take one look at Struts 2 and wonder if it even makes sense to take the jump. In the one to two years it takes most of these organizations to come to grips with the fact that Struts 1.x is going to affect execution speed and developer retention, we’re going to see a continued period of innovation in the web application framework space, and, IMO, this is a great thing, and this isn’t necessarily a zero sum game. The Wicket project has this table of the various web framework options, and there are many. Plan to evaluate a new web framework once every year for the next two or three, and plan to implement real applications on two different frameworks simultaneously.

(I disagree with Paul on this one, but he’s usually dead on accurate) K