Notes On Choosing A Web Framework

I’m looking at starting a new project and once again find myself choosing between frameworks. Having spent some time evaluating different ones I wrote up some notes to share and get some feedback that might alter my thoughts or opinions. Here’s the criteria I’m using to choose a framework in no particular order.

IDE Support – I would like to get as much IDE support as possible for auto completion, code validation and general helpfulness.

Resume Building – How much demand is there for the skills? I’m looking to bolster my skills that have wide adoption in the industry. As this is an important factor, it also means I probably won’t be choosing a framework that I am already very familiar with. I’ll be using job trends and opinion to determine the industry support for the frameworks. I know job sites aren’t the best measure, especially since many ads are stuffed with buzzwords so they appear in searches even if there is no JSF, JAXB or JAX-WS involved. However, the fact that they are included at all indicates some kind of market penetration of the technology.

Ajax Support – How well does it support Ajax natively out of the box as opposed to requiring third party libraries and are there de-facto standard libraries for that framework if they are needed.

Templating / Layout – How are pages built and organized to enable reusable HTML without using include statements everywhere or some other mechanism which will require every page to be edited if the layout is changed. I think facelets is the best page layout library out there as it pulls the template into the page and then pushes the content from the page into the template making separate files optional. Tiles requires separate definition files and does a similar thing outside of the page being rendered. Sitemesh is non invasive and works by decorating existing pages as they are sent to the client. In terms of writing actual pages, the choices are Jsp, Velocity and Freemarker, of which JSP and Velocity are the two most in demand.

Completeness – How much is in the framework out of the box without requiring additional libraries for core functionality. Obviously, you are going to need libraries for things like data access, but the framework should be able to put text in a page without requiring third party libraries. One other aspect of this is how easy it is to get up and running without having to get different pieces configured and talking to each other. Some frameworks discussed here like Spring MVC and JSF are not meant to be complete frameworks but a framework onto which to build other frameworks (like Servlets). In these cases, the frameworks are expanded by third party libraries so completeness is not so much a factor here. Third party libraries integrated as part of the stack is acceptable (i.e. Sitemesh in Grails and Richfaces in Seam).

Custom Paginated Tables with Sortable Columns – This is my barrier for determining how powerful and easy a framework is to use. Simple CRUD is trivial to write, it’s like hello world for the web so I usually go for a more robust litmus test by writing some pagination code. Action frameworks require you to chug all the parameters backwards and forwards and handle your own binding and determining whether a page was selected or next/previous was clicked while Component frameworks handle most of that for you. For the same reason, clickable columns can be a real pain. For bonus points, how easy is it to implement multiple paginated / sortable tables?

Statefulness – Can we integrate some kind of stateful mechanism in there (i.e Spring Web Flow) cleanly? There are a few scenarios where I will need a stateful workflow in the application.

Third Party Support and integration – One annoying aspect of java web development is all the pieces and parts that need to be strung together and then you have to get them to play nicely. This is really about the path of least surprise, and not having to deal with issues because I add libraries that don’t have special mechanisms for working with each other.. I.e Spring MVC embraces Tiles, but how much of a hassle is it to incorporate Velocity with Tiles? This issue is also somewhat redundant for those frameworks that include built-in solutions for most needs.

The application is going to be moderate in size, but hopefully growing as time goes on. For that reason, I’m looking for something flexible enough to grow and refactor later on. Initially, I’m also looking for something lightweight and will be looking to deploy it on Tomcat primarily due to ease of hosting.

Action or Component Based

I find Action frameworks are great for catalogs and simple CRUD pages but when you start getting to more complex web applications pages, things get much tricker. Take for example a search page with 10 search parameters, suddenly you find yourself having to attach 10 parameters to the next/previous/first/last result links or using javascript funkiness to modify form contents to change the form state and post the form. Add column ordering and things get pretty messy quickly. In my mind, For a web application, any search pages (or other pages that require pagination or other common interface elements) should be trivial to write within minutes. Obviously, if you are Google and your main business is that one search page, you can afford to spend a little more time on it and be as choosy as you like on how to implement it. However, it never fails to amaze how much code people will write to create a single page demonstrating how to do some simple function in a non-reusable way. User interface elements like pagination and column ordering should be totally reusable.

