the 2014 decision makers guide to java web frameworks

1All rights reserved. 2013 © ZeroTurnaround OÜ

SPRING MVC, GRAILS, VAADIN, GWT, WICKET, PLAY, STRUTS AND JSF

THE 2014 DECISION MAKER'S GUIDE TO JAVA WEB FRAMEWORKS

Give your next app a new framework!


INTRODUCTIONLET'S GET EVEN MORE CURIOUS... 1-3 CHAPTER IWHERE POOH AND PIGLET RANK FRAMEWORKS FOR TESTABILITY AND SECURITY 4-15

CHAPTER II FRAMEWORK RANKINGS BASED ON APPLICATION TYPE 16-38

CHAPTER III LET’S SEE THE RESULTS! 39-43

SUMMARY OF FINDINGSAND A GOODBYE COMIC :-) 44-47

TABLE OF CONTENTS


INTRODUCTIONLET'S GET EVEN MORE CURIOUS...

Our first report looked individually at the top 8 most popular Java Web Frameworks at a feature-by-feature level and scored them. We got some great feedback and added two more feature categories based on this commentary, plus analyzed the strengths and weaknesses of each framework against seven different application types (use cases)...


What did I read/miss in the first report report?

At the end of the first report we compiled the scores for each framework across all the features we looked at for the comparison. While this is interesting to look at, it does not make any suggestions as to which framework would be good to implement based on different end-user needs, as we haven’t introduced the real world problems/projects into the picture yet.

That’s where this report comes in: here we focus on the application and test use cases with varying application types to determine which frameworks are best suited for that app. Each application type will have different needs, requirements and functional priorities, so the feature areas we looked at in the first report and the two additional parts in this report will be scaled differently. This means we can suggest which framework(s) would be more appropriate than others for different types of applications.

Both reports are follow ups on the Java Web Frameworks section of our popular Developer Productivity Report. Here you can see which were the popular frameworks back in 2012. According to over 1800 developer responses, here’s what we found:

http://zeroturnaround.com/rebellabs/the-curious-coders-java-web-frameworks-comparison-spring-mvc-grails-vaadin-gwt-wicket-play-struts-and-jsf/

http://zeroturnaround.com/rebellabs/developer-productivity-report-2012-java-tools-tech-devs-and-data/


So what are the application types we care about in this report, you ask? We wanted to pick a selection of real-world application scenarios to gauge each framework’s effectiveness, so here they are:

• CRUD (Create, Read, Update, Delete) app - e.g. Evernote

• eCommerce app - e.g. Amazon

• Video/streaming app - e.g. Netflix

• Desktop application port - e.g. Salesforce

Once these application types have been weighed, we can then suggest/recommend a web framework based on its strengths, and report which we’d consider using on a similar project if we were to take it on from scratch. The Java Web Frameworks we will discuss will be the same as those looked at in our first report, as follows:

• Mobile app - e.g. m.google.com

• Multi-user app - e.g. Scribblar or Crocodoc

• Prototyping app - e.g. your own app in development :-)

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 2.3.15.1 JSF 2.2


CHAPTER I:WHERE POOH AND PIGLET RANK FRAMEWORKS FOR TESTABILITY AND SECURITYAfter we launched the first Java Web Frameworks report, we read your comments and feedback very carefully and as a direct result of your suggestions we added two more feature categories into the mix in addition to those in our first report--Testability and Security. We’ll rank all 8 frameworks in these two categories, and show the combined scores from the previous report. Enjoy!


SPRING MVCFortunately, Spring MVC has an official Spring MVC Test Framework and this makes it a very unit-testable framework. The Spring MVC Test Framework loads the actual Spring configuration through the TestContext framework and always uses the DispatcherServlet to process requests thus approximating full integration tests without requiring a running Servlet container.

There are a few things that give Spring favorable scores in this area:

• All controllers are just plain Java classes with annotations and ideally, with very little business logic code inside;

• Controllers may be tested using REST-based unit tests;

• Controllers may be tested using mocked unit tests (Mockito or EasyMock).

With various frameworks combined like Spring MVC Test Framework, JsonPath, JUnit and Mockito it is possible to write fast & short tests. The only downside in testing of Spring MVC is the separated view logic (JSP-s), that needs to be tested using some external tool like Selenium.

Score:

Reason: Built in, official test framework comes with Spring MVC, but needs external tools for some tests.

GRAILSGrails is a framework that encompasses the entire application stack--from the UI layer all the way down to the database--so the testing capabilities have to be sophisticated enough to provide confidence that everything works. Fortunately Grails provides exactly that; you can test everything starting from your controllers, response bodies and tag libraries all the way to your domain objects.

We found writing tests for Grails to be a breeze. Mostly because Grails itself does all the magical wiring, mocking and hooking things up to an in-memory database (if required) for a component under test. This leaves the developer to worry about writing the actual test and not the surrounding infrastructure (although it does not stop you from doing that if you want to!)

Score:

Reason: Every component is testable across your entire stack. Nuff said.

Testing… the last line of defense before throwing your code to the user-den! We have many tools available to help us with this (e.g. Selenium), but does a Web Framework interact with, embed or assist you with this crucial step?

Testability


