Skip to main content

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

Posted by richunger on April 9, 2005 at 11:21 AM PDT

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?