The Contenders

Here are the contenders in no specific order

  • Seam with JSF
  • Wicket
  • JSF
  • Grails
  • Spring MVC with JSP
  • Spring MVC with JSF

First lets look at the job trends for these different frameworks :


spring java, ejb java, jsf java, "spring mvc" java, wicket java, seam java, grails java Job Trends graph

spring java, ejb java, jsf java, "spring mvc" java, wicket java, seam java, grails java Job Trends spring java jobsejb java jobsjsf java jobs"spring mvc" java jobswicket java jobsseam java jobsgrails java jobs

We can see a sort of multi-tier system in place for different frameworks. Spring and EJB both rank up there as first tier technologies. I’ve already had quite a bit of experience with both of these but Spring is at an advantage with regards to being lightweight and running in tomcat without having to worry about setting up an embedded EJB container. Writing something with EJB 6 might be a possibility, but I think it more likely I’ll try and use Spring.

Now lets consider the view frameworks :


jsf java, "spring mvc" java, wicket java, seam java, grails java Job Trends graph

jsf java, "spring mvc" java, wicket java, seam java, grails java Job Trends jsf java jobs"spring mvc" java jobswicket java jobsseam java jobsgrails java jobs

Seam / JSF

I’ve had a lot of experience with these two so it’s easy to comment on. Great IDE support (probably the best), great out of the box support, but it can feel foreign to use on Tomcat where it doesn’t offer such a rich a developer experience. Great Ajax support, but not so great for the resume since I already have a lot of experience with Seam and there are very few Seam jobs out there.

Seam
IDE Support Excellent – JBoss Tools Demand Poor
Ajax Support Excellent – Richfaces Templating Excellent – Facelets
Pagination Excellent – reusable component based pagination Completeness Excellent
Statefullness Excellent – Conversational scope 3rd Party Library Integration Ok – Seam likes things to run a certain way

JSF

Despite using Seam a lot, writing a straight JSF application is still quite different and poses a number of challenges. It might be a interesting using just JSF but I have most of that ground covered with my existing JSF work. JSF is in-demand though and this might be an opportunity to use it with other frameworks such as a Spring/Hibernate/JSF combination. It has great Ajax support with multiple frameworks available, but no decent IDE support even though JBoss Tools works well on plain JSF apps without Seam. It may also get frustrating since I’ll be having constant reminders of how easy things are when you use Seam. Facelets is a great templating framework, if not the best, and I’d probably go to JSF 2.0 so I can use annotated beans. For statefulness, I could add in Orchestra and pagination should be simple with JSF although I think Seam (or JBoss-El) added ways to call methods (with parameters) on beans passed in to facelets which made it really easy. I haven’t been able to duplicate that with in JSF or Spring Faces which could be a problem. One annoyance of JSF is the inability to suppress validation when you post the form back but don’t want to save it which you may want to do as part of a web flow where you want to save the contents, go to another page, come back and finish your data entry. The only solution is to manually perform validation when the form is finally saved and not use JSF validators which is a limitation and I don’t thing this was fixed in JSF 2.0.

JSF
IDE Support Ok with JBoss Tools Demand Excellent
Ajax Support Great with 3rd Party tools or JSF 2.0 Templating Excellent – Facelets
Pagination Good Completeness Ground framework
Statefulness None without 3rd party libs like Apache Orchestra 3rd Party Library Integration Excellent for JSF libs

Wicket

Wicket is a great component based framework with good ajax support, a fine grained stateful architecture and because of it’s emphasis on the java language, good IDE support. Some people don’t like the heavy use of java code to build web pages, but it’s a personal thing and I do enjoy it. However, the only thing holding it back for me is the poor industry adoption with very few Wicket jobs.

