Rich Unger's Blog

April 2005 Archives

JavaONE deadline

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?

Examining Premises: why use a framework?

In working on my JavaONE presentation, I got to thinking about why frameworks such as the NetBeans Platform and Eclipse RCP are important. It's really because, if they didn't exist, we'd all end up rewriting them, anyway.

Every project I've ever worked on started out as a dedicated application, with a very simple architecture. Then, as features are added, and they don't fit nicely into what I already have, I have two choices:

1. I can do some rewriting, and just "get it working" in time for the release date. This results in buggy, hard to test code.

2. I can begin to modularize what I have, and create a pseudo-framework that can accept new components more easily without breaking what I already have.

The idea with these platforms is to start with the framework, and build out. Of course, the challenge there is to make the learning curve shallow enough that folks making initial versions of their dedicated applications won't blink at starting with them. When I first picked up netbeans (several years ago), the learning curve had Everest-like proportions. It's gotten a lot better, but I still have a few annoyances.

I think the declarative method for laying out components is very difficult to grok, and far too easy to break, especially when trying to create a singleton TopComponent. I've gotten very little traction from netbeans developers whenever I bring that up. After all, they just rewrote the darn thing.

The new projects system is a joy to work with on an API level, though. It's super easy for me to create my own flavor of project. Also, the way the Lookup mechanism works to provide context as the focus moves around to different components has a certain zen to it. It "just works".

And the new UI and tools for modules developers, which is slated for version 4.2 should go a long way towards lowering the barrier to entry.

The J2EE side of the aisle is way ahead of the desktop space when it comes to recognizing the value of a prebuilt framework. Web developers everywhere were building their own dialog management components, until Struts came along and gained a serious following.

Of course, the J2EE crowd went overboard. They're framework-happy! And, boy, am I confused. More on that in the next entry.

This work is licensed under a Creative Commons License.