Rich Unger's Blog

More Frameworks Than it Would Be Wise to Shake a Stick At

I'm a client-side guy, but my customers use my stuff to make webapps. So, I figured I'd check out the landscape they're facing when architecting their solutions.

Beehive
Cocooon
Echo
EJB
Hibernate
iBatis
JDO
JSF
Keel
Maverick
SiteMesh
Spring
Struts
Tapestry
Tiles
Velocity
WebWork
WebObjects
Wicket

Whoa. And I'm sure I'm just scratching the surface.

I suppose it's an indication of just how awry the JSR process has gone in this instance, that so many people felt the need to reinvent the wheel.

Now, I know I'm not the first person to blog about this. Everyone over at theserverside.com shares my frustration at the proliferation of frameworks, all while extolling the virtues of their preferred solution.

In my last entry, I convinced myself that frameworks can be a good thing, so long as the barrier to entry is low enough. Not exactly rocket science, but there's still a lot of folks out there who don't agree with this. They feel that it's just a lot of complexity they won't need. That's not an argument to be dismissed out of hand, especially given how much time you can kill just trying to pick out the "right" J2EE architecture.

It's a barrier to entry, because now I have to learn a bit about all of them to select the best one.

But that's not even the end of the story. And, here's where my real confusion comes in. Evidently, you can mix and match!

People are building Spring/Hibernate/Tapestry solutions, Spring/JDO solutions, Tapestry/Hibernate solutions, and Spring/Struts solutions (this one really mystifies me, as I thought they were direct competitors in every respect). Then there's this "appFuse" thing that I can't rightly figure out, but it seems to be a giant conflation of everything at once.

Basically, you can pick any 2 or 3 things from the list above, and somebody's got a website running them in concert.

Let's run through an example.

Coming from a swing background, the component based model of Tapestry is very appealing to me. I grok the way the "model" and "view" interact there. I'm not so sure where the "controller" fits in (maybe somebody could explain that to me in the comments?)

Anyway, there are some very nice tutorials out there explaining how to create an entire web application using only Tapestry, and maybe something to abstract the DB away, like Hibernate or JDO.

But, the folks at Spring seem to take it for granted that Tapestry is something best relegated to the UI layer. Spring should be handling the object relational mapping in the Spring ORM package (which, itself, wraps Hibernate, iBatis, and/or JDO).

What's the value-add here, and is it worth the added complexity?

Now, I started with Tapestry and worked my way out from there, but I could have just as easily started with Spring and wondered at the advantages of adding Struts to the mix. Or many other ways.

I really want to know. I don't have the benefit of having struggled through creating a webapp myself. Perhaps the impetus is obvious to anyone who has. What's wrong with picking one framework for one project? Why put yourself through more complexity than that?

Comments

• IMO, the ones that are supported in AppFuse are worth looking at. ;-)

  The others might be good, but there's not much of a market for them (as a consultant looking for gigs). From your list, this narrows it to:

  Hibernate
  iBATIS
  JSF
  SiteMesh
  Spring
  Struts
  Tapestry
  WebWork

  
  Web frameworks are often a matter of personal taste (or familiarity), but some do things better than others. The number of books written about a framework is often a testament to its usefulness too. The thing I like most about Spring is it makes programming J2EE webapps easy and gives you declarative transactions and easy de-coupling between layers. In essence, it enforces a lot of J2EE patterns and makes it easy to write to them.

  Posted by: mraible on April 09, 2005 at 01:23 PM

• I am sure each of these frameworks has some merit, for its particular purpose; but from my somewhat storied experience, I attribute their number to one thing: frustration.

  Web-apps are, in my perspecrtive, a bit like trying to create the telephone, using telegraph technology. I.e. it would seem to be a natural extension at first glance, however the underlying design cannot ultimately support it.

  Often, in the rush to innovate, the herd charges off in unfeasible directions. It just takes a while for the inevitable realisation to set in. For example, computers where built using vacuum tubes quite a long time after the invention of the transistor, in '47. (And you think you have frustrations now! ;-)

  Invariably, the ones who chose not to run at these particular times are not left behind, but in fact, are free to discover the successful ways.

  Your questions are very incisive, stick with them!

  Posted by: cajo on April 09, 2005 at 01:42 PM