Wicket
IDE Support Great since it is mostly java based Demand Poor – unfortunately
Ajax Support Excellent – it comes with Ajaxified components Templating Excellent – Offers page inheritance and panels
Pagination Excellent – reusable component based pagination Completeness Good
Statefullness Excellent – Fine grained statefulness 3rd Party Library Integration Great – although you won’t need or be able to use many web libraries (i.e. tiles, velocity etc) here.

Grails

I tried to get back into Grails and again, I hit a number of snags. It’s a great framework, but I find it can be problematic. The IDE support was basic and I often had to clean the eclipse project then the grails project so it wouldn’t choke on old classes lying around. Netbeans also has Grails support, but was prone to hanging when you want to restart the server. It also lacked the refactoring / renaming features present in eclipse. I also found problems in the framework itself such as not being able to model embedded classes that contained a reference to another entity. Other times, inexplicably, when I called person.save() nothing would happen, no error, no messages, nothing. I don’t doubt it was my fault and something I did, but it is off putting and frustrating in a framework that won’t tell you when you have a syntax error.

Grails and Wicket seem like polar opposites in some ways. Wicket is all about type safety and strict java code checked by the IDE. Grails on the other hand doesn’t often know when you make a mistake because its a dynamic language. Developers shouldn’t have to write tests just to make sure you didn’t make any typo’s in your classes, people have spent a number of years and millions of dollars evolving IDEs to solve that very problem.

The dynamic language is all very nice, and Grails is a framework but when I’m building furniture, I don’t start out with aflat pack plywood cabinet and slowly replace each piece with half inch mahogany with hand cut dovetail joints in the name of being rapid and agile (umm, Agile Wordworking, there’s an idea). I can see the point, and for the most part, Grails is unobtrusive but I think for me, on this project, I’d rather start out with a workbench and some planks of mahogany and craft it from scratch.

Ajax support is excellent and it also has many plugins which are easy to install and use. Writing taglibs is a breeze and very intuitive. Even pagination was fairly simple and I especially liked the paginator tag that takes a map of parameter values to include on all the previous/next/page links. Again, things are scarce on the job front for Grails, but being such a unique and productive tool I think there is a great future for Grails which lowers the importance of current trends.

Grails also supports Spring Web Flow but I’m not sure it allows the use of flow scoped persistence contexts. Sitemesh is used for templating and offers a lot of features out of the box. Overall it’s very impressive and definitely still a contender.

Grails
IDE Support Poor Demand Small but growing
Ajax Support Excellent Templating Excellent – Sitemesh and easy taglibs
Pagination Great Completeness Great – plugins make things easier
statefulness Spring Web Flow 3rd Party Library Integration Plugins make it really easy

Spring MVC with JSP

This is probably the one I was most eager to tackle as I think this one probably has the most potential. Spring and JSP have been largely adopted within the industry, but are they any good? I think Spring MVC is excellent, especially with the new Spring 2.5 Controller annotations and Web Flow integration. As usual with Spring, it provides a lot of flexibility and it sits on the Core Spring Framework. For templating, I can use Sitemesh, Tiles, and it includes support for velocity and free marker. It appears that using both Tiles and Velocity together isn’t straightforward resulting in this third party plugin to solve the problem.

Spring MVC doesn’t have any ajax support, Chapter 13 – Web MVC Framework of the Spring reference documentaton doesn’t even mention the word Ajax. Spring Web Flow has Ajax support but it requires the use of Tiles (or some other compatible templating library) for specifying page fragments to update. This is also requires that pages be designed in such a way that the Ajax updatable pieces are clearly defined in the page definition which is outside of the page being designed. With Richfaces you can create a fragment in the page just by using an output panel tag and giving it a name. Another problem with Spring Web Flow is the inability to use an Open Session In View alongside the Flow Managed Persistence context which means having to work around Lazy Initialization Issues in other ways. On the plus side though, you can make validation optional in Spring Web Flow if you are using the Spring Validators and not JSF.

