Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

The Curious Coder’s Java Web Frameworks Comparison: Spring MVC, Grails, Vaadin, GWT, Wicket, Play, Struts and JSF

Introduction: Let get curious…

Web Frameworks are all very different and have been typically created for different reasons and to achieve different goals. Which Java Web Framework will you use in your next project and why would you chose one over the other? There are many features which may sway your decision and of course it will depend on the type of app you’re building.

Why do we need Web Frameworks?

Well, coding good-looking web applications in Java isn’t super easy. In fact, let’s just say it sucks. It can be hard to do and mostly doesn’t give us the rich front-end we strive to deliver to happy users. This is really the catalyst which has caused Web Frameworks to be created. Both, functional and non-functional web app requirements have led to the need for various web frameworks to be created, but this brings us to the opposite problem…there are so many choices out there to use, which web framework should you pick for your next web app?

We thought it made sense to follow up on the Java Web Frameworks section of our popular Developer Productivity Report and see what we had in there back in 2012. According to over 1800 developer responses, here’s what we found:


More than just looking at market share and usage in place, we wanted to extend this report on Java Web Frameworks to look deeper at these eight libraries, and find out about what is really important to developers, in addition to looking into how different frameworks make sense for different use cases.

This report is the first of two and will focus on a feature comparison across the following categories:

  1. Rapid application prototyping
  2. Framework Complexity
  3. Ease of Use
  4. Documentation & Community
  5. Framework Ecosystem
  6. Throughput/Scalability
  7. Code Maintenance/Updates
  8. UX, Look and feel

We’re going to compare and contrast each Web Framework in this report against each category above scoring and placing each of them based on our findings. The Java Web Frameworks (and versions) we will be discussing in this report are:

  • Spring MVC 3.2.3
  • Grails 2.2.2
  • Vaadin v7.1.1
  • GWT 2.5.0
  • Wicket 6.8
  • Play 2.1.2
  • Struts
  • JSF 2.2

Wait–there is a Part II coming?

In order to avoid a 9000-page report, we wanted to separate it into two parts. In this part, we look at each framework objectively and compare them. In the second report we will take a look at different application types and styles (i.e. use cases), matching the most appropriate Java Web Frameworks to each, from the information and scores from this report. Each application type will care about the categories mentioned in this report to varying extents, which will aid us in weighting each of the categories for the application types. So save some popcorn, keep an eye out for the trailers and make sure you come back for the sequel to this blockbuster report.

What if you no longer had to redeploy your Java code to see changes? The choice is yours. In just a few clicks you can Say Goodbye to Java Redeploys forever.

Continue this on the couch and download the PDF version

  • $247183

    I agree with @anlzselgin:disqus , the proof is in the pudding. Show examples of what has and can be done with the framework without considerable custom modifications on it. That’s the best way to evaluate a framework.

  • caldron68

    Grails does not have good documentation. How you can say that it does is beyond me. If you like one line descriptions of functions, then Grails is definitely for you. But, if you need a little more information on how things actually work, avoid Grails.

  • Lawrence

    JSF on second place. OMG! Seriously??

  • Lawrence

    The BIG issue with JSF is that simple things sometimes take hours compared to minutes in other frameworks. Also, JSF combines content with presentation. That alone is reason enough to shoot it for me. I mean, we’ve had it, that it runs fine except on browser x and then you can start fixing… java code! In the 20 years I have been a web developer, JSF is my last choise. With all due respect.

  • Sean

    Wish the maintenance category included the ease of updating the framework dependencies for the application, not just the ease of updating and maintaining the application itself.

    Also, a security category would be nice and maybe look at how vulnerabilities are found, disclosed, if there are bug bounties, the ease in updating in lieu of a security issue, etc..

  • Adam Koblentz

    Sean, that’s great feedback. I’ll make sure we keep that in mind for the update or next report like this. Thanks!

  • Lambda Pool

    its pure bullshit, spring mvc is full of xml configurations for flows and it stucks everywhere for any reason. full of lies here.

  • hyozbahce

    No matter what anyone says, it is so obvious that; server-generated-html based component frameworks are coming to an end. front-end development is becoming one of the mostly-payed jobs, and service oriented architectures are more popular.

    As a developer, I’ve experience in lots of different frameworks. And I hate the days, that I had to use ASP.NET WebForms and JSF. If I could, I would definitely replace those days with pure, no-component php code :)

    It is a simple equation. People want more dynamic and better looking web applications. It was hard to do that before; but with tools like bootstrap and angular.js it has become so much simpler than before. And every experienced web developer, who had the urge and time to try another framework do know that, a close framework is much more harder to work when everything has to be so much open.

    I don’t need a prebuilt menu element in the framework. I don’t need a prebuilt grid when it is so easy to implement a responsive and good-looking html table with pure html and css. People think it is much harder to implement certain layouts with html and css and it is much easier to implement with component libraries. :) Those were the days of past. The opposite is true now.

    Do know that, if you are developer whose mind is close to new development styles, you are going to be replaced by a developer whose mind is open to those thinks :)