I’ve been seeing the hoopla hoopla revolving around WebWork 2.0 and Struts (and even WebWork 1.x) the last couple of weeks. I’ve been laying pretty low, not getting involved. I did this mostly because after trying very hard for some time, I realize that there is no way to convince someone that X is better that Y with text words over the internet. The only true way to do it is to do what Kris Thompson is doing — try ‘em all. Of course, some of us like to sleep as well
Here’s my opinion on the whole thing (if anyone cares). As the primary force behind the original 1.3 codebase that eventually tured in to XWork and WebWork 2.0, I do believe there are problems with Struts and WebWork 1.3. I mean, why would I spend all this time if I didn’t? However, I also believe that frameworks in general need to provide zero (or very very close to zero) need to “work around the framework”.
I use Struts daily at work. Maybe this will change, maybe it won’t. I used WebWork 0.92 all the way up to 1.3 and beyond. I used and continue to use WebWork 2.0 for various projects. What I’ve found is that so far, I’ve found myself providing work-arounds for Struts and WebWork 1.3, but not for 2.0. Does that mean 2.0 is perfect and the others suck? No. That means that 2.0 works well for the way I build webapps and the others didn’t quite fit. Others may find the exact opposite is true.
My point is that this whole debate seems rather pointless. One cannot possibly prove that “X is better than Y”, especially not over blogs or wikis or email. I’d rather all that energy was spent writing documentation or improving the projects.
Recently WebWork 1.3 development started up again (thanks Hani!). In a way I wish it hadn’t, since it further complicates that already disasterous OpenSymphony space. But it does says something: there is a desire, strong enough to cause Hani to actually do something about it, to see a released product supported. Struts is also a released product. WebWork 2.0 is not, and will continue to be until Jason and I finish up the last 1% of open issues, write docs, and in general make the cost to use the framework as small as possible.
I expect that to happen in 3 weeks from now. I’ve been waiting on an Ognl release to put out 2.0 beta 2 for weeks now. It appears that Ognl has lost it’s zest it once had, which is now affecting WebWork. With that said, rather than continue to wait, I’ll either fork Ognl and ship with a modified version, or I’ll grab the EL from 1.3 and give it some upgrades. Regardless, I won’t be waiting around any longer.
The work on 1.3 has me excited and worried at the same time. It’s great to see people interested in the product, but I don’t want there to be a branch in two seperate directions. Hani and I are working to keep our efforts in sync so that new features added to 1.3 can be placed in 2.0 as well so that upgrading is possible.
On the migration front, I completed support for most of the main migration tasks. I migrated a few small example apps from 1.3 and it turned out to be fairly effortless once I turned on the old EL support (it uses regular expressions to convert to the new EL). There were a few problems, primarily with Ognl, that will be addressed very soon.
Other than migration, docs is the only thing holding us back. I plan to write docs not about InterceptorFoos and ActionProxyFactoryDoohickies. I believe that the first round of docs should show the simplicity (not the power, which is often equated to complexity) of WebWork. The truth is that writing a WW app is trivially simple (the config is way less verbose than most people think), but without docs no one except Jason and I will know about it. That needs to change.
So in short (if anyone has read this far), I want to express that I think this whole debate is kinda pointless. Use what works for you. The only thing I can do as a developer is listen to the users and provide the best possible support — including docs. I have been quiet (and will continue to be) because I’m working on exactly those things. I also think that this “debate” would be much more straight forward if examples were provided — Kris seems to understand that and hopefully everyone will follow his lead when it comes to comparing any technology choice.
PS: In the end, I’m a big believer that it is the tools that matter the most. JSF and Tapestry interest me greatly and someday I’ll really get to explore them more than my cursory glances I’ve given them up to this point.