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

The 2014 Decision Maker’s Guide to Java Web Frameworks

Summary of Findings and Goodbye Comic :-)

Here’s the “too-long; didn’t read” (TL;DR) version of the report, where you can rest assured that we’ve curated the juiciest bits of the content into a single section that’s designed for lazy coders. Recently, we were told that the TL;DR section should come before a “pile of text”, but we figure that’s just related to the guilt incurred by lazy readers for skimming through dozens of painstakingly-prepared content to get to the last part. Ha-HA!

java web frameworks part 2 comic

If we had to consolidate this entire report into one [long] sentence, it would be this:
If you are going to choose one framework to rule them all, then we recommend Vaadin, Grails or Play as our top 3 choices, but if you want to synergize (ooh, 90s buzz word!) the benefits of multiple frameworks, then Spring plus nearly any other framework we covered (especially GWT, which saw the greatest gains) will yield the best results. The choice is yours. Anyway, here’s a summary of what we found…

Chapter I – Where Pooh and Piglet rank frameworks for Testability and Security

How do each of the frameworks help you test your app? Most frameworks made this process easier by integrating with good existing tools like JUnit and Mockito, but with helpful additions Play and Grails stood out and won the category, with Spring MVC and Wicket tying for second place.

The ability to easily implement authentications, authorizations and other security features with your framework is crucial to many organizations. Both Wicket and Spring (other frameworks like Grails and GWT in fact integrate with Spring Security to bolster their feature set) win this category with excellent standard support. Vaadin and Play arrive in 2nd place, and last comes GWT, which needs the oft-attacked JavaScript, so we don’t recommend using this framework alone.

Chapter II – Framework Rankings Based on Application Type

CRUD (Create, Read, Update, Delete) app – e.g. Evernote
For our next Evernote-like application, we would concentrate on ease of use, throughput/scalability and testability. In this category, Play and Grails stood above the rest with good scores in these categories.

eCommerce app – e.g. Amazon
Here a framework’s ecosystem, throughput/scalability, UX (look and feel) and security are of the highest importance. Vaadin, Play and Grails are the top 3 highest ranking frameworks, with Spring, Wicket and JSF tied in 4th place.

Video/streaming app – e.g. Netflix
Simple yet very hungry, video/streaming apps like YouTube need a great UX and high throughput/scalability, which is why Vaadin is 1st and Play and Grails tie for 2nd place. Spring, GWT and JSF are also strong in throughput/scalability, but leave things desired when it comes to UX design.

Desktop application port – e.g. Salesforce
Security, good UX and easy code maintenance/updates are the factors we judged to be most important for SalesForce-style apps, and Vaadin, Wicket and Grails all excel here. However, the super-combo punch is in fact Spring + GWT, which would in fact beat out Vaadin. Ooooh…

Mobile app – e.g.
Security and UX look and feel will top the priority list for this app type. With security difficult to handle on mobile apps, so Spring and Wicket stood out here, but their lower scores on UX led to Vaadin and Grails taking 1st and 2nd place.

Multi-user app – e.g. Scribblar or Crocodoc
Concurrency and a great user interface are high priorities here, so throughput/scalability, security, UX and code maintenance/updates are all important in a framework. Vaadin and Grails again take the top spots, with high marks in all areas. Again here, a combination of Spring and another framework (namely GWT), would come in at 2nd place, though not beating Vaadin.

Prototyping app – e.g. your own app in development :-)
Want to make a testbed for your own app? Rapid app development, framework ease of use and level of complexity, plus docs and community are major areas to look out for. Being easy to use and easy to get started with, along with great docs and a strong UX, Vaadin just barely nabs the 1st place spot over Grails (2nd), followed by GWT, which excels in light of the low priority for high security features.

Chapter III – The Results

