Skip to main content

Straining the bath water (in search of lost babies)

Posted by johnreynolds on August 12, 2005 at 3:40 PM PDT
alt="John Reynolds">

Romain Guy's blog "Get to love web development" chronicles his growing love for the Wicket web component framework... and I must admit that I am very tempted to take the plunge... but my first reaction was to ask the obvious questions:

Why another Java web component framework?

Why not evolve (fix) one of the existing web component frameworks?

Tapestry's Howard Lewis Ship had a slightly different reaction:

"Wicket is looking to me like a mix of Tapestry and JSF. I've been giving a lot of thought to what a much better web framework would look like. Tapestry has the templates right (and everyone's been copying that) but internally, the component approach is too limited. I'm envisioning something closer to an AOP approach and may find time to work on a prototype someday."

Kudus to Howard for admitting that Tapestry isn't perfect... and for reminding all of us that "a much better web framework" is still a real possibility.

My cautionary note is that most innovations in web component frameworks seem to be throwing the baby out with the bathwater.

I'll explain what I think "the baby" is, but let me hasten to add that I don't want to single-out Wicket... the sounds of sloshing bath water are all around us.

One of the loudest noises is coming from the direction of Ruby on Rails. Everyone from Matt Raible to David Geary is lauding the power of Ruby on Rails.

Ruby on Rails sounds great... but they're not just throwing out the baby, they are throwing away the tub. Do we really have to flush Java down the drain to make web development "fun again"? (The folks on the Grails and Trails projects seem to be enjoying themselves.)

But I digress... What I really want to talk about is web components.

It's the Web Components (stupid)!

In his book Democratizing Innovation, Eric Von Hippel stresses that users want solutions that exactly meet their own needs (that's why Wicket and Ruby on Rails were created). Users needs are never exactly the same, so there is always going to be an incentive to innovate.

In the domain of Java web component frameworks, user innovation has resulted in (at least):

Each of these frameworks has some very nifty features, and each innovator "threw out some bath water" to realize their visions.

Unfortunately the innovators also threw out whole libraries of pre-existing web components. You can't use an Echo component in a Tapestry application. You can't use a Tapestry component in a JSF application. You can't use a JSF component in a Wicket application.

To be fair... with the exception of JSF, none of the web component frameworks set out to define standards for the web components themselves, and in many cases these frameworks were developed during overlapping time frames.

Innovation is a great thing, but the continuing innovation in Java web component frameworks is somewhat stifling innovation in Java web components (and in tool support for component based programming).

Consider AJAX as an example:

Google and a new acronym made AJAX sexy this year, and now every web component framework that I am familiar with is scrambling to support its features.

The problem (for web component innovation) is that proponents of each framework are building "the same" AJAXian components. We're seeing some innovation, but mostly we're seeing a lot of duplication (tables, trees, etc.). Worse (from my perspective) we aren't seeing significant tool support for developing JavaXIANTM web components (components with client-side JavaScript and server-side Java).

Fortunately, there are great plans and repositories for client-side AJAXian JavaScript, and no doubt many JSF, Tapestry and Wicket components are (unknowingly) sharing the same client-side JavaScript. It's the duplication of the server-side code that's a waste. As Michael Jouravlev points out in his article Building Web Components Without a Component Framework, components have a pretty clear set of responsibilities that are distinct from the application framework in which they are embedded.


Related Topics >>