What Web Application framework should you use?
by Timothy M. O'Brien in Opinion
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 they haven’t really started to contemplate what comes next. Or, they’ve thought about what comes next, and the answer hasn’t revealed itself yet. JavaOne might have had the highest attendence on record, but the community is fractured and the energy is unfocused. The answer to “what web framework should we use” is far from clear. Read on, if you are interested in exploring this confusion…
Well, what Java web framework should I use?
*shrug*, beats me. All the revenue generating projects I’ve worked on 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 series convinced me that Java Server Faces does make some sense, but investing the time it takes to become an expert and train others in Faces still doesn’t sound like an efficient use of time. I anticipate that the path of least resistance for most is going to be the next version of the Struts Action Framework (read WebWork), but good luck trying to figure out 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 to discourage people from continuing to use it. The Struts team did the right thing in recognizing that Struts 1.x was a dead-end, but that project needs a single public message. Is it Struts Action or is it Struts Faces? Or is it two frameworks capitalizing on the Struts brand name?
Maybe the set of components being developed in MyFaces will convince me to go with Faces - Tomahawk and Tobago look like they could become promising component libraries. Rife looks interesting, but that’s about as far as I’m willing to play at the moment. Shale’s been around long enough, but I have yet to hear anyone tell me how great it was to work with. Then there is Seam, Seam is a reaction to Rails, and Fleury admits as much without really admitting it in this eWeek article. But, don’t let me leave out Stripes and Wicket. Or, how about Spring MVC, or Tapestry, or Turbine. Hey wait a minute why not use Cocoon. Or, how about sticking with Struts but using Strecks for Java 5 compatibility.
Confused yet? You should be. None of these options has emerged as the logical choice, they all have various advantages and disadvantages. Most of these frameworks have to work with the Spring framework in some way. Of course, they all have to support AJAX. Some of them are open-source/no-agenda and some of them are open-source/corporate-agenda projects. A lot of them are duplicative. Many of them have very vocal, high-profile consultant bloggers that produce a series of hype-driven press releases (sorry I mean blog entries). It is getting very difficult to identify the next logical step. (Hey, have you checked out Rails yet?)
Too many architects in the kitchen
…Struts 1.x will never go away.
An entrenched base of trained Struts developers coupled with this anarchy of open-source innovation translates to something of a stalemate. Even though it is widely acknowledged that Struts 1.x has some serious limitations, it is less risk for an organization to stick with what it knows. We’ve got “Corporate-sponsored Open Source” (read Marketing) hyping everything from JBoss Seam to Java Server Faces. The only real constant in this game is that Rails continues to set the bar higher and higher. The Republic of Rails has succeeded in focusing innovation on rails as a common web-delivery platform, and rails provides an active community and an easy way to extend via plugins. The Java web development community loses this game, and it responds by trying to make Java web development easier. Just when we think we’ve found a good web framework in Java that approximates the ease of Rails, something new comes out - like RJS templates, and seven Java architects jump to approximate its Ruby genius.
Java Developers Dabbling in Rails
Those few organizations that have decided to dabble in Ruby on Rails are quickly learning that it’s ease of implementation is intoxicating. I’ve spoken to many who work for organizations that have permanently sworn off Java for web application development forever in favor of Rails. But, on the other hand, I know more than a few organizations that are happy as can be with a very modular J2EE architecture and a web 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 to thousands of clients or maybe you are working on a system that utilizes some super-sophisticated grid computing platform that only has bindings to Java. My own experience is that Rails is a hands-down winner if a project is self-contained and limited in scope. The second it starts having to rely upon shared code or interface with an existing database schema, I jump for Java.
Rails is great, but sometimes you really do need to wield the heavy 3-tiered application architecture. Sometimes an organization benefits from the structure the J2EE provides (imposes). If anything, the great majority of Java web software projects are still using the (now ancient) Struts 1.x framework. Average Java web developer Joe Java, might just now be considering whether it makes sense to move to another framework. A minority of them have dabbled with Rails, some of those have 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 MyFaces in three years? Honestly, anything can happen, as Struts 1.x proved, it isn’t the best technology that wins, it is the one that people end up using. :-) But, I doubt it. Rails continues to improve and it has a core community that excels at communicating it’s compelling ease of use.
JRuby will mature, Rails will run on JRuby and there will be various plugins that expose something like Hibernate or some Spring managed fanciness as something similar to ActiveRecord. Think Rails on JRuby accessing some Spring-managed beans that provide the functionality of ActiveRecord over JDBC. This way we can stop arguing over who’s got the better ride and we can start making some real progress.
FROM::
http://www.oreillynet.com/onjava/blog/2006/06/isnt_rails_supposed_to_change.html
No comments:
Post a Comment