CrashSplat, BANG!

As I mentioned, in my last post, we are evaluating web frameworks at the office. Seeing as all of our current web-app development is done using Struts 1, we thought it would only be fair if we first looked at Struts 2. I also mentioned in my previous post that we have some basic criteria by which we are evaluating these tools. This evaluation took place on Friday, February 29th, with two of my coworkers.In case you’re wondering, Struts 2 is a significant departure from Struts 1. In fact, it’s totally different. If you’ve ever used WebWork then you’ll be at home in Struts 2 because it’s basically WebWork renamed.How did it stack up against our criteria?

• 10 Minute Rule – Unfortunately Struts 2 failed miserably here, but it’s not all the framework’s fault. Because of some of our other evaluation criteria, namely “Convention over Configuration”, and “RESTful”, we had to use the current development version of Struts 2 (2.1.1 I believe), not the officially blessed version (2.0.11.1 at the time). This meant we had to download, and compile the source. In order to compile the source we had to have Maven. All of our tools are currently built using Ant, so we had to download Maven. Oh, and by the way when we used Maven to build Struts 2 it downloaded the entire Internet onto my workstation while resolving dependencies. We did however eventually get it built. Let’s just say it took a bit longer than 10 minutes to get compiled jars, not to mention running code. However, once we got past this initial hurdle we were able to use the REST showcase application (I’ll mention it more later) to get up and running quickly.Grade D (Maybe C)
• Convention Over Configuration – Once we got everything compiled and running Struts 2 really shined here. However, I should note that this is not necessarily stock behavior for Struts 2. We made use of the Codebehind plugin in order to achieve this (note, it’s also required for the RESTful stuff). Basically if you name things a certain way and put things in the proper places Struts 2 will “figure out” what to do. In our afternoon of playing it worked great. It may also be worth noting that the Codebehind plugin was yet another thing we had to download, and compile, thus further slaughtering the “10 Minute Rule”.Grade A
• Tool Support – This one is a bit of a no brainer. Struts 2 is all Java, we’re an all Java shop with a great IDE. So, we didn’t have any issues here. It’s probably worth noting that all of IDEA’s Struts specific features are geared for 1.x. However, I find most of those features pretty useless anyway, your mileage may vary.Grade A
• Developer Resources – Maybe it’s just me, but I thought that most of the Struts 2 documentation sucked. This probably has something to do with the fact that we were using developmental plugins and an edge version. I’m sure if I took more time to read I would have had a better experience, but as we were rushing to accomplish something in a day I didn’t find the docs much help. On final thing to note about documentation, when you are looking at plugins it can be very confusing as to what plugins do what, what requires what, how one is different from another, etc… it’s a bit of a mess. Seeing as this is Struts we’re talking about I’ve got to believe this stuff will keep getting better as more people move to Struts 2.Other things of value to note here, a simple Amazon search shows that there are a number of Struts 2 books (not sure if any of them cover RESTful stuff). Also, it’s an Apache product so there’s going to be conference coverage.Grade B
• RESTful – Once we got the REST plugin downloaded and compiled this was seamless. The REST plugin comes with a showcase application that serves as a good reference for getting up and running. Most of the RESTful stuff just happens. It’s really nice.Grade A
• Access to Java – Struts 2 is written in Java, it obviously runs in the JVM, nuff said.Grade A

Overall I was satisfied with Struts 2. Aside from the things already mentioned the only major concern I had was the constant feeling that “this ain’t quite ready for prime-time”. Again though that’s mainly because of the desire for “zero configuration” and “REST”. If those things are not requirements for your project, and you can use the current release version of Struts 2 you’ll probably have a decent experience.

At work, sometime towards the end of this year, we’ll be moving our primary application to a different web framework. There are a number of reasons for doing this, some I’ll talk about here, others I won’t. Obviously in order to properly evaluate some of the tools we need to develop some basic criteria for the evaluation. None of this is set in stone, but here is my first cut (these are in no particular order):

• 10 Minute Rule (ok, maybe 30) – Given the current state of most modern web frameworks it seems to me that you should be able to do something of value quickly. While I understand that you probably won’t finish your application in an afternoon, you should be able to accomplish something measurable. If it takes you all day just to setup your environment, you fail. How long does it take you to write “Hello World”? This will provide a good idea of how quickly you’ll be able to iterate on things when you’re doing real work.
• Convention over Configuration – This concept has been popularized as of late by Ruby on Rails. The core idea here is that if you name things certain ways, put things in certain places, and in general, follow understood methods then you shouldn’t have to spend a bunch of time “telling” the framework where things are. If you have spent much time maintaining a large enterprise web application then you understand why this is important (if not important, then definitely desirable). Most of my recent experience has been with Struts 1, which has lots of “configuration” bloat. Define your actions in this xml file, put your reusable views over here in this xml file, map your domain objects in these xml files, prick your finger and put a drop of blood over here, blah, blah, blah. Not that I’m knocking Struts 1, because we have built some great stuff with it, but these days I think we can do better.
• Tool Support – We’re an all Java shop and all of our engineers have become pretty dependent on a good IDE. Whatever framework we decide to use needs to play nicely with our current development environment. Things like code completion are critical. Can you start, stop, and reload from within your development environment? How long does that take? Telling all of our developers to go back to using vi or emacs just ain’t going to cut it.
• Developer Resources – I want to make sure that whatever framework we choose has lots of resources available for our developers to consume. What is the documentation like? Are there books that you can buy from Amazon? Are there active mailing lists? Are there conferences that you can attend? Is there a local user’s group?
• RESTful – It’s my hope that whatever framework we choose will easily facilitate (if not mandate) RESTful development. I want a framework that will take out some of the guesswork that can be involved here.
• Access to Java – Seeing as all of our core technology is built using Java this is pretty important. We need the ability to reach back and execute Java code in our existing stack. This doesn’t have to rule out frameworks that are built using other languages, but it does mean that if we do look at other languages they’ll have to run in the JVM.

Adam Keys’ recent post on micro-apps is a great read. It’s inevitable that we’ll continue to see a rise in the number of “micro-apps” as developers leverage rich API functionality in mashups.