What Web Application framework should you use?

What Web Application framework should you use?
Monday June 19, 2006 7:45AM
byTimothy M. O‘Brien inOpinion
Not excited about any Java web application framework these days?Join the club. The reality few want to acknowledge is that many“enterprises” are running along with Struts 1.x applications and theyhaven’t really started to contemplate what comes next. Or, they’vethought about what comes next, and the answer hasn’t revealed itselfyet. JavaOne might have had the highest attendence on record, but thecommunity is fractured and the energy is unfocused. The answer to “whatweb framework should we use” is far from clear. Read on, if you areinterested in exploring this confusion…
Well, what Java web framework should I use?
*shrug*, beats me. All the revenue generating projects I’ve workedon in the past few years are all still chugging along on Struts 1.2,and there is little reason to upgrade at this point. Sure,Rick Hightower’s Developerworks seriesconvinced me that Java Server Faces does make some sense, but investingthe time it takes to become an expert and train others in Faces stilldoesn’t sound like an efficient use of time. I anticipate that the pathof least resistance for most is going to be the next version of theStruts Action Framework (read WebWork), but good luck trying to figureout what is happening over at the Struts project. Is it Struts Ti,Struts Titanium, Struts Action 2……err…why not just call it WebWork? Prediction:The confusion over what is happening over at Struts is going todiscourage people from continuing to use it. The Struts team did theright thing in recognizing that Struts 1.x was a dead-end, but thatproject needs a single public message. Is it Struts Action or is itStruts Faces? Or is it two frameworks capitalizing on the Struts brandname?
Maybe the set of components being developed inMyFaces will convince me to go with Faces -Tomahawk andTobago look like they could become promising component libraries.Rifelooks interesting, but that’s about as far as I’m willing to play atthe moment. Shale’s been around long enough, but I have yet to hearanyone tell me how great it was to work with. Then there isSeam, Seam is a reaction to Rails, andFleury admits as much without really admitting it in this eWeek article. But, don’t let me leave outStripes andWicket. Or, how aboutSpring MVC, orTapestry, orTurbine. Hey wait a minute why not useCocoon. Or, how about sticking with Struts but using Strecks for Java 5 compatibility.
Confused yet? You should be. None of these options has emerged asthe logical choice, they all have various advantages and disadvantages.Most of these frameworks have to work with the Spring framework in someway. Of course, they all have to support AJAX. Some of them areopen-source/no-agenda and some of them are open-source/corporate-agendaprojects. A lot of them are duplicative. Many of them have very vocal,high-profile consultant bloggers that produce a series of hype-drivenpress releases (sorry I mean blog entries). It is getting verydifficult to identify the next logical step. (Hey, have you checked outRails yet?)
Too many architects in the kitchen
…Struts 1.x will never go away.
An entrenched base of trained Struts developers coupled with thisanarchy of open-source innovation translates to something of astalemate. Even though it is widely acknowledged that Struts 1.x hassome serious limitations, it is less risk for an organization to stickwith what it knows. We’ve got “Corporate-sponsored Open Source” (readMarketing) hyping everything from JBoss Seam to Java Server Faces. Theonly real constant in this game is that Rails continues to set the barhigher and higher. The Republic of Rails has succeeded in focusinginnovation on rails as a common web-delivery platform, and railsprovides an active community and an easy way to extend via plugins. TheJava web development community loses this game, and it responds bytrying to make Java web development easier. Just when we think we’vefound a good web framework in Java that approximates the ease of Rails,something new comes out - like RJS templates, and seven Java architectsjump to approximate its Ruby genius.
Java Developers Dabbling in Rails
Those few organizations that have decided to dabble in Ruby on Railsare quickly learning that it’s ease of implementation is intoxicating.I’ve spoken to many who work for organizations that have permanentlysworn off Java for web application development forever in favor ofRails. But, on the other hand, I know more than a few organizationsthat are happy as can be with a very modular J2EE architecture and aweb delivery stack that consists of some old Struts 1.x applications.Rails is perfect for some projects, but isn’t appropriate for others.Maybe it is an elearning system that needs to be distributed tothousands of clients or maybe you are working on a system that utilizessome super-sophisticated grid computing platform that only has bindingsto Java. My own experience is that Rails is a hands-down winner if aproject is self-contained and limited in scope. The second it startshaving to rely upon shared code or interface with an existing databaseschema, I jump for Java.
Rails is great, but sometimes you really do need to wield the heavy3-tiered application architecture. Sometimes an organization benefitsfrom the structure the J2EE provides (imposes). If anything, the greatmajority of Java web software projects are still using the (nowancient) Struts 1.x framework. Average Java web developer Joe Java,might just now be considering whether it makes sense to move to anotherframework. A minority of them have dabbled with Rails, some of thosehave been convinced by it, but Javaland is still waiting.
Future == Integrating Rails and Java
Maybe a winner will emerge, maybe we’ll all be using Seam or MyFacesin three years? Honestly, anything can happen, as Struts 1.x proved, itisn’t the best technology that wins, it is the one that people end upusing. :-) But, I doubt it. Rails continues to improve and it has acore community that excels at communicating it’s compelling ease of use.
JRuby will mature, Rails will run on JRuby and there will be variousplugins that expose something like Hibernate or some Spring managedfanciness as something similar to ActiveRecord. Think Rails on JRubyaccessing some Spring-managed beans that provide the functionality ofActiveRecord over JDBC. This way we can stop arguing over who’s got thebetter ride and we can start making some real progress.