As the results show, Vaadin, Grails and Play are the first, second and third place winners not only for features like UX (look and feel), throughput and scalability, and ease of use, but also when compared across seven different application types, from eCommerce to Mobile and even Prototyping applications. JSF, Wicket and GWT are all fair contenders for the middle of the road frameworks, excelling individually in key areas but not bringing enough to the table in others.

One interesting takeaway from this is the fact that although Spring MVC didn’t come in first in any single categories, due to it’s size, community and security it is in fact an ideal candidate to bundle with another framework, such as GWT, which gained more than any other due to the addition of Spring Security. Here we see that a combination of Spring and another framework will beat even Vaadin in many cases. That said, if you are going with a single framework for most needs, become a Vaadin ninja for extra happiness.

All of us at the RebelLabs team hopes that you enjoy this report, and invite you to leave comments below and share the heck out of this awesome report. Twitter is a good place @ZeroTurnaround.

Ok ok, you probably don't need the PDF now, but here it is anyway...

  • Simon Maple

    Hmmm, that Sven guy, in the video clip, has disguised himself well, but I can just about tell that he’s the award winning singing sensation from “Install it Maybe”!

  • Oliver White

    It’s true! I’ve spotted him!

  • Joe

    ZK still not listed. Unbelievable. Is it because of the partnership between Vaadin and JRebel?

  • salk31

    GWT is insecure because the client is JavaScript!? It is the client technology. Are the other frameworks using something other than HTML and JavaScript?

  • kpolo

    Exactly what I thought. This article should be labeled “The personal preference of someone at JRebel, that company that annoys you with a hundred and one phone calls”!!!

  • salk31

    I can see that frameworks like Wicket can be more secure because the client just gets opaque references to server side objects but that is at a big cost.

  • arhan

    As we mentioned before, it is not possible to cover all the frameworks in one go. ZK was never at the top in the survey results anyway.

    You could ask the same about any other framework that you probably like, and the answer would be the same.

  • shal

    +1 as well.
    Apparently Vaadin (based on GWT) is more secure because it supports using “security constraints in the deployment descriptor”? WTH!? This has nothing to do with the (front end) framework.

  • salk31

    Vaadin might have very good security because I believe it has an architecture like Wicket (don’t get me started on the downsides of that). Spring MVC, by default, lets you poke through at any part of the bean. GWT RequestFactory makes you declare things via interfaces. After that you can use Spring security with either.

  • David Nouls

    Is it a coincidence that you seem to favor frameworks that runs mostly on the server side, while JRebel is all about testing server side things ? My experience with GWT is that it is very easy to secure since you remove a lot of server calls. Every server call is subject to attacks. You end up with a thin RPC layer that needs to be secured, for which you can even use Spring security if you wish. But lot’s of cheaper options exists.

  • Subhro

    GWT is insecure bcoz its JS!!. .. very silly argument!!
    thanks for leaving it alone..

  • An0nym0usC0ward

    Those are all old-style Java web dev frameworks. The contemporary style od developing web apps is to build a set of services – where Spring MVC is still of interest – and build a client solely with Javascript, which is served as static content. You may have done your stats on legacy apps.

    Java services plus JS client Is fast, simple (if done right), secure (because you check security at the service level, where you decide what resources to provide access to for various roles, instead of deciding what operations to allow, if you build a RESTful API for your app), provides a service layer available to 3rd parties for free and a lot better (both unit and integration) testable than more traditional approaches.,It significantly cuts boilerplate code and moves a lot of logic and computational effort away from the server.

    Cutting boilerplate code and moving logic to the client is especially useful for making bug diagnostics easier (I guess everybody using Spring has seen huge call stacks populated mainly by proxies while debugging), and intrinsically improves the app’s speed. Simple, stateless, mostly idempotent requests (the way REST says they should be) simplify logic and improve readability (simply because the logic to read is a lot simpler).

  • Eric

    What about Dropwizard? It’s a great framework that forces you to care about operations.

  • John Waterwood

    The JSF security review is not correct!

    JSF has a couple of important security features that you have seemed to miss.

    There is both implicit and explicit support for CSRF see in short there’s an explicit token for stateless views or general usage. For normal views there’s an automatic CSRF protection via the view state ID.

    Another important security feature is that JSF checks that you can only postback that what has been rendered. So if you render a list with “a”, “b”, “c” and then try to be sneaky and send “d” to the server, it won’t be accepted.

  • Don’t think bringing out what UI options offered is relevant. As previous comments discussed client-side is HTML, CSS and JS (always has, always will) besides some developers nowadays the likes of @An0nym0usC0ward and I like to do it “properly”.
    The JS hatred thing is silly, JS is tested, is growing and maturing (more than Java) and mostly it IS the language of the browser. So simply wanna be a web-developer, go learn proper JS (GWT, Vaadin don’t cut it for me – they are just additional layers adding mostly complexities).

    One thing you forgot to mention, all of them need JRebel except for Play! which is a huge plus for me.

  • I agree with others that ZK might need to be added, really. I don’t think it would be *that* much behind Vaadin in popularity.

    Besides, Implementing a very straightforward REST application with JAX-RS at the server side, and something like AngularJS (or name any other JS framework) seems quite as contemporary as some other choices. AngularJS catches up with any of Vaadin, Wicket, ZK, at least on Google Trends:

  • John

    I 100+ % agree with your vision on this one. I’m on the same road. But it will take some time before it will be common practice in the market.

  • Dilshod Sultan

    Hi, people, what do you all think about Play framework?

  • arhan

    JRebel relevance wasn’t really considered. BTW, Grails can cope with hot updates too.

  • Dieter H.

    I don’t believe this at all. I’ve seen many, many web applications making your browser pretty much a JS fat client and I can’t say it’s very encouraging. Stuff like GWT that allows compile-time checks and unit testing of your JS is not so bad, but the fact is that larger applications like this tend to lock up quite easily, and as long as there is no uniform and large standard adhered to by every major player in the market, this will not be viable. That doesn’t mean I don’t support the idea, I can only hope a web framework will emerge that really sets the bar for corporate applications with a JS client, as this is really the best field of application for such a thing, but the fact is that at the moment, this doesn’t exist. Yet.

  • An0nym0usC0ward

    I’ve delivered a few not so small apps built as a service layer on the server plus a rich and fat JavaScript client for the browser. None of them was locking up the browser.

    Some of them were rewrites of apps written using other technologies. The new implementations were both faster to develop and faster at runtime than the PHP/Wicket/tapestry equivalent.

    As for GWT in particular, I dislike it, for a few reasons: its maintenance is increasingly bad, and the JavaScript it generates is inscrutable. If you discover a bug in the generated JavaScript (which is something that happens), there’s not much you can do, aside from starting to debug the JavaScript generator. Similarly, if you hit a performance bumper, there’s not much you can do – the generated JavaScript is difficult to influence in any way.

    Besides, (aside from the ugly side of it) JavaScript is a wonderfully flexible and expressive language. Why would you prefer your code to be written in Java, which is in no way targeted at a browser execution environment, when you can write in JavaScript, on top of frameworks which add many powerful and convenient features for the web app developer?

    As for a likely candidate of a framework to develop corporate JS apps, check out qooxdoo. Its target is specifically the type of apps that you mention.

  • arhan

    Let’s see, how ZK community is able to give a vote this time :)

  • arhan

    I wander how much ZK votes the survey gets this time:

  • Mark Sasler

    There is an alternative tool similar to GWT called Dragome. But this one is about compiling bytecode to js, and it also has UI components support. Things like Incremental compiling, Java 8, HTML template are already supported.

    And there is no need to wait to ECMAScript 6 to be standardized because it already allows use of dynamic proxies continuation (js yield), classes, lambda (arrow functions).

    Project URL:

  • Serban Balamaci

    The fact that you even recommend qooxdo(who the hell uses it besides 1&1 – the fact that you were forced to use it, does not mean you should inflict it on others) and that you group Wicket in the same area as PHP and Tapestry kinda lowers you credibility. People can write bad performance apps in JS as well as any other language.

    Everybody is jumping into “The contemporary style of developing web apps is to build a set of services” – give it a few years when you’ll no longer be the one creating the webapps and if successful the business will get complicated, someone new might need to come and do maintenance on these apps and god help him making sense of which change involves which other part – because he’s not working in a static typed language, he might not have inherited 80% code coverage-, but hey he might be a lucky guy saying all needs to be rewritten from scratch.

  • An0nym0usC0ward

    If you want to see who uses qooxdoo, browse their archived mailing list on nabble. I wasn’t forced to use it. I did a thorough research of what was available on the market at that time, and qooxdoo was the best choice to develop a web app with a team of people used to develop almost exclusively in Java.

    In the meantime, there are several other frameworks which you could use – ember, sproutcore, smartclient, you name it. Qooxdoo is still ahead of anything else, if you get to know it, IMO, but others have evolved hugely since that time. Qooxdoo just doesn’t have the marketing other frameworks have.

    I’d say you listening more to marketing hype than doing your own technical investigation of what you should or shouldn’t use lowers your credibility, not mine.

    I group Wicket, PHP and Tapestry together because they all do the same thing: generate markup on the server (granted, PHP can be used to implement services, but tapestry and wicket are specifically designed to generate the markup on the server). Generating markup on the server I call old style web app development. Anything JSP based falls into the same category. In fact, both server- and client-side libraries/frameworks that generate markup are IMO outdated – with HTML5 and the browser support there is for it nowadays, continuously replacing parts of the DOM from markup which needs to be parsed is impossible to be faster or more convenient than simply manipulating the DOM by mainly changing node attributes and only seldomly adding/removing nodes. The latter is what all client-side frameworks specifically targeted at rich single page apps rather than website scripting do.

    When you work with a loosely or dynamically typed language, and don’t have everything unit-tested, it’s your own fault. You can’t blame the language for the maintenance nightmare you create.

    Code coverage is a known bad measure for the quality of tests. When thoroughly practicing TDD, good tests are simply a side effect of what you do, and development speed goes up. If you refer to legacy code, you won’t get that code written in JavaScript anyway – JavaScript probably wasn’t considered a serious enough language to be used when that code was written.

  • Serban Balamaci

    “Generating markup on the server I call old style web app development…The latter is what all client-side frameworks specifically targeted at rich single page apps rather than website scripting do.”
    Guess sites like amazon, alibaba are not interested in the performance boosts you get for clearing the DOM attributes vs replacing as they seem to not have adopted what you’re saying – Non SPA for them – (hopefully someone from them might see this thread and change this).

    “Qooxdoo just doesn’t have the marketing other frameworks have.” – ah, that explains the meager 400 stars on github.

    “You can’t blame the language for the maintenance nightmare you create.” – actually with java I don’t even need to look at the unit tests to see what is going on. I just need to follow in my IDE which method is calling which and all the places where the method I’m about to change gets called.

    I cannot explain how grateful I am right now that I’m programming Java and my colleague is in sick leave and without prior knowledge to the business case, I was able to work out fast what his code was supposed to do.

    Anyway, I cannot prove my case yet and will not continue arguing, time needs to pass, current “trendy” apps and frameworks to mature and grow big, developers need to leave, people to replace and maintain need to be hired and then tell their experiences and opinions.
    JS frameworks from my perspective are in their infancy and as soon as they mature, grow past some certain level it’s dubbed as heavy and dropped in the favor of the next “fly-light” framework.

  • An0nym0usC0ward

    You said it right – Amazon and Alibaba have web sites, not apps (mostly).

    I would say the star count on github is definitely explainable by the lack of marketing – have you ever heard of qooxdoo before? Yet, you’re eager to trash it, without having tried it once, without even having looked at what the people actually using it say. Of course, Wicket, which is pure Java, fares much better: a whole lot 235 stars on github …

    As for qooxdoo’s trendiness: it’s already more than ten years old, still maintained and still highly appreciated by the small community around it (mostly people who don’t care about hype – and which regularly complain about the lack of marketing around it). A whole lot different history from GWT, which is another Java only solution …

    You can do the same following of method calls with JavaScript. Good luck, though, doing it with applications using clever runtime dependency injection when you stumble upon a method call to an interface method – only running through a debugger helps. Time spent in a debugger is mostly wasted time, once you start doing TDD properly. You don’t even notice how much so, before you try out TDD.

    But you go on using Java code to generate markup, if that makes you happy. I’ve done both (i.e. worked with plain JSP, Wicket and Struts, but also with qooxdoo, ext, backbone and a bit of angluar). I never ever want to go back to generating markup on the server, and I hate to use templates in JavaScript, even if it’s trendy atm.

  • An0nym0usC0ward

    An important principle of the Unix philosophy is to do one thing and do it well. I fully embrace this. As a consequence, a framework like Play does too many things for my taste.

    Besides, it creates lock-in – you can’t easily switch from play to something else, neither can you swap out just part of what play provides for another implementation (like plugging in Spring security, for example). But I might be wrong – I didn’t do any real project with play so far.

  • Mqurashi

    with reference to the following in the above comment ” its maintenance is increasingly bad, and the JavaScript it generates is inscrutable.” – being a GWT developer, I want to put my two cents across, any modern web application using GWT, uses the MVP/activity,places paradigm, which greatly alleviates the maintenance problem. As far as the JavaScript being churned out by GWT, being a Java developer (since you developed in GWT) it does not serve any purpose to to decipher the generated JavaScript (which is very optimized and complex), you need to go back to the Java code to modify. It is analogous to writing an app in C++ and debating how to understand or modify the machine code after compiling the C++ code.

  • An0nym0usC0ward

    Quote: ” it does not serve any purpose to to decipher the generated JavaScript (which is very optimized and complex), you need to go back to the Java code to modify” – that’s the theory, and, given that the JavaScript GWT generates is indeed not all intelligible, you’re forced to apply it. The flipside is that when something really goes wrong, and you have no clue why, you have to rely on the GWT devs to fix it, and this isn’t always timely – I don’t comment on the reasons, these are anyway irrelevant when a customer is breeding down your neck. In such cases, instead of being able to diagnose the problem, you usually build a clunky workaround. Even if GWT later fixes the problem, you never remove the workaround – it no longer pays off, unless you have to start working on that particular place in code again.

    Conversely, when you write C++, and the compiled code doesn’t do what you’d expect it to do, you _can_ look at the assembly code, and that’s especially useful if you compiled with debug info. Similarly, you can inspect the .class files created from your .java files – which can also include debug info. I’m not aware of a debug mode compilation for GWT.

  • This is amazing! Thank you.

  • LacViet

    I wonder how ZeroTurnaround rated a framework like JSF. Does it look at something like PrimeFaces? As far as ease of use goes, I don’t understand why GWT is on the same level as JSF. A bare bone GWT (100% client side) is easy to develop for sure but when you introduce stuff like MVP, UIBinder, EventBus, etc, it is definitely not straightforward. You have to do a lot of wiring on your own. With JSF, once you set up the configuration, all you need to do is develop the .xhtml and the backing bean. The rest is taken care for you by the framework. For the app type CRUD, how come all the frameworks get zero when it comes to framework complexity, documentation, and code maintenance? Is it because those are irrelevant or because all the frameworks are the same in those aspects? Take documentation for example, I think GWT would rank lower than JSF.

  • Remarkable things here. I’m very glad to see your article.

  • Much thanks! It is an amazing web site.

  • Thank you I love it!

  • Thanks for making your blog.

  • Cheap Shared Linux Web Hosting

    Fantastic!! Awesome website.

  • You’ve done a great job here!