VAADINVaadin application testing is split into three different categories: JUnit tests, TestBench browser based tests, and integration tests. JUnit tests will test all of the server side functionality; TestBench tests use real browsers with different versions, do regression testing and provide supporting screenshots; integration tests are required to verify that the application works in all supported servlets/containers. The JUnit and TestBench test cases can be directly integrated into com.vaadin.tests, and the integration tests can be outlined using tests/integration_tests.xml and tests/integration_testscripts/*.

There is some documentation on the Vaadin site that walks through how to create tests, how to run TestBench tests locally and how to perform integration tests. While the application test categories do cover everything they need to cover, Vaadin itself does not really provide anything extra that would surpass our expectations (or blow our minds) .

Score:

Reason: Separate test mechanisms for different categories, not comparably impressive as other areas of Vaadin.

GWTThere are few additional testing features built into the framework. GWT supports standard JUnit TestCases, GWTTestCases (subclasses of the JUnit TestCase), and Selenium testing. The additional GWTTestCase class does allow testing for code that requires JavaScript at runtime, a necessity for a framework that cross-compiles Java to JavaScript. It’s standard, simple to implement and expected.

Score:

Reason: Standard set of test features, nothing amazing.

WICKETWicket testing revolves around unit testing pages and components via the WicketTester class. This provides you with a testbed for your application, and once you provide the component or page under test you are good to go. You can perform actions on the rendered page/component in the testbed--i.e. clicking links and submitting forms, then verify the results of those actions -- whether some label has been rendered or some list contains some specific items. It even supports testing ajax components and component security. If the page uses some injected/autowired components, then mocking these out is obviously a necessity, but other than that we found the testing framework to be pretty easy and straightforward to use.

Score:

Reason: Specialized tester class, nice testbed for various application tests.


STRUTSTestability of Struts 2 is good (or, “very OK” in Estonian), as Struts 2 has also the Struts 2 JUnit plugin available. This makes it possible to write regular JUnit tests for Struts actions. Struts 2 JUnit plugin simulates a servlet container and thus there is no need to run an application inside the actual container.

There is even support for Spring and also it’s possible to use custom Struts configuration files when running tests.

We think that this kind of official and maintained test framework is really valuable to any framework.

Score:

Reason: Solid JUnit plugin and simulated servlet container, support for Spring adds value.

JSFJSF by default does not have any additional testing functionality built in, however tools like JSFUnit and Selenium can be used to properly test your JSF applications. The score here reflects that JSF is very middle of the road and is tested like a normal Java EE application.

Score:

Reason: No features baked in, testing is similar to that of a Java EE app.

PLAYPlay is kind of cool in the way that it approaches testing. Play by default uses JUnit and will spawn a new process for each test. A neat feature that we wish other frameworks would bundle is Play’s ability to mock a whole “application” for the test to use. For example, a tool like Mockito is required to stub out code or infrastructure, but Play has JavaTest with FakeApplication, which allows developers to spin up a real “fake application” with a real in-memory database. The score of 5 here represents Play’s awesome additions to application testing.

Score:

Reason: Useful additional features for testing your app, lets you spin up and mock your complete application.


SCORE SUMMARY - TESTABILITY


In the words of the infamous John McAfee, “Ignorance and confidence are constant companions”. Let’s be honest, when you know someone who is willing to look at security work items, you don’t fight them for it! It’s important that your overall solution not only supports security features but that it’s easy to implement and manage.

SPRING MVCSecurity of Spring MVC is pure awesomeness. It all relies on Spring Security and can utilize all the features Spring Security has. Spring Security features @PreAuthorize annotations, that make writing security rules easy and with minimum code. These annotations can be put on top of each Spring MVC controller method and it is possible to use SPEL (Spring Expression Language) at the same time.

As Spring Security works throughout the entire application, then also annotations set in other interfaces or classes work in the same way, blocking user access from web to some particular method.

Score:

Reason: Spring Security and @PreAuthorize annotations make it the best in the industry.

GRAILSGrails does not provide an authentication/authorization mechanism out of the box. The idea behind this is that users would generally use either Spring Security, Apache Shiro or the Authentication plugin to do this. The Authentication plugin however seems to only support authentication, and finer-grained control is left for the application developer to implement. On the one hand the security policy does make sense--when building an application that has important security considerations, you will usually use one of those. On the other hand, however, this does seem like a missed opportunity to also provide out more out-of-the-box, finer-grained and integrated security for framework components.

Score:

Reason: No out-of-the-box security features, would need to rely on Spring Security or another tool for security.

Security


VAADINVaadin does provide some ways to integrate security into an application and has a decent step by step walkthrough in their Wiki. You can secure the enterprise layer of your application using annotations, web and channel layers by declaring security constraints in the deployment descriptor, and pair Vaadin with form-based authentication. It’s a good solution and there is additional documentation available on their website. Even though Vaadin is based on GWT, because it is not as heavily reliant on JS and provides extra security checks on the Java side it qualifies as including reasonable security and so therefore gets a higher score.

Score:

Reason: Good documentation for setting up your own enterprise layer security, and ditches the reliance on JavaScript, like GWT.

GWT Because of the vulnerability of JavaScript applications, GWT dedicated a section of their website to discussing the major classes of attacks against any AJAX framework as well as possible solutions to each of these susceptibilities. It talks about implementing SafeHtml, rigorously following good JS programming practices, using RCP tokens introduced in GWT 2.3, wrapping JSON response string with JS block comments, and remaining vigilant. Google is upfront about the insecure nature of JS, and GWT, applications in general and repeatedly recommends staying well informed about security threats and, essentially, paying attention. It’s not a solution, but it’s something.

Score:

Reason: One CamelCased word: JavaScript.

https://vaadin.com/wiki/-/wiki/Main/Creating%20Secure%20Vaadin%20Applications%20using%20JEE6

https://vaadin.com/wiki/-/wiki/Main/Coding


WICKETThe way applications implement security has become pretty standard over the years and Wicket does not really diverge from this (which is a *good thing*). You have your usual built-in authentication and authorization mechanisms and setting these up for basic authentication is a breeze. Just extend your application from AuthenticatedWebApplication and your session from AuthenticatedWebSession, provide the appropriate implementation for your application, annotate your pages and components with desired roles/permissions and you are good to go.

What’s cool about Wicket is its component model and how the security mechanism expands to support it. Not only can you define authorization strategies with annotations for your pages, but you can even do the same for your components. If you need to hide that super-secret panel or disable some buttons for users without a specific role, go ahead! And for more complex security schemes you can always leverage the power of Spring Security or Apache Shiro (is anybody actually using that? :)) and hook that into your authentication or authorization mechanisms. Protecting yourself from motherly exploits is mostly covered by JDBC already, but Wicket's strongly typed Model and the Validator mechanism ensures that you get what you expect from users.

Score:

Reason: Excellent security spreads into Wicket’s component model and let’s you define authorization strategies with annotations.

PLAYThe Play framework adds support for secure routing and has authentication support through annotations. These features enable developers to harden and secure their applications without having to write horrendous if-blocks in every secure method and also does not limit developers to security through obscurity for routing in the application.

Decorating your methods with @With and @Check annotations are a very convenient, almost AoP approach to security included by default with the Play framework.

Score:

Reason: Default support for secure routing and strong annotation-based authentication.

http://xkcd.com/327/


STRUTSStruts itself does not try to implement yet another security framework. Instead, it hands it over to some other framework like Spring Security.

But still - the framework itself has been quite secure over time. Many legacy and also fresh projects still use and trust it because of the ongoing development and protection against various vulnerability attacks. When integrating Struts with Spring Security, it is possible to get a quite secure system with many security aspects covered.

Score:

Reason: Works best when integrated with Spring Security or another framework.

JSF JSF relies on the existing Java EE security features, so it is a reliable and stable security platform. However, this also means that the security aspects of Java EE/JSF are heavily reliant on design and development patterns and exception handling. JSF does have nice form validation that ties into bean method calls. JSF gets a 2.5 for security because it does get to leverage the Java EE platform, but does not offer anything on top.

Score:

Reason: Reliant on Java EE’s stable security features, but goes no further to add anything on.


SCORE SUMMARY - SECURITY


Rapid Application

Development

Framework Complexity

Ease of Use

Documentation & Community

Framework Ecosystem

Throughput/Scalability

Code Maintenance/

Updates

UX/Look and Feel

Testability Security Totals

Spring

MVC2.5 3.5 3 4 4 4 3 2 4 5 35

Grails 5 3 4.5 5 4.5 4 4.5 4 5 2.5 42

Vaadin 4.5 4 4.5 5 3 4.5 4 5 3 4 41.5

GWT 4 4 4 4.5 3 4.5 4 5 2.5 1 36.5

Wicket 3.5 2.5 3.5 3 3 3 4.5 3.5 4 5 35.5

Play 5 2 3.5 4 4.5 5 4 3 5 4 40

Struts 2 4 3 2.5 3 3 3 2.5 4 2.5 29.5

JSF 3 3.5 4 4.5 4 4 4 4.5 2 2.5 36

The ResultsNow we have the scores in for both Testability and Security, we can total these up with the numbers in our previous report, to get the following scoresheet:


Let’s now put this into a pretty graph so we can see how they fare against one another.

So we can see that Grails, Vaadin and Play are still our front runners, but this is hard to judge as many of the features may not be that relevant or important to your application. So, let’s move on and look at different application types.


CHAPTER II:FRAMEWORK RANKINGS BASED ON APPLICATION TYPE

Now we bring the scores for each of the frameworks into the real world. Scores on paper are meaningless unless we apply them to a real world example. So this section takes a look at seven different types of applications and reviews each framework based on their suitability for that style of application. If this were a quiz show, it would be the double money round.


What types of applications do developers make?

We tried to come up with all sorts of different types of applications, which led to more than one heated debate. Here are the application types we chose; let us know if we missed any that you think should have been added:

• CRUD (Create, Read, Update, Delete) app - e.g. Evernote

• eCommerce app - e.g. Amazon

• Video/streaming app - e.g. Netflix

• Desktop application port - e.g. Salesforce

• Mobile app - e.g. m.google.com

• Multi-user app - e.g. Scribblar or Crocodoc

• Prototyping app - e.g. your own app in development :-)

To whittle down the list of frameworks to recommend, we first needed to weight each of the features we looked at previously as High (multiplier of 2), Medium (multiplier of 1) or Low (multiplier of 0), based on how important the feature was to the success of the application. the scores, showing full results, highlighting the top three and recommending the frameworks we’d look into if we had to code an app of each type.


App Type: CRUD

This use case focuses on a typical CRUD (Create, Read, Update, Delete) application. These applications form the backbone of data storage on the internet. An example of a CRUD application that one would be sure to find in the ZT offices is Evernote, which is used to take, update, delete, and read notes in multiple locations on multiple platforms.

When creating a CRUD application, ease of use, scalability and throughput, code maintenance and testability should be your focus. You don’t want to use a framework that is so complex that you have to leap through fiery hoops in order to get or modify the data you want. You also want code that is easy to reuse and update when you add mountains of data to a couple of shiny new databases. But most importantly, you want to be able to make sure that your code is actually doing what you want it to do--accidently changing the new nuclear launch code to “p@ssword” isn’t going to make your boss too happy.

Feature Ranking

Ease of Use H

Throughput/Scalability H

Testability H

Security M

Rapid Application Prototyping M

Framework Ecosystem M

Framework Complexity L

Documentation & Community L

Code Maintenance/Updates L

UX, Look and Feel L


Rapid Application

Development


Ease of Use


Framework Ecosystem


Code Maintenance/

Updates

UX/Look and Feel


Priority M L H L M H L L H M

Spring

MVC2.5 0 6 0 4 8 0 0 8 5 33.5

Grails 5 0 9 0 4.5 8 0 0 10 2.5 39

Vaadin 4.5 0 9 0 3 9 0 0 6 4 35.5

GWT 4 0 8 0 3 9 0 0 5 1 30

Wicket 3.5 0 7 0 3 6 0 0 8 5 32.5

Play 5 0 7 0 4.5 10 0 0 10 4 40.5

Struts 2 0 6 0 3 6 0 0 8 2.5 27.5

JSF 3 0 8 0 4 8 0 0 4 2.5 29.5

The Results: CRUD


The two frameworks that came ahead of others for this application type--Play and Grails--are there because of their higher-than-average scores in ease of use, throughput and testability. The excellent framework ecosystem and available component libraries also helps with putting these above the competition.

Vaadin came third and is trailing quite a bit with other candidates which were left out of the top three. It is a little bit ahead of SpringMVC and Wicket thanks to a high score in rapid application development and ease of use while the other two have it beat in terms of testability.

Note: Throwing Spring into the mix, we find that the scene changes quite a bit, and the “combo punch” award for this application type actually goes to GWT in conjunction with Spring. GWT by itself did not score high at all, mostly due to its poor security and testability scores. Adding Spring on the backend and GWT on the frontend however makes it rise to the challenge with those aspects improved and blasts past the others with its excellent scalability, ease of use and rapid application development scores.

2 31

Our Analysis: CRUD


Feature Ranking

Framework Ecosystem H

UX, Look and Feel H


Security H

Framework Complexity M

Ease of Use M

Code Maintenance/Updates M

Testability M


Rapid Application Prototyping L

App Type: eCommerce

Oh, what would we do without these apps? To be sure, eCommerce applications have driven much of the growth of the internet, so that now you can order anything from music to tires over the web. An eCommerce application must be stateful and secure, while also maintaining the flexibility to adapt to multiple formats, like mobile and low bandwidth. There is also another consideration with eCommerce applications, whether your development team wishes to write everything from scratch or leverage an existing eCommerce platform like Oracle’s ATG or Hybris. Examples of eCommerce applications are Amazon and Apple’s iTunes or App stores.

When building an eCommerce app you want to focus on scalability, security and the UX. Your users should be able to easily navigate through and feel comfortable with the look of your site, including the site itself and it’s mobile and low bandwidth adaptations. It should be very secure; it’s an eCommerce app after all and will be handling order and payment information. In addition, to handle the application itself you want to use a solid framework(s) of medium complexity that is flexible and full-featured, but isn’t impossible for developers to learn, manage and thoroughly test.


Rapid Application

Development


Ease of Use


Framework Ecosystem


Code Maintenance/

Updates

UX/Look and Feel


Priority L M M L H H M H M H

Spring

MVC0 3.5 3 0 8 8 3 4 4 10 43.5

Grails 0 3 4.5 0 9 8 4.5 8 5 5 47

Vaadin 0 4 4.5 0 6 9 4 10 3 8 48.5

GWT 0 4 4 0 6 9 4 10 2.5 2 41.5

Wicket 0 2.5 3.5 0 6 6 4.5 7 4 10 43.5

Play 0 2 3.5 0 9 10 4 6 5 8 47.5

Struts 0 4 3 0 6 6 3 5 4 5 36

JSF 0 3.5 4 0 8 8 4 9 2 5 43.5

The Results: eCommerce


After an arduous scoring process, the frameworks with feature sets that best match to an eCommerce use case are Vaadin, Play, and Grails. All three of them are strong with throughput/scalability, security, and all try to provide a usable ecosystem without reliance on too many other tools. Other than the three high priority metrics, there are several medium priorities as well. Users want their eCommerce experience to look nice and not be reminiscent of GeoCities or Tripod, so a good UX or look and feel is important as well. Vaadin applications look beautiful out of the box, and Play and Grails can look great as well with a little more work.

Traditionally, eCommerce and other security-conscious applications would have relied more on Spring or Struts. Spring’s security additions are fantastic and when paired with lower scoring frameworks, like GWT, the combination may even score higher than any other framework on its own.

It is also worth pointing out that three other frameworks were only a small gap from the winners. Spring, Wicket, and JSF were only 3.5 points from third place. This leads us to believe the eCommerce use case is well understood and most major frameworks at this point would work equally with a few standouts.

2 31

Our Analysis: eCommerce


App Type: Video Streaming

Feature Ranking

UX, Look and Feel H



Ease of Use M


Testability M

Security M


Framework Ecosystem L

Framework Complexity L

One of the largest eaters of bandwidth on the internet now due to video streaming, at the forefront of this use case we have applications like YouTube and Netflix’s Watch It Now. These applications are typically stateful only for credentials or history tracking, after that the bulk of the application is stateless streaming. These applications are high-bandwidth and typically are available in multiple formats, while also being smart enough to lower quality to meet bandwidth constraints.

When building a video-streaming app, the main considerations that we have is the throughput and scalability as well as the UX for a good look and feel. The reasoning behind this is pretty self-explanatory, with thousands (possibly millions) of videos in the application’s video library and the huge numbers of those are being streamed concurrently by a large user-base, keeping the server load per-user as low as possible becomes high priority.

UX, look and feel also becomes important for the overall success of the application. Making the application appealing to look at and as easy as possible to use for the customers ensures that the application rises above its competition and gets people coming back to it for more.


Rapid Application

Development


Ease of Use


Framework Ecosystem


Code Maintenance/

Updates

UX/Look and Feel


Priority M L M L L H M H M M

Spring

MVC2.5 0 3 0 0 8 3 4 4 5 29.5

Grails 5 0 4.5 0 0 8 4.5 8 5 2.5 37.5

Vaadin 4.5 0 4.5 0 0 9 4 10 3 4 39

GWT 4 0 4 0 0 9 4 10 2.5 1 34.5

Wicket 3.5 0 3.5 0 0 6 4.5 7 4 5 33.5

Play 5 0 3.5 0 0 10 4 6 5 4 37.5

Struts 2 0 3 0 0 6 3 5 4 2.5 25.5

JSF 3 0 4 0 0 8 4 9 2 2.5 32.5

The Results: Video Streaming


The two aspects we rank highly here are UX, look and feel and throughput/scalability, and there are a couple of contenders here that stick out straight away. Clearly, Vaadin and GWT possess great qualities when it comes down to the look and feel and the throughput, but JSF and Grails are also very close contenders in these areas. Play performs extremely well in the Throughput/Scalability section, naturally, but is let down by it’s UI score.

So, what lets each framework down? Well, JSF drops points on Security and Testability, but a lot of this could be caught up by the surrounding Java EE implementation it would sit in, so is a good option. Grails and GWT are both let down a bit by Security, particularly in GWT’s case, which also suffers from lack of Testability. That leaves us with Vaadin and Play which perform well in the remaining categories and take the top two spots.

There is another way though! We could supplement the deficiencies in some of the frameworks by bringing in Spring’s security features, which when added to GWT particularly benefits the application. You would of course need to pull out some of the vulnerabilities in your app that uses GWT, but this is an interesting combination and makes it a real contender. Similarly, Grails could do something similar, although you’d have to offset the complexity cost of using another framework for an increase in security.

2 31

Our Analysis: Video Streaming


App Type: Desktop App Port

Feature Ranking

Security H

Code Maintenance/Updates H

UX, Look and Feel H


Ease of Use M

Throughput/Scalability M

Testability M




One of the more interesting use cases to come out of 24/7 connectivity available to the average user is desktop ported applications. These applications are typically heavy, native code that then gets ported onto a “cloud” platform. Examples of these are Google Docs (to replace Microsoft Office) and SalesForce (as opposed to Microsoft Dynamics).

These kinds of applications are aimed at office workers as an alternative to desktop applications. Given the nature of businesses, the security aspect becomes very important in establishing trust. You are no longer in control of what happens with your document or customer database, since it is not on your local machine anymore, so having faith in your data “on the cloud” being safe and usable only by people with proper credentials becomes essential.

The other aspects that we found important for us were Code Maintenance and Updates as well as UX, look and feel. The UX, look and feel has to be familiar to the end user and make it comfortable to cross the gap from the desktop app to the “cloud”. The framework of choice should be flexible enough to develop this kind of familiarity for different desktop app types.


Rapid Application

Development


Ease of Use


Framework Ecosystem


Code Maintenance/

Updates

UX/Look and Feel


Priority L M M L L M H H M H

Spring

MVC0 3.5 3 0 0 4 6 4 4 10 34.5

Grails 0 3 4.5 0 0 4 9 8 5 5 38.5

Vaadin 0 4 4.5 0 0 4.5 8 10 3 8 42

GWT 0 4 4 0 0 4.5 8 10 2.5 2 35

Wicket 0 2.5 3.5 0 0 3 9 7 4 10 39

Play 0 2 3.5 0 0 5 6 6 5 8 37.5

Struts 0 4 3 0 0 3 6 5 4 5 30

JSF 0 3.5 4 0 0 4 8 9 2 5 35.5

The Results: Desktop App Port


One of the main things that developers need to be concerned with while writing ports of desktop applications is the user experience, look and feel. Vaadin is a standout here because it enables developers to make beautiful, rich UI easily. Wicket and Grails are not too shabby, but they really shine in other areas. Namely in security and the maintenance phase of the application. All three of these frameworks also have to ensure they are capable of high throughput and scale well. Nothing destroys user experience more than a slow or crashing application, this use case is supposed to replace native desktop applications after all.

The runners up were Play, JSF, and GWT. JSF is great for user experience as well, with a huge component library and Play has great themes. GWT is fantastic for UI, but the real shortcoming was in security.

Many of the practices around hardening a GWT application are based in the JavaScript world, which is nowhere near as secure as the rest of the frameworks’ environments.

There is a combination that would beat Vaadin: Spring + GWT. If developers rip out all of the faulty or lower-scoring security features of GWT and replace them with the Spring Security framework, they now have a great component library that enables them to make beautiful, secure applications easily. Then developers can also take advantage of the client-side processing of JavaScript which will further enable gains in performance and scalability.

2 31

Our Analysis: Desktop App Port


App Type: Mobile App

Feature Ranking

Security H

UX, Look and Feel H

Throughput/Scalability M


Testability M



Ease of Use M



More and more consumers are using mobile versions of their favorite web applications and services on their mobile devices. This presents a decision to be made by any architecture team, do you write a native mobile application for each platform or do you make your existing applications support mobile browsers? There are pros and cons of each answer, in this use case we will discuss the second option, formatting an existing application to mobile browsers or light web services. One example of these applications is Google’s m.google.com.

Mobile applications are a little different than traditional web applications, instead of only having to code against multiple browser version, you also now have hardware constraints reminiscent of the age of 1024x768 vs 800x600. It is also a lot harder to verify the security features of a website or application when on a mobile platform, which raises security as a priority for the developers.

The unifying feature of every successful mobile application is a great user experience, with a snappy and well-organized look and feel. That is why we are rating UX as the most important feature of a framework for mobile development.

Also, it is good when a framework provides a possibility to develop and maintain API-s (REST endpoints) that can be used by native mobile apps.


Rapid Application

Development


Ease of Use


Framework Ecosystem


Code Maintenance/

Updates

UX/Look and Feel


Priority M M M L L M M H M H

Spring

MVC2.5 3.5 3 0 0 4 3 4 4 10 34

Grails 5 3 4.5 0 0 4 4.5 8 5 5 39

Vaadin 4.5 4 4.5 0 0 4.5 4 10 3 8 42.5

GWT 4 4 4 0 0 4.5 4 10 2.5 2 35

Wicket 3.5 2.5 3.5 0 0 3 4.5 7 4 10 38

Play 5 2 3.5 0 0 5 4 6 5 8 38.5

Struts 2 4 3 0 0 3 3 5 4 5 29

JSF 3 3.5 4 0 0 4 4 9 2 5 34.5

The Results: Mobile App


Although it is possible to develop good REST-based API-s with Spring MVC, it is still hard to build nice and shiny mobile UI-s with it. Also, Struts has its own strong place in the world of Java web application development, but it does not offer any security features out of the box and building RESTful API-s is not easy with it. Definitely higher scores went to frameworks that provide facilities for building nice UIs (important in mobile) and also to those that enable to have a good usable REST endpoint development features. Vaadin has TouchKit which makes it easy to develop mobile apps on it as well.

Security is important in mobile apps, so the huge winners here were the ones who had good security features, like Spring, Wicket and Play. Mobile apps need to have nice looking user interfaces and it turned out to be the winning point for Vaadin, GWT and JSF.

Rapid application development was a weakness for all frameworks that we reviewed. It is not good at all for this app type because many new mobile apps are mostly developed by startups or during hackathons. Not getting initial MVP (minimum viable product) done in a reasonable time results in not using the framework at all. And as mobile apps are conquering the market right now and their market share expands even more, then it may happen that some other framework, with very easy rapid application development capabilities, kicks in.

2 31

Our Analysis: Mobile App


App Type: Multi-user App

Feature Ranking


Code Maintenance/Updates H

UX, Look and Feel H

Security H


Ease of Use M

Documentation & Community M

Testability M



Concurrent usage of an application can be a challenge, is not unique to web applications, however the ways in which you present the ever changing state of your application to your users can lead to either a great user experience or a confusing mess. A great example for great user experience in this app type is a whiteboarding application, like Scribblar or the collaborative PDF markup app Crocodoc.

Multi-user applications have a lot of necessary requirements. A positive user experience is the end goal, and with many concurrent users working with the same application its necessary that your application can handle it. A good UX and throughput/scalability fall onto the very important end of the scale--keeping the server load per-user low will ensure stability and speed. A good UX will keep users coming back, so it needs to be easy to use and, well, pretty. The look is the representation of your brand; beyond everything else, your UX is what’s going to be judged first.

Your application also has to be easily maintained and updated, and like with any application that is handling multiple users, and those users’ information, there needs to be a lot of security. Secure information leads to happy users that continue to use your application.

http://www.scribblar.com/

https://crocodoc.com/


Rapid Application

Development


Ease of Use


Framework Ecosystem


Code Maintenance/

Updates

UX/Look and Feel


Priority L M M M L H H H M H

Spring

MVC0 3.5 3 4 0 8 6 4 4 10 42.5

Grails 0 3 4.5 5 0 8 9 8 5 5 47.5

Vaadin 0 4 4.5 5 0 9 8 10 3 8 51.5

GWT 0 4 4 4.5 0 9 8 10 2.5 2 44

Wicket 0 2.5 3.5 3 0 6 9 7 4 10 45

Play 0 2 3.5 4 0 10 8 6 5 8 46.5

Struts 0 4 3 2.5 0 6 6 5 4 5 35.5

JSF 0 3.5 4 4.5 0 8 8 9 2 5 44

The Results: Multi-user App


Building a multi-user app can be intimidating--you want your users to have a positive experience, so choosing a solid framework is very important. Our top players were Vaadin, Grails and Play, which is not too surprising. Vaadin took the gold by a pretty decent amount; considering how it scales easily, it’s easy to maintain and update, has a wide variety of UX options that can be easily maneuvered between, and provides additional security features. It’s versatile, well-rounded and fairly easy to pick up.

Grails and Play followed closely with similar scores. Grails fell a little short on security, mostly because it was built to be paired up with another framework like Spring Security, Apache Shiro or the Authentication plugin. It doesn’t include much extra out of the box support. Play, in contrast has a slightly lower score because of the framework complexity (the learning curve is a bit steeper than is ideal) and its shortcomings in UX.

Unlike Vaadin, the component aspect of the framework isn’t well supported and Play applications generally utilize LESS CSS and CoffeeScript mixed with templates instead of the CSS and JavaScript leveraged by traditional Java web applications.

GWT and JSF fell just short of the top three for fairly similar reasons, mainly because of their framework security additions or, rather, lack thereof. Wicket on the other hand might have made it into the top three if it wasn’t for its shortcomings in throughput and scalability.

What’s very interesting is that GWT plus Spring Security would not beat, but comes close to, Vaadin’s score of 51.5. Taking advantage of GWT’s component library and the benefits, especially speed and scalability, paired with Spring phenomenal security, and you can see GWT become a real contender. Grails is in a similar boat; with the added security benefit of Spring, Vaadin has some real competition.

2 31

Our Analysis: Multi-user App


App Type: Prototyping App

Feature Ranking

Rapid Application Prototyping H

Framework Complexity H

Ease of Use H

Documentation & Community H

Framework Ecosystem M

UX, Look and Feel M

Throughput/Scalability L

Code Maintenance/Updates L

Testability L

Security L

There are times in software engineering where a developer just wants to see something running to try to get an idea of the workflow of their application. Or maybe when using a UI or layout issues become more readily apparent with the architecture of the application. This is where rapid prototyping becomes essential in the software development process. Often times a wireframe simple version of the application is enough to meet the criteria and other times a slightly more functional prototype is required.

When creating a prototype of an application, the most important aspect is to get results quickly to prove or disprove a feasibility study. As a result, the Rapid application prototyping has to be a high priority. Ease of use and documentation are also high as when you’re writing a prototype with time constraints you don’t want to be slowed down by unnecessary gotchas or a lack of understanding due to lack of documentation.

Throughput/Scalability and code maintenance are more production issues, and while important later are not such a concern now, similarly with Security. Some of these categories will of course depend on which area the prototyping app is focused around and may differ depending on the details of the app itself.


Rapid Application

Development


Ease of Use


Framework Ecosystem


Code Maintenance/

Updates

UX/Look and Feel


Priority H H H H M L L M L L

Spring

MVC5 7 6 8 4 0 0 2 0 0 32

Grails 10 6 9 10 4.5 0 0 4 0 0 43.6

Vaadin 9 8 9 10 3 0 0 5 0 0 44

GWT 8 8 8 9 3 0 0 5 0 0 41

Wicket 7 5 7 6 3 0 0 3.5 0 0 31.5

Play 10 4 7 8 4.5 0 0 3 0 0 36.5

Struts 4 8 6 5 3 0 0 2.5 0 0 28.5

JSF 6 7 8 9 4 0 0 4.5 0 0 38.5

The Results: Prototyping App


When building a prototype for an application, the frameworks that came on top in our review were actually the obvious candidates--Vaadin, Grails and GWT. Most of these frameworks scored high for rapid application development (which is obviously something you want to be doing when slapping together a prototype) and that do not get in your way by being overly complex so that you would get lost in the details while trying to get functionality out of the door. The documentation is good and the learning curve for getting a basic level of proficiency for putting together simple applications is also something that works heavily in their favor.

Tailing the best choices are JSF with its exhaustive component library and Play, which (although looking like a solid choice for rapid development) falls behind of our top picks due to the steeper learning curve associated with getting familiar with it.

When looking at what frameworks would get a knee-up over the others when we add Spring to the mix, it seems like there are none. The reason for this is that while Spring does bring a lot of goodies to the table--security, transactions, web services to name a few--in addition to what is provided by the framework, none of these seemed important enough that would warrant adding a new level of complexity to the application stack for this kind of app.

2 31

Our Analysis: Prototyping App


CHAPTER III:LET’S SEE THE RESULTS!

It’s been a fun and eventful ride looking at each of the frameworks and we sure did have some great discussions/arguments while scoring each framework feature. But now comes the time to reflect on what we’ve seen in Chapter II and also how that changes the results from the original scoring table, back in Part I.


Spring MVC Grails Vaadin GWT Wicket Play! Struts JSF

Totals 35 42 41.5 36.5 35.5 40 29.5 36

The Overall Results

Really quickly, let’s remind ourselves of the scores of the combined results of the 10 feature categories from Part I (the previous report) and Chapter I of this report:


Grand Total

249.5 292 303 261 263 284.5 212 258

Average 35.64 41.71 43.29 37.29 37.57 40.64 30.29 36.86

Grails, Vaadin and Play are a very close top three, followed by a sizable gap and then a very close grouping of GWT, JSF, Wicket and Spring, with Struts falling behind. Now lets look at the average result scores across each of the app types. We’ll add all the scores in total and then average them out across the 7 app types:


Now, for the fun of it, lets plot the average scores based on Application Type against the original scores in the Feature categories to see how the frameworks scores based on features alone increases or decreases when we add application types into the conversation.


Totals 35 42 41.5 36.5 35.5 40 29.5 36

Average 35.64 41.71 43.29 37.29 37.57 40.64 30.29 36.86

From this table, and the graph summarizing it on the next page, we can see that , Grails is the only framework which seems to be worse off, albeit by just a small amount. The frameworks with the biggest increase seem to be Vaadin, and Wicket as well as some good increases by JSF, GWT and Struts.

The top three scoring frameworks were clearly Vaadin, Grails and Play throughout this report, but others, including GWT and Wicket were never far away. Wicket managed a 2nd place spot for Desktop Port Applications, and GWT broke into the top 3 with prototyping. That’s not to say others shouldn’t be considered of course. For instance when you use JSF with the more comprehensive Java EE capabilities, particularly security, it turns into a much more favourable prospect.


Spring MVC: For when you need an extra shot in your coffee

Picture the scene. It’s early on Saturday morning and your head is racing to remember what exactly happened the night before. You go to your local coffee shop and order your traditional red-eye coffee to fix the situation you find yourself in. You think “I’m already paying a few dollars for a cup of my favourite Java brew, for just a few more cents I’ll get extra shot of espresso and life will be a better place” -- So what’s this got to do with Spring? Well, Spring, (like a shot of espresso) can be used to supplement your choice of framework (or coffee - hope you liked the Java reference!) providing additional value, which your framework potentially lacks at little extra cost. True, there are extra complexities involved, such as learning and maintaining more than one framework, but the benefit often outweighs the extra cost brought by these complexities.

Spring’s tight integrations with the other frameworks is unique across the web framework ecosystem. Spring, back in it’s early days shined as the de facto web framework to use, created a vast community and user base. As a result, other frameworks made use of Spring’s tried and tested components and to become an option in a wider ecosystem which many others have also plugged into, none more so than Spring Security or Transactions support, which can be neglected by some frameworks.

So, the other frameworks gravitated to Spring, because of it’s large existing community and by providing integration, they can be used together to deliver a complete solution. Remember, a common scenario will be a user who already uses Spring and is perhaps considering another framework to plug the UI gap. With good integration, a solution can be found to provide tried and tested security with good UI providing a better joint solution than their individual component parts. As conversations with many developers have proved, teams are accustomed to using multiple frameworks during development, whether on the same project or at different times. So although Spring doesn’t blow anyone’s socks off by itself, when used in conjunction with another framework, the synergy abounds.


SUMMARY OF FINDINGSAND 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!


Summary

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:

TestabilityHow 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.

SecurityThe 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 I - WHERE POOH AND PIGLET RANK FRAMEWORKS FOR TESTABILITY AND SECURITY

the comic: http://xkcd.com/292/

http://xkcd.com/292/


CHAPTER II - FRAMEWORK RANKINGS BASED ON APPLICATION TYPE

CRUD (Create, Read, Update, Delete) app - e.g. EvernoteFor 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. AmazonHere 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. NetflixSimple 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. SalesforceSecurity, 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. m.google.comSecurity 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.


http://zeroturnaround.com/software/jrebel/trial/


This report is brought to you by:Simon Maple, Adam Koblentz, Sigmar Muuga, Cas Thomas, Sven Laanela, Oliver White, Ladislava Bohacova

Contact Us

EstoniaÜlikooli 2, 4th floorTartu, Estonia, 51003Phone: +372 653 6099

Twitter: @RebelLabsWeb: http://zeroturnaround.com/rebellabsEmail: [email protected]

USA399 Boylston Street, Suite 300, Boston, MA, USA, 02116Phone: 1(857)277-1199

Czech RepublicOsadní 35 - Building BPrague, Czech Republic 170 00Phone: +372 740 4533

http://zeroturnaround.com/rebellabs

[email protected]

the 2014 decision makers guide to java web frameworks

Software

report report

different application

popular frameworks

popular java web frameworks

varying application

frameworks effectiveness

java web frameworks

multiuser app