I made a little progress this week in my play project that aims to do something interesting with freedb and Rails.

So I was just thinking, as I threw together a simple webapp in 30 minutes last night, how easy it would be to rewrite the the user facing side of my work’s Web site (the read only pages, anyway) in Rails. It would be cake. I’m cheerfully working on rewriting much of our administration site in Wicket, enjoying all the benefits of a component programming, but also seeing how inappropriate its heavy-duty abstraction is for simple content display. The session overhead is excessive for a high volume site, and the URL issues will never be solved. (The URL can’t contain all the information needed to render a page when most of your state is on the server.)

Then today I came across this O’Reilly article trying to make sense of the whole Rails disruption. James Duncan Davidson’s comments resonated the most with me:

And I think that’s the real win from the recent attention on Ruby on Rails and the breakaway from viewing the world with Java-colored glasses. It’s not that Ruby on Rails is going to be the next Java. Far from it. It’s that Ruby on Rails helps to break this idea that there is “One True Way.” There’s not. There are many different ways to solve a problem. And really, none of them is the clear-cut winner. There’s just places where one solution has advantages.

Indeed, that’s the Java dogmatism that has driven me to rail against tiers. So, I like this guy, but here’s where I disagree:

The strengths of Java could be applied to a brand new framework in interesting and amazing ways. It’s just that nobody has done that yet.

I think Wicket is that framework, the one that takes advantage of Java’s strengths and makes all the cartwheels we have to turn for the language worthwhile. Web components that render themselves, profit from inheritence, and don’t die at the end of the request cycle are done brilliantly in Wicket. Maybe Davidson just hasn’t tried it yet.

So where does this all lead? The O’Reilly panel mostly dodges the question, or maintains that “the enterprise” will still be better off with Java. Some answer! It’s not the size of the company that determines the best technology to use—it’s the application you’re building. Use Ruby for one and Java for another. (If Java programmers could drop their fetish for “e,” they might be able to think more clearly.)

For high volume sites with working URLs, you need a stateless framework. Java has always been a bad choice for a stateless framework (Struts, please die) because there’s little payoff for the object palace you’re required to build your apps in. In days past the best bet was PHP, but Ruby on Rails is the clear winner now: it’s practical object orientation.

On the other hand, if you’re supporting a limited number of users in a fairly complicated system that you want to work like a desktop application, then you can benefit from a stateful framework. Go ahead pour a few hours into this or that component, because it won’t have packed up and left you 1, 2, or 3 requests later. Java + Wicket is the best thing going in this department.

Two classes of frameworks, and two front-runners. You can learn both, or you can just be a fanboy.