re: Struts 2 is the New Mini

by Tim O'Brien

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...


7 Comments

Tom
2006-12-22 08:02:34
Eventually, Rails is going to be an option on the JVM (whether you like it or not)

Or try Grails if you want RAD in your app container that will interact with your legacy code right now.
Paul Browne - Technology in plain English
2006-12-22 08:16:30
Tim,


Good response , including the turning around of the car examples to prove exactly the opposite of my argument - ouch :-)


You're correct in that people should be aware of the various web framework alternatives. Maybe it's a case of 'too-many-web-frameworks-too-little-time' , so the way I (maybe unfairly) cut the numbers down is the mercenary 'use in next job' test. At a purely technical level, there is little in your analysis that I can disagree with.


Now , if you're in a position to dictate / choose the web framework on your next project / job - great. (Un)Fortunately as Java matures and more and more projects become 'adapt this existing system' instead of 'build something new', the opportunities will become fewer. Taking this to it's extreme , it means us Java guys are the Cobol guys of the future - a true if slightly depressing thought if you've enjoyed the buzz around Java for the last couple of years.


Paul


Will
2006-12-22 11:53:35
Actually, I don't care much for the car analogy simply because it's not relevant. You're stuck with your 1999 Camry no matter what Toyota does. It's not like you can gradually upgrade to a 2007. Rather you have to replace the whole thing.


So, there goes all the window tinting, the custom stereo system, the aftermarket spoiler on the back and the flames your Cousin Fred painted on the fenders. The fuzzy dice tends to be a portable upgrade option, but beyond that, it's a complete rewrite when you upgrade to the new Camry.


The other point is that the interface to a new Camry may well be the same as the old Camry, but so is the interface to most every other car on the market (save the BMW 7 series with its wacky computer controller knob). So, Camry, Altima, Maxima, Accords, whatever...pretty much a wash (based on the fuzzy dice compatibility index no doubt, but that's always been hard to quantify). You could pick any one you like.


Now, if we're talking left hand drive, standard vs automatic, etc. then, sure, there's a bit of a learning curve as you go from an old model to a new model, but since you're a skilled driver, you're going to adapt fairly quickly as the environment that you drive in is not dramatically different. The functions you need to perform are the same: stop, (always learn stop first), go, left, right, park, swerve, tune the radio, etc.


Same with web frameworks. Any skilled web Java programmer should be able to pick up any other framework reasonably readily. Particularly if there are others available to ask questions of, or if there is working source code with good idioms and examples.


If you're a Struts Expert and asked to take on a position of designing a JSF project from scratch, you're probably not a good fit. But if you're a Struts Expert and asked to join a JSF project in progress, that's a completely different story, and a Struts guy is probably more than capable of filling that position.


So, I wouldn't get hung up on the frameworks so much. Pick one(s) you like, work with them, and master their idioms. Keep the fundamentals in mind (it IS, after all, an HTTP Request to a servlet at the core, no matter what), and master that relationship from HTTP request to the framework. Then, just worry about application design and all of the other issues that crop up with systems unrelated to the frameworks at all.


That is what makes you a better Java Web programmer, IMHO.


(P.S. What do I know about Camry's, I ride a motorcycle...;-))

Steve
2006-12-23 13:16:44
No question - lots of viable options in Java Web Frameworks, including dynamic scripting Web frameworks.


Grails, JRuby (on Rails), JSF, MyFaces, Stripes, Struts 1.2.x/Streck, Struts Action Framework 2, Wicket, RIFE, Tapestry, and on and on and on...


It's good to have choices. And Java gives us that. In theory due to Java SE 6 scripting support on JVM beyond Java, PHP (on Rails) solutions may be of interest, Python (Django, TurboGears), etc.

Kevin Galligan
2006-12-30 15:01:52
I'm excited about JSF. I wasn't at first, and I wouldn't let a junior person use it without a lot of hand holding, but once you get it, you get it. Actually, I'm excited about Facelets and JSF, not so much the regular jsp version.


Struts does seem a lot like "Old Gill's" framework of choice (Simpsons reference). I miss it like I miss Nintendo and my Motorola v-60. I haven't spent any time on struts 2.


I do plan to take a look at Wicket and Tapestry, but to be honest, I think the "next job" argument shouldn't be completely ignored. I did a quick search on dice. Tapestry came back with 83, jsf 456 ('server faces' 390), struts 2073. Wicket? 6. I'm sure Wicket is great, but its been viable for about 2 years. 6 jobs. Even facelets came back with 19, and right now facelets is fairly obscure (and, unfortunately, will probably stay fairly obscure).


I guess I'd need to better understand the details of the different frameworks, but it seems like there are way too many of them. IMnsHO, Progress would be better served if, say, the wicket folks put their efforts whole hog into Tapestry enhancement, you know what I mean? Then you get the effort (development, design, testing) of the regular Tapestry people, plus probably some sweet add-ons and better design from the people who don't think Tapestry is perfect as-is. Then you also get serious momentum. I understand why the open source world would be less interested in JSF enhancement (although, I think JSF gets a much worse shake than it deserves), but why a whole new framework? On top of all of this, people tend to forget that a quality editor makes a difference. New frameworks require new editor integration, etc. Plus, corporate IT departments are going to consider that its going to be a lot harder to find a Wicket coder than a JSF coder (or struts coder, etc). That probably wouldn't be true, as there are many more people using Wicket because its cool than there are jobs to give those people, but you can bet few corporate-minded folk would take that gamble (longevity, support, training, etc).


I don't think I'll ever get the rails thing. I would assume that one could build a similar framework in the java language, so if you're doing mockups, you might be able to reuse at least some of the business logic that was flushed out during the mockup phase. A simpler framework? Sure. Different language? Hmm, not so sold on it. I read this...


http://www.ruby-lang.org/en/documentation/ruby-from-other-languages/to-ruby-from-java/


which seems to say that ruby's main benefit, besides personal preferences (brackets vs no brackets, etc) is less code. I guess I don't get it. How, exactly? That to me is an emperor's new clothes statement if I've ever seen one. You might have less lines, and you might abstract more out of the box (or not get all worked up about strict type conversions), but you're not really "working" less. You don't wind up with less logic definition, which is what a programmer does. In fact, I'd like to see statistics on code completion vs. full typing of a statement. I'd say at least half of my coding involves CTRL+Space. You can't really get code completion without types, right? You also need to run your tests to see that you might have a problem. When I code java, I see that right in the editor. Vague variable typing reminds me of javascript. If you want to find something that most developers aren't excited about, I'd put that up there next to Basic and Cobol. On top of all of that, you need to go back and re-code the huge body of work that exists for the other languages. DB drivers, common code libraries, etc. I will say Microsoft's plan with the CLI (after years of bashing Java's VM), takes a big step in the right direction.


FYI 183 dice jobs for 'rails'. 1212 'php', 7814 '.net', and 14536 for plain 'java'.


2007-07-12 23:24:11
what is the control flow in a jsf framework
Antony Stubbs
2007-09-06 17:00:02
Don't forget about Grails.
@Kevin Galligan - Grails is like Rails for Java, and uses Hibernate and Spring etc...