Now take that a step further, where you find a restaurant that you're really impressed with. You had their Chateau Briand and loved it the last time you were there. You walk in with your mates, sit down, and look for the Chateau Briand on their menu, and it's not there. So you ask the waiter:
"Erm, what happened to your Chateau Briand?"This morning I had a 'debate' online with a mate of mine, Chris Miller. He's an annoyingly smart developer who more often than not wins these little debates we have. I posit, he counter-posits, I counter-counter posit, and he slam-dunk posits, and then I end up sobbing in the corner. Okay, I digress. The point is I was bitching and moaning about the constantly changing landscape that is Java Web Frameworks. The huge proliferation of Yet Another Web Framework's that is out there in the Java web space. I haven't done Java web development for quite some time now, and recently have returned to the web space because of a personal project I want to explore. I refer you to my recent posts while hitching a ride on the Grails bandwagon.
Waiter: "Oh we don't offer that anymore, but now we have this really scrumptuous Carpet Bagger steak!"
You: "But I really liked the Chateau Briand, what was wrong with it?"
Waiter: "Oh nothing but the chef got tired of making that. He felt it was becoming passé and wasn't sexy enough anymore, so he stopped preparing that. But he's now really plugging his CarpetBagger steak!"
The last time I did a Java web application, I chose Webwork v1.x as my preferred Java web framework. Webwork was a great framework. A very unimposing, yet powerful framework, true to the intelligence that is Rickard Öberg, the initial developer of Webwork, before it entered the OpenSymphony suite of frameworks. I enjoyed developing with Webwork as it allowed me to focus on the business features I was trying to implement without imposing any configuration distraction, or "square-peg-in-round-hole" forcing. There were a number of really smart individuals who had a hand in Webwork development, like Mike Cannon-Brookes, Hani Suleiman and Joseph Ottinger.
Then one day, a guy by the name of Patrick Lightbody had some or other epiphany and decided that Webwork needed a complete rewrite, basically, and he started on a journey that became Webwork 2. Development on Webwork 1 ceased. Hani made a valiant effort to try to migrate some new (and admittedly useful) functionality from Webwork 2, back to Webwork 1, but he had to work to pay for all that Mac machinery he owns, and so Webwork 1.x development basically ground to a halt. A year or two later and what do we have again? Oh look, Webwork 2 and Struts are merging to become Struts 2. Imagine my surprise. Why? What was wrong with Webwork 2? It's almost like these guys just get bored and decide to rewrite stuff.
Chris (Miller) argued with me that this was irrelevant. That there was nothing wrong with Webwork 1.x that should have caused me to have to upgrade to Webwork 2, other than if I was simply trying to remain 'trendy'. Now as somebody who doesn't get out much, 'trendy' isn't a moniker I would use for myself, and it's not something I attempt to accomplish. However, as I indicated, there were features which Webwork 2 had, which would have been useful in Webwork 1. Off the top of my head, I offered 'interceptors' to Chris, as an example. So you either stick with Webwork 1 and look enviously at all those using a better way to do what you're doing, or you upgrade (probably yet again!) or you enhance Webwork 1 yourself (which I'm not sure if I'm smart enough to do, and I don't have the time). Chris contended that despite the noise that exists in the Java landscape, it's usually easy enough to sift out the wheat from the chaff and if you just focus on the small handful of wheat, you can stick with one choice for a long time before you might have any need to do the upgrade dance. This is true, though often the most-used framework is not always the best framework. Struts 1.x is testament to that.
I guess for me, the issue is the sense that there are so many smart developers out there, giving of their intelligence and time, that it's a pity there isn't more cohesion amongst them. Is it ego's that clash? Disagreements that lead to feuds which lead to divergent frameworks? It seems like there's so much time wasted because of differences of opinion, that lead to reinventions of the wheel. These reinventions mean the rest of us who use these frameworks do a lot of tail-chasing.
I guess beggars can't be choosers, and if I'm not going to contribute in some meaningful way to these frameworks, then I can't complain. Put up or shut up. True, I can't argue with that. But from an objective perspective, it's still a pity. Take for example the Java workflow space. Here's a post from Carlos Perez's Manageability blog. Just look at that proliferation! I count 40, yes, 40, different Java workflow frameworks. I mean, surely there's enough commonality in the workflow space that we don't need 40 frameworks. Is it bad co-ordination? Poor communication? What is it?
Well I don't really know, but it's annoying, and it's a pity. And furthermore there's really precious little you can do about it. Open source is a voluntary beast, so you can hardly go around dictating to developers as to what they should do with their spare time.
If you've read any of my earlier posts you will have seen that I've jumped onto the Grails bandwagon. I just really hope and pray that Grails sustains the attention of the developer community sufficiently to remain relevant for a long long time. If not, it'll be a bit of a gamble since Grails applications, by their very nature, are significantly different to most other Java web frameworks, and web development methodologies.
Postscript: The one fairly important aspect I've completely omitted here is what we get from those who are somewhat at the reins in our industry. Consider, for example, Java Server Faces (JSF). I must admit to not having played with JSF at all. However, I can't say I've found a single positive comment on JSF by those not specifically biased due to their involvement in the JSF effort. The overwhelming consensus that I have picked up on is that people feel that JSF ignores what Java developers actually asked for. That it's delivery was grossly impotent when considering its potential and initial promise. EJB is another example. Look at EJB 1.x and 2.x. Yick! EJB3 seems to finally be getting somewhere close to what Java developers have wanted all along. So does this suggest part of the problem: that the leaders in the Java space are too introspective, and they don't actually listen to what their developer masses are asking for? How long did developers complain about the lack of exclusion patterns in the servlet specification? So perhaps our fearless leaders have some blame to bear in this mess that is the Java web framework landscape.
No comments:
Post a Comment