• Well, as one of the developers of Wicket, I have to disagree with Matt. But then again, I'm a developer, not a consultant (though I might hire consultants ;) ).

  Anyway, though there are a lot of frameworks for web development, a lot of them relics of the past, part of a collective learning experience. We (at least I) had to go through the JSP/webmarco/velocity, Model 2 AKA 'Web MVC' (Struts, Maverick) thing to found out that you really *need* to have a component oriented application framework in order to build large, complex web applications (though the model 2 frameworks are still fine for not-too complex stuff).

  And then frameworks like Spring etc. They 'spring' from J2EE being too complex in the first case. I co-developed large scale applications without J2EE, and am still happy about not adding that extra layer of complexity on those projects. I guess Spring (or something similar) can be helpfull at times. On the other hand... I developed an IoC like framework two years ago for in-company use, and have seen it used on several large projects. I hate it now! All that XML configuration seldom really adds much (unless you depend heavily on the strategy pattern), but what I really think is bad is that it doesn't encourage developers to 'think OO'. Rather, with that kind of frameworks, they tend to put everything in functional modules with methods like 'doXXX', 'calculateXXX' etc. The same 'bad OO learning' argument goes for the model 2 frameworks IMHO.

  So, looking for a frameworks? Look at what you really need. If you're unsure, just defer the decission until you actually have a use case.

  And as for choosing a web development framework, I would go for Wicket, Echo, Tapestry or JSF, depending on your team, your 'consultant' needs and tooling (personally I would use JSF *only* with drag 'n drop tools, and only for projects that lend themselves for drag 'n drop).

  Eelco Hillenius

  Posted by: eelco12 on April 09, 2005 at 03:26 PM

• 
  The majority of these frameworks exist to solve different problems. Hibernate and iBATIS are data access technologies. Struts and Tapestry are web-tier frameworks (they do NOT address any middle tier or persistence issues.) Spring is a end-to-end application framework that unites many of these disparate technologies through a common configuration and programming model. Spring addresses the whole stack from UI, to middle-tier, to data access, but it doesn't do it alone: it does it by integrating a lot of what you see above--and in many cases, makes using all of the above much easier (in general by masking complexity, but still giving you the power of the underlying tool if you need it.)

  
  So there is some competition here yes, but there is a lot more compliment.

  
  The reason why Spring is so popular is because it takes this massive number of frameworks and integrates them into a smart, unified application framework with a consistent usage model. In that respect you get the best of both worlds--you can leverage specialized frameworks/libraries that are really focused and good at what they do, while ensuring these disparate technologies are integrated consistently into a end-to-end "use what you need" solution (Spring) that makes it a lot easier to mix and match (it does the hard work for you.)

  
  Cheers,

  Keith

  Posted by: kdonald on April 09, 2005 at 05:36 PM

• Yes, I understand what the individual frameworks do. My main confusion was why there are 2 seemingly large camps: one who believes that a component library (like tapestry) is a complement to a "middle-tier" framework like spring, and another who believes it's a replacement. How can it be both? Is there a continuum with a tradeoff here I'm not aware of?

  Also, why the heck are people using spring and struts in a complementary fashion? There simply must be a trick I'm missing, because to me that sounds like using SWT and swing in combination. Doable, but a whole lot of complexity for absolutely no gain.

  And, just to play devil's advocate to your description of Spring, is there also case to be made that having yet another framework to tie together existing frameworks just adds more complexity? Why do I need Spring's ORM module to provide a buffer layer between me and my object mapping framework, which is itself a buffer between me and my database?

  I'm not trying to be contrary. I'm asking as someone with some experience in frameworks outside of the J2EE world, looking seriously at all this stuff for the first time. From a fresh perspective, it just looks like combinatorial madness.

  Posted by: richunger on April 10, 2005 at 01:05 AM

• I wonder when they will discover the superior technology of servlets?

  Posted by: rickcarson on April 11, 2005 at 06:39 AM

