Selecting a Web Framework
- Damodar Chetty
- December 02, 2007

Selecting a Web Framework


Consider walking into a store to pick up a box of laundry detergent. You are faced with an entire aisle full of choices, each box claiming to be the best, and spouting endorsements by dermatologists, allergists, and mothers everywhere. You see the brand you've used in the past, but it kind of looks shabby when considered against its conspicuously labeled "New and Improved" competitors.

To add to your challenge, lets add a representative for each product each standing on a soap box surrounded by his/her disciples, and each yelling at the top of his/her voice about why that particular product is so much better with whites and colors, and yet is gentler on your skin, than anything else on the shelves.

Add to this, that as soon as you pick one product, you're faced with jeers from the rest about the "wrong-ness" of your choice, and all the evils that will befall you and your family.

Far fetched? Not if you perform some judicious replacements of "laundry detergent" with "web framework" and "representative" with "evangelist".

Problem scope

If you are a J2EE Web developer, it doesn't take a genius to predict that a very common question in your career has been:
"Which web framework should we use on this project? ".

The most interesting part about this question is (a) how often it comes up; (b) the passion it generates; (c) the subjectivity that comes into play; and (d) how the answer changes every 6-9 months.

In many ways, a J2EE Web consultant could easily specialize in the answering of just this one question! In fact, one expert who publishes very interesting, and frequently updated, perspectives on just this issue is Matt Raible (Reference [1]).


So is this really a tough decision?

Lets start with the fact that you have well over a dozen well respected frameworks out there right now, including JSF, Struts 1, Struts 2, Wicket, Stripes, Tapestry, Rife, Grails, Spring MVC, and Spring WebFlow. Mix in the RIA alternatives such as the Flash-based OpenLaszlo and Flex. Then, add in the various JSF implementation flavors (such as Facelets, Seam).

Next, throw in the hype that is generated by each framework's evangelists/developers who believe that their particular framework is absolutely the best, and that everyone else just hasn't seen the light yet.

Finally, let's introduce average Joe Developer who is simply trying to get his work done, to meet his timelines, and then hurry home to his waiting XBox.

With all this noise, how does Joe go ahead and pick a framework? Well, the traditional answer (which thankfully is falling out of favor) is that Joe gives up, claims confidently that every framework is currently immature, and rolls his own. A more typical answer is that Joe simply picks the one that he is most familiar with (and perpetuates the lifetime of Struts 1).

How critical is this decision?

For all the noise and fury surrounding this decision, the unfortunate truth of the matter is that the answer doesn't really mean much. The bottom line is that most Web frameworks out there in the wild are actually darn decent platforms to build an application on, and unless you are trying to do something so off-beat that you need some peculiar non-mainstream functionality, you can't go wrong with picking any one. Of course, you just might have to endure the ridicule of your colleagues (esp. if you pick Struts 1), but then you're your own man (or woman), aren't you?

Any Web framework worth its salt today will provide a reasonable architecture, will help you manage session state, support validation and conversion of incoming request data, provide security features, handle internationaliztion, and even provide alternative configuration mechanisms.

In addition, the more capable ones will throw in support for Ajax, will support templated composition (e.g., Tiles or SiteMesh), and will integrate nicely with rich UI libraries (like Dojo, or Scriptaculous). Some might even help with Redirect after Post as a solution to the repeated submit.

Web Framework Considerations

Be that as it may, how do you go about picking the one true framework? As a business solutions developer, here are my primary criteria, ordered from most important to least.