Spring MVC with JSP
IDE Support Good – Spring IDE Demand Excellent
Ajax Support Poor Templating 3rd Party
Pagination Roll Your Own Completeness Spring MVC offers a solid ground on which to build
statefulness Spring Web Flow 3rd Party Library Integration Good

Spring MVC with JSF / Spring Faces

If I couldn’t find a way to reconcile the problems with Spring MVC and JSP, this would be my backup as it solves a number of problems with using Spring MVC and JSP. It fixes the Ajax and templating issues since I can use a JSF based Ajax framework (IceFaces or Richfaces) and Facelets for superior templating. The only problems here is a resource issue for JSF and the fact that I have already worked with JSF extensively. However, I have found Spring Faces to be a great library to use with some nice extensions. While there are only a few jobs explicitly mentioning Spring Faces, there are many jobs involving Spring and JSF. While spring web flow de-couples your view from the back end, it can be a little too decoupled. For example, within a flow, to call a method from a command button and refresh some data requires you to call the method and return an action string that would trigger the refresh of the data in the web flow. In Seam, you can get away with just calling the method and then refreshing the data. Spring Web Flow, forces you to decouple that which makes for a lot more work when you have multiple links that can trigger a refresh of the data. It also doesn’t fix the open session in view / flow managed persistence context clash. Writing JSF pages outside of a web flow means having to work directly with Spring beans as Jsf backing beans as opposed to dealing with Spring Beans through the web flow. This isn’t a big deal though, it just means you have two separate styles of writing code. Even though Spring Web Flow lets you suppress validations for flow transitions, It doesn’t have any effect when you are using JSF for the view, only when you are using Spring validations.

Spring MVC with JSF / Spring Faces
IDE Support Good – JBoss Tools for JSF and Spring IDE Demand Great – Spring and JSF Combination
Ajax Support Excellent Templating Excellent – Facelets
Pagination Good Completeness Good
statefulness Soring Web Flow 3rd Party Library Integration Good

Summary

Ultimately, it boils down to Grails or Spring MVC with JSP and probably Tiles and if I can’t find a solution there, Spring MVC with JSF. I f career/employment was not a factor, I would pick Wicket with Spring in a second, however, as I’m looking to bolster my resume and make sure my bona fides are in order for the more popular technologies.

All in all, it’s a difficult choice, but I’d love to get some more thoughts on the matter. I’m sure there are plenty of opinions on frameworks out there in The java community 😉




10 thoughts on “Notes On Choosing A Web Framework

  1. Hey Tetsuo, sort of!

    I’m just trying to hit the sweet spot of working with a framework that doesn’t suck and will help pay the bills. Too often web frameworks make things difficult where others don’t but they have other faults.
    It’s like some weird condition laid down by the Gods of computing, we shall have our frameworks but never be content lest we grow lazy and never develop Yet Another Web Framework.

  2. Pingback: MyPage Builder

  3. Nice and thoughtful analysis. Please give straight up JSF2.0 a good look. It’s much more than just annotations!

  4. Maybe there isnt really a demand for wicket because you only have to say that you should be a good OO java developer.. 🙂

  5. thumbs up for an excellent analysis of the frameworks, wicket is my favorite, but unfortunately is not an industry’s favorite and also the guys behind the wicket, i think need a lesson or two on marketing, because the framework is an excellent one.

  6. Ed, I’ve been having a good look at JSF 2.0, and it looks great, especially with Netbeans 6.8 m2 and Glassfish v3, I’ll hopefully blog about this in the next week or so.
    Ikenna, totally agree on the Wicket thing, it is a great framework but with poor adoption. However, thinking about it, the wicket adoption rate is no worse or better than the other frameworks in the same space. Only JSF (a standard) has done really well, and even Spring mvc, with widespread spring adoption isn’t that far ahead of the pack.

  7. You somewhat left out Oracle ADF/BC4J, these are highly in demand in enterprises implementing Oracle centric solutions.

  8. Good Article!
    I am having a good look at JSF 2.0. I am convinced that the technology will have increasing adoption rate for enterprise applications. Java EE 6 CDI support will give a boost to JSF.