• Here's my 2 cents worth of clairvoyance...

  JSF will win as the presentation layer due to vendor support. An HTML template "version" of JSF (ala Tapestry) will gain wide popularity for those who don't care for JSPs. A significant number of JSF components will be implemented to provide AJaX features.

  Shale (a.k.a. StrutsShale) will become the de-facto middleware layer because it is unabashedly taking everything good from Spring, Webworks, Tapestry (you name it) and it will undoubtably provide server-side support for AJaX from day one.

  The EJB3 "Entity manager" will supercede Hibernate et. al. as the preferred ORM/Database layer.

  All of the above will be packaged together by IDEs such as Sun Studio Creator to give the developer a "VB-like" environment. Folks will be able to mix-and-match if they want to, but there really won't be a good reason to do so, and we'll move on to solving bigger-and-better problems.

  Posted by: johnreynolds on April 11, 2005 at 07:27 AM

• I agree it's very difficult, especially for the casual developer, to learn enough about all the different frameworks to figure out which ones are best suited to their needs and taste. Couple that with the typical lack of current documentation that most open source projects have, and even the comparisons can be difficult to follow! It can be fun to find the right framework, but an exercise in futility to find the One True Framework[tm] that fits all apps.

  I've read up on several web frameworks, and am "least disappointed" with the following strategy:

  Analyze problem to build domain model
  Build schema from domain model
  Use middlegen (et al) to generate Hibernate objects from schema. (I love this tool!)
  Use Spring to tie together business logic components (This shrinks or grows a lot depending on what's needed)
  Use Spring web stuff (optional part of Spring) to control web layer (I used to be a Struts fan, but Spring's web stuff is more to my taste.)
  Use commons-validation for client-side form validation. (Clunky, but I haven't found anything better, at least in my price range!)

  For most of my apps, business logic has been fairly light, so getting the schema right and easy to work with has been the biggest savings. That said, something like Spring really simplifies unit testing, especially when compared to networks of Singletons or EJBs.

  
  Tapestry and JSF have their own strengths and weaknesses, but aren't for me. Tapestry borrows a lot from ASP, but hides too much for me to feel in control. Some of the syntax is downright mystifying and unexplained, even in the one Tapestry book I have read. JSF is really just a refinement on Struts, but is still a bit XML-heavy and disjoint for me to feel the "flow" of the app. I might like it if I actually worked with it more, but it's too easy to jump to a framework that fits my style of thinking.

  In the end, the variety of frameworks is probably exactly the kind of unbounded creativity that J2EE needs so that good solutions can be found and cross-pollinated. Look at EJBs now: the spec intended a simple and easy-to-distribute model of self-contained beans. The reality is very much the opposite unless you shell out for serious commercial tools, and even then only works by hiding an awful lot from the programmers. EJB 3 will fix some of this by adopting Hibernate's persistence strategies, but there's still plenty of room for improvement in there. People experimenting with other frameworks may very well lead us to a One True Framework[tm] for J2EE after all.

  Posted by: tomwitmer on April 11, 2005 at 11:27 AM

• Rich, I'm at least partly with you on this. It is most definitely a pain to sort through all the possible frameworks (or at least the most popular, of which there are many) and learn them well enough to decide which ones to use. I also agree that the overlap is getting out of hand. Some frameworks trying to work on all layer levels, and while their core functionality is great the other stuff is only ok at best. The same problems are going on with all the flavors of UNIX and even the Gnome/KDE debate. IMO there's not enough cooperation out there and too many folks are writing their own stuff instead of making the better ones even better. It would be nice for us plebes to have everything cut and dried, but it's not going to happen any time soon.

  I'll back up Matt, though, and say that the stuff AppFuse works with is probably the best short list folks should use. He's got a lot of experience with them and their quirks and knows how to integrate them into a working whole. I'd like to see more folks working with Matt to come up with a good FAQ or decision matrix or "interview" flowchart or something like that to help folks understand the strenghths/quirks of the various frameworks and which ones would be best in certain situations. A decision tool like that would help the community tremendously. My guess would be that it would also encourage framework developers to address and fix their quirks/bugs/deficiencies.

  But of course, in the end, we should certainly not fault anyone for trying to come up with a better solution. We should only fault them if they keep saying year after year that it's better when it's really not. :-)

  Posted by: gerryg on April 12, 2005 at 09:41 AM

• Either java.net blogs doesn't support trackbacks, or I did it wrong. At any rate, I thought I'd mention the response I posted in my own blog. The synopsis: Rich's amazement at the number of web view frameworks is not unfounded, but I think he's confusing web view frameworks and web application frameworks.

  Posted by: shaug on April 12, 2005 at 11:51 AM

This work is licensed under a Creative Commons License.