Note that I have not considered the truly off-the-charts requirements that a project may impose, for which only a very specific framework would suffice. I've yet to encounter such a project, so I'm assuming that those are fairly rare. If this is true in your case, well, then you're the lucky one, your framework decision just got very easy - you just pick from your choice of one.

  1. Popularity
    A popular framework bestows very real advantages on your project.
    1. The whole point of using a third party framework is to enable you to focus on building business applications without having to muck about in the low level plumbing of the APIs that prop up web development. So, the more you have to find answers for yourself by spelunking in the framework's code base, the better off you'd have been with a different choice.
      After all, you're almost always getting paid to get work done. And, there's nothing more frustrating than putting your work on hold, while trying to find an answer out for yourself :)
      Being able to query a forum or to Google an answer is a major timesaver, and I'd be willing to sacrifice quite a lot to obtain this free tech support. This is all the more important in the world of J2EE frameworks which due to their open source nature, have almost non existent support and mostly incomplete documentation. So, unless you want to roll up your sleeves and dig into the innards of your chosen framework - popularity ends up being a major boon.
    2. Picking a popular framework also means that you won't hurt when it comes to staffing your project. You will appreciate the flexibility that comes with this, as soon as you are asked to scale up your development team at short notice ... which is not such a rare occurrence these days.
      An interesting argument has been made that picking a niche framework adds to the job security of a team, but I'm discounting the logic in that for now.

    A couple of easy tests here are to (a) check Amazon to see how many books have been written on the framework, (b) visit Monster to see how many people are looking for and/or have this skillset, and (c) check out the framework's 'live-ness' by monitoring message boards, mailing lists, and blogs for recent chatter. (e.g., check out any group on, which lists traffic in terms of posts per day).
  2. Long term viability
    Viability measures are about the same as for popularity. However, unlike popularity, which looks at taking a snapshot of the current lay of the land, here we are talking about the likelihood that this framework will still be alive and kicking in 5 years time.
    Most non trivial web projects tend to live for around 5 to 7 years before they start coming up in team discussions as prime candidates for a "rewrite" or "rearchitecture". Given that, a good rule of thumb would be to expect your framework of choice to stick around for at least 5 years.
    Predicting the long term viability of an open source project is a dicey proposition. What you're looking for is being able to predict the next Struts 1.x. You want to avoid being stuck with something like Maverick, or any number of other also-rans. Unfortunately, as Rick Hightower points out in Reference [2], the future may never see another Struts 1.
    This sort of echoes my personal philosophy of not being an early adopter of technology products. You do sacrifice the "coolness" factor for not being on the bleeding edge, but you also end up with a better price/performance ratio, as well as not having to spend countless hours on forums and message boards railing against developers who don't release "complete" products any more.
    It is prudent to remember the warning on your 401K mutual fund prospectuses ... past performance is no predictor of future viability.
  3. Prototyping
    This one is tragically underused as a selection criteria. The ideal prototyping scenario includes participation by at least 3 developers, evaluating at least 3 options, with each spending at least 80 hours on the exercise. While this initial outlay of 240 hours may seem excessive, consider that this is less than 2% of the actual cost associated with the final web application.
    [Assuming - completely arbitrarily and unscientifically - that a web application lasts about 6 years, requires a year to build with 4 programmers, and has 2 programmers to actively maintain it.]
  4. Developer comfort / Learning curve:
    It is hard to overestimate the value of inertia, making this more often than not, the primary driver in the selection of a framework. I've seen numerous "comparison" studies where the outcome is pretty much clear from the start, where the most compelling arguments are made in favor of the framework that is currently part of the architect's or team's skillset.
    On the other hand, it would be unwise to neglect this very important driver. There are enough challenges on most projects without having to add training of an entire team on a different development paradigm into the mix.
    A particularly important consideration here is your comfort with component-oriented vs. action oriented frameworks, e.g., JSF vs. Struts; as well as in the degree to which you want your code to be Java centric (e.g., Wicket).
  5. Ease of configuration. XML based. Annotations. Convention.
    This is an area of contention that is high on hyperbole. This has to do with how you tell a framework about your custom development. Its often the core glue that ties the controllers in your code to your views (usually JSP files). It may also encode rules for custom validators and converters, as well as serving as a mechanism for dependency injection.
    This has traditionally been achieved as an XML configuration file. But, given that XML is not the "in-thing" for J2EE any more, is often being driven by convention/exception or using annotations.
  6. Technical feature set
    An important driver of this decision is usually not whether a framework supports some advanced feature (such as Ajax), but how well it does so. E.g., the Struts 2 Ajax support felt fairly primitive to me, and I wouldn't add it to the top of my list if that were a primary criterion on a project.
  7. Lines of code
    Another common factor for comparison is how many lines of code it takes to achieve some piece of functionality. Those that take fewer lines of code are touted as being far better than their less fortunate competitors.
    Of course, often times, the examples provided to show how few lines of code something requires are simply toy examples. This tends to fail miserably when dealing with the ugliness that is part of normal development reality, where there is an existing persistence or business layer, a disapproving DBA, and "out of line of sight" teams that are set in their ways.
  8. Skills Marketability
    It is difficult to discount the fact that one consideration in picking a framework is whether it will look good on your resume. Knowing JSF or Flex may make you more marketable than multiple projects with an in-house framework ever could.
    Its hard to deny that I like to see a resume with experience in multiple frameworks.


So what's my recommendation?

Review the above list of important issues to be considered. Add in any additional considerations that may be specific to your project or workstream. Then, reorder them by your perceived order of importance. Then pick the framework that meets your most important criteria (or toss a coin if more than one comes in close),


Don't Look Back!

I've worked on a number of projects where the "web framework" (to be charitable) used was actually homegrown. It is interesting to note that I cannot recall a single instance where a business feature point could not be implemented on that particular framework. In fact, I can't recall a single instance where web site failure could be linked to performance or scalability issues related to that in-house "framework". Note that I did not say anything about the developer's comfort with the framework - just that I didn't run into any feature that could not be implemented within the performance and usability constraints placed by the end users.

So could it be that maybe, just maybe, the whole idea of framework selection is way overblown, and that in reality this decision is actually not quite as important as your high priced consultant or your high placed architect might lead you to believe?

Or is this just our way to encourage intelligent discussion about the future of web development? That's for you to decide :)


  1. Matt Raible's Web site
  2. Sample of evangelistic speak

Valid XHTML 1.0 Strict