It wasn’t too many years ago that the people at Apache realized that you could probably come up with an organized way to use JSP’s and Servlets without making a huge mess. They called it Struts and it was a good, maybe even a great product when it came out. As the years went on and incremental releases of Struts started coming out, the product never really got better. Things were fixed here and there, maybe a feature was added but nothing worthy of a major release ever happened to it. Developers, even the slower ones, realized that an MVC framework offers a way to sanely manage the various scenarios in a web application, and even streamline some of the behavior common to their applications. Struts opened the door to a new wave of web development and served as the flagship product leading the way for J2EE.
However, Struts never got past the 1.x range of things because it never got significantly better. It always stayed the same and it’s committers decided that there’s no need to fix something when it’s not drastically broken. Then it was left to other people to come up with add-ons and plugins to Struts to make up for the lacking framework. Products like Struts Spring Plugin and Struts AjaxTags which had no business existing, were created. What should have been part of the framework, was now an add-on. It was left to Michael McGrady to figure out how to properly use buttons in a Struts application. All in all, Struts slowed down to a crawl until nothing but bug fixes highlighted the releases.
In the corner sat Patrick Lightbody and Jason Carreira who saw what Struts was lacking and started on Webwork, a framework that was based on common sense. OpenSymphony’s Webwork was a simple alternative to Struts that lacked the community support, but had all the features to make web development a whole lot easier. What the initial releases of Webwork lacked were more than made up for the groundbreaking Webwork2, which blew Struts out of the water in every way. Webwork2 had Spring integration, pluggable view rendering, an intuitive validation framework, dynamic action invocation, action classes that were simple and powerful and a tag library that supported them perfectly. Later releases of Webwork2 had Ajax capabilities and even made use of Java 5.0 generics and annotations. In short, if you had to start a new project, you’d be a fool not to go with Webwork.
I was a Webwork user and despised using Struts because it felt clumsy, redundant and boring. Then one day I was reading Patrick Lightbody’s blog and he mentioned that Struts and Webwork were merging for the betterment of the Java development community. I was shocked to see the pretty girl actually agree to a date with an 80 year old dying patient. There was no reason for it. In my shock I asked people why on earth Webwork would even want to be associated with a product like Struts that was good five years ago and was now reduced to being used by developers who refused to use anything except what they’re comfortable with. They told me that Webwork lacked the marketing power of Struts and nobody was going to use it because they were already using Struts. That to me wasn’t a reasonable explanation since I believed that people would soon see just how much better Webwork was than Struts and would naturally switch over. But my theory will never get a chance to be proved correct since the two have now merged.
So what convinced the Webwork folks to join forces with Struts? I don’t know. I’m not privy to that information but I’m sure it was a convincing argument. Now that the two have actually become one, I hope Struts2, now in beta, adapts a progressive and exciting approach to changing web trends and technologies much like Webwork did. I would hate to see Struts2 fall behind like its predecessor, especially when it’s got the great start it needs, thanks to Webwork.
Even though the body is Struts, I hope the soul is still Webwork.