The latest expert opinions, articles, and guides for the Java professional.

Introduction: Comparison of Java MVC Frameworks

Introduction: Let’s Get Curious
Part I: Warming Up
1. Rapid Application Prototyping
2. Framework Complexity
3. Ease of Use
4. Documentation & Community
Part II: Going Ninja
5. Framework Ecosystem
6. Throughput/Scalability
7. Code Maintenance/Updates
8. UX, Look, and Feel
Part III: The Results
Summary of Findings

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

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.

Part I: Warming up

A web framework can be like Marmite… you either love it or you hate it! WAT? You’ve never heard of marmite? Never mind, you’ll probably hate it anyway! It’s really important to be able to launch yourself into a new language or project and be productive quickly. Learning a Web Framework is no different.

This section will compare and contrast each Web Framework for each of the following categories ranking them with a score out of 5 with our comments.

  1. Rapid application prototyping
  2. Framework Complexity
  3. Ease of Use
  4. Documentation and Community

This time, we’ll be using a new unit, which we will use to measure the coolness of each framework. We shall call the new unit the “Beaker”

Next, in Part II will look into some of the deeper topics as we go undercover, Ninja style.

1. Rapid Application Prototyping

Whether you’re using a Java MVC framework for the first time, or you’re an expert in all things framework related, it’s important to be able to develop quickly to prototype an idea or just try new things out. This section rates each framework for the ability to produce content from scratch with rapid results.

Spring MVC

If you’re looking for a framework to help you generate a application fast and clean, Spring really shouldn’t be your go to. It’s MASSIVE and hard to grasp if you’re just starting out. For a quick template, you can always download the Petclinic package and strip all of the unnecessary stuff out – but even that will take time, and you need to be able to tell what is necessary.

Spring Roo, a subproject of Spring that supports Spring Framework, Spring Security and Spring Web Flow, is Spring’s convention-over-configuration solution for rapidly building applications. It focuses on Java platform productivity, usability, runtime avoidance, lock-in avoidance, and extensibility via add-ons. It’s in the process of being expanded and has a lot of potential.

Score: 2.5/5 — Much preexisting Spring knowledge is needed. Plain JSP & Controllers do not provide out-of -the-box components and widgets that can be used.


Grails’ simplicity rocks. Next time we need to implement some small-to-medium CRUD application we’ll consider using Grails. The setup is very fast and scaffolding (code generation) saves a lot of time. Convention over configuration principle helps you to forget almost all of the configuration hassle.

Grails comes with a reloading mechanism out of the box, but it has some limitations (like it can only reload Groovy classes) and you may still want to use [Blatant Product Pitch] JRebel if a part of your project is in Java.

Score: 5/5 —  Top marks here. Scaffolding, conventions and hot code reloading, what else could you want?


The Vaadin directory is a component repository which provides existing components that users have implemented and contributed for others to use. If you choose to use something in the repository, you simply need to download the JAR and add it to your project and use it in your code straight away – template-tastic. At the time of writing this post, there are 365 components in the directory for you to use, one for every day of the year! You can’t get much more rapid than that ;)

Also, the design mode provides a drag and drop mechanism to add components and the code is generated for you, providing you with the exact layout you want, without even having to use the keyboard!

Score: 4.5/5 — Scaffolding and the Vaadin directory are both very impressive.

Your time is too valuable to sit around waiting for your code to redeploy. Seriously, imagine how much more you could accomplish if you choose to Eliminate Redeploys from your daily routine!


There are lot of pre-canned widgets for quick use but really anything you can do with JavaScript and the browser’s DOM can be done with GWT. If you prefer designing, you can also use GWT’s built-in Design Mode, an easy drag and drop interface with automatic code generation.

It’s no Grails, but the goal is to allow developers to productively develop web apps without being an expert in JavaScript, XMLHttpRequest, and various browser quirks.

Score: 4/5 — GWT is easy to create and maintain web apps widgets, and the built-in compiler takes care of efficiency and browser support.


With its clear MVC model, clean HTML and a wicked component module, you can create new applications with reusable components quick and easy. Wicket does use a model inheritance for it’s components, which isn’t great due to a bit steeper learning curve.

The existence of markup files for every component gives you a clear separation of concerns between the controller deciding what to display and the view that specifies how to display. This not only reduces development time but also gives your web designers the confidence to modify the HTML code without worrying about crashing and destroying everything. Win!

Score: 3.5/5 — HTML and component structure with no need for configuration files.  Separation of components and how they display.  Model inheritance for components.


Play is super simple to get started. The origination story of the framework essentially boils down to Java developers being envious of Ruby on Rails developers having a super fast prototyping framework. Play has a binary component similar to the Rails component of RoR, which is used for scaffolding and makes Play a little unconventional as a Java web framework. The Getting Started section of the Play framework documentation is a great basic tutorial and there’s a very low barrier to entry for developers to become at least moderately productive.

Score: 5/5 — Play has great documentation and the scaffolding works wonderfully.


Many devs see Struts as a legacy technology, so don’t expect fancy code generation in the place of boilerplate code. You need to configure a lot to start prototyping. An example project can be a good starting point. Something on the bright side: Struts has a Convention plugin, that enforces some convention over configuration and provides annotations to configure URL mappings and some other stuff. This should speed up things a bit.

Score: 2/5 — Lots of boilerplate code, no built-in code generation, no external powerful tools.


JSF is not fantastic for quick prototyping; code generation is not a built-in feature and prototype applications require just as much configuration as a full application. This is not really JSF’s fault, as it is reliant on the Java EE specification. JSF does have several useful Maven archetypes, however, that do provide a good starting point for a basic application. Prototyping can also be achieved with the vast array of sample projects available both online and bundled with many of the Java EE application servers. The biggest gains to productivity with JSF are the wizards available in most IDEs that generate most of the boilerplate code and configuration for you.

Score: 3/5 — The quick prototyping of JSF relies on the tooling around it. Maven and Netbeans provide archetypes and wizards to assist with getting started.















Spring MVC




2. Framework Complexity

This section is where we explore each framework’s construction. Here, we’ll discuss how many moving parts exist in each framework and how the complexity of a given Java MVC framework affects you. Do you really want to learn 10 technologies to use a framework? There are also other considerations when choosing frameworks, such as whether the extra features and benefits outweigh the extra complexity levied against frameworks for your application. Remember the old adage, “what you choose in development, you support in production!”

Spring MVC

Spring is the Mount Everest, the Pacific Ocean, the Stegodon of frameworks. The base Spring framework gives a solid foundation for over 22 subprojects, which increases with the scope of your application. These mature projects range from your “basic” fully functional MVC to Spring .NET and Spring for Android.

Spring MVC architecture is relatively simple, but still there are many layers and abstractions that are sometimes hard to debug if something goes wrong. And it is highly dependent on Spring Core.

Score: 3.5/5 — Spring scares away newbies and people who love simple and lightweight things. It is old and mature framework that has numerous amount of ways to extend and configure it – and this actually makes it fairly complex.


Grails’ MVC functionality is covered by Spring MVC; GORM (Grails’ Object Relational Mapping) is actually a facade for Hibernate. Everything is glued together with core Spring. All of these frameworks are mature, but heavy-weight and Grails adds another layer of abstraction on top of it. Grails also tries to be a full-stack framework by having it’s own console, build tool and a lot of plugins. All this can make things very complicated when it comes to debugging some nasty issue.

Score: 3/5 — Grails has all of the complexity associated wtih Spring and Hibernate, and adds another layer of abstraction to that.


The Vaadin Framework currently builds upon a flavour of GWT (lightly altered), which is a mature framework. The way you’d go about developing a Vaadin project is similar to GWT in the sense that you could create a hierarchy of components, but learning GWT is not a prerequisite to be competent at using Vaadin.

Score: 4/5 — Slightly more complex than GWT, as it embeds a version of it, but not enough to drop it any marks.


GWT is a pretty complex, if small framework for being so easy to use. You only have to worry about the Java code and what components you want to put where (or just drag and drop components using the Design mode and let GWT auto-generate all that code for you) and GWT cross-compiles that code into highly-optimized JavaScript that works across all major browsers.

Score: 4/5 — Pretty complex framework with an interesting execution that makes your life easy to develop with, either through code or through the drag and drop Design mode.


For being an MVC, Wicket can be fairly straightforward. It has clean HTML and a large library of components and a wide range of model objects that the components can use to retrieve or push data. However, the model inheritance can be pretty difficult to grasp initially and, while it increases code reuse, it reduces readability and is unnecessarily complex.

Score: 2.5/5 — A straightforward framework but with an unnecessarily complex model inheritance system that is useful but also difficult to grasp.


Play is quite a complex framework, and there are a lot of moving pieces. This makes sense given how robust of an ecosystem the Play framework provides. The framework comes with Netty, SBT, Akka, a Scala templating engine, and several other modules built in. Play emphasizes convention over configuration, so the framework is responsible for scaffolding much of the glue and configuration between the modules, which does cut down on the complexity experienced by you, the developer.

Score: 2/5 — Play provides an entire ecosystem instead of just a framework, which helps provide a lot of features. However, you do need to know something about Scala, which adds additional complexity.


Struts isn’t lightweight, but it isn’t overly complex either. When a user request comes into Struts, there is an Action (Struts’ term for a controller) to be performed and interceptors to be invoked before and after the action. Interceptors can manage logging, security, double-submit guarding etc. Official documentation states that “The default Interceptor stack is designed to serve the needs of most applications. Most applications will not need to add Interceptors or change the Interceptor stack.” The result of the action is rendered using chosen view technology. That’s the whole magic.

Score: 4/5 — Struts is pure MVC with a more or less straightforward architecture. No extra components that may add complexity.


JSF is incredibly complex, and that is the largest downfall of the framework. However, this is not JSF’s fault, this is due to the Java EE specification and the inflexibility of runtimes available. There are open source implementations of the JSF specification that do allow the use of non-Java EE containers like Tomcat, which cuts down tremendously on the complexity of having to run a full Java Enterprise application server (there are middle grounds though, like WebSphere’s Liberty Profile). The complexity does come with the benefit of access to the rest of the Java EE stack.

Score using JSF in a Java EE stack: 3.5/5 — When using the Java EE implementation of JSF, we must account for the complexity of the Java EE specification and running a full Java EE server, and one would be hard pressed to claim that the Java EE specification is not complex.

Score using JSF in an OS implementation: 3/5 — When using an OS implementation of JSF, we need to account for the complexity of the underlying framework that JSF is being run on top of.









Spring MVC










* Using Java EE Implementation score


3. Ease of Use

This section is all about how easy it is to pick up a framework for the first time and play with it, learn and get results. Think of it this way: if you gave one of these frameworks to a colleague, how many questions would you have to answer for them? The quality of documentation is always useful, but if you have to refer to the docs, have you already lost the battle?

Spring MVC

Spring is extensive to say the least and, as a result of that, is not particularly easy to just pick up one day and use. In order to take advantage, you need to know how Spring as a whole works, which is its biggest caveat. There are a lot of online tutorials and documentation pages as well as the Petclinic sample application that you could strip down and use as a base, but, overall, Spring is for building serious applications with solid foundations, rich user interfaces and a RESTful API, which makes it completely unnecessary for anything significantly simpler than that.

Score: 3/5 — Spring knowledge needed. Plain JSP & Controllers do not provide usable, out-of -the-box components and widgets.


Grails is designed to be a rapid development framework and rapid is a direct consequence of ease of use. It is advocating convention over configuration and doing it right. Extensibility is very simple when using plugins (there is a lot of them). One command in the console – and all the dependencies and configurations are managed for you.

One downside is that you need to get familiar with Groovy when you learn how to use Grails. But it shouldn’t be a big problem since Groovy is so Java-like anyway.

Score: 4.5/5 — Designed to be easy to use without any complex configuration, and Groovy should be more or less easy for Java devs.


Vaadin takes away the bulk of the GWT boilerplate code away from the developer, so that the code looks a lot neater. A great feature for ‘ease of use’ is the design mode. The design view allows us to drag and drop components onto a canvas and provide the logic code behind each component. The code which creates and sets up the UI for each component is created for us, magically, which we can see back in the source view. There are also many videos and documentation pages set up for new users to ease the new user learning curve. These really do take you by the hand and get you up and running. If you’re not using the design mode, the code can get a little hairy but not too bad. Also visualising your changes in the runtime can often be a bit slow.

Score: 4.5/5 — Super easy to use, particularly from the design mode. The Vaadin directory also helps. If you run into problems, you have plenty of support around to help out.


Whether you’re a coder or a designer, GWT has a good, fairly straightforward structure. The component structure for the coders out there are easy to work with and the widget options are numerous. The code is easy to read, modify and reuse, and if you are already familiar with client-side storage that is easy to work with as well, the only problem is, there’s so much of it. The code is incredibly similar to JavaScript (it does translate it to JavaScript at compile time after all) so if you’d need to be familiar with it to develop quickly.

GWT Designer, while not for everyone, is a powerful bi-directional Java GUI designer that lets you create user interfaces with tools for intelligent layout assist, drag-and-drop, and automatic code generation.

Score: 4/5 — Code is easy to read and write and there’s a Design mode is there for the non-coders.  Client side storage is a little hard to grasp if you haven’t used it before.

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.


Wicket keeps things simple – it lets Java developers do what Java developers do best: Java. There is a clear separation of markup (HTML/XML) and logic (Java code) which lets your Java devs worry about the Java and your web designers make changes to the markup templates of an application without worrying about breaking everything (and a huge sigh of relief just sounded from the design corner).

Wicket is also designed to do a lot of the heavy lifting for you, so boilerplate and repetitive code is kept to a bare minimum. View Components can be easily generated from metadata such as annotated “bean” classes and there are built-in utilities in extension modules that allow the developer to bind these components to back-ends.

Score: 3.5/5 — HTML and Java code focused, no need for silly configuration files.  Model inheritance can be a little hard to grasp initially.


Play is really simple to get started with, however it’s very complex for a developer to take full advantage. One of the best things about Play is the ability to go from zero knowledge of the framework to leveraging some of the more basic capabilities in less than 10 minutes. Features like scaffolding and native JSON processing are immediately available to even the most eager developer, while features like asynchronous calls through Akka Actors may require a bit more research into the documentation.

There are a few knocks against Play in the Ease of Use department; the most obvious learning curve issue with Play is integrating it with your existing build tools and environment. Play tries to provide an entire ecosystem by itself, which can make it very non-trivial to swap items for your existing pieces of infrastructure and tooling, using SBT instead of Maven or Ant for example. The other potential issues with Play in terms of usability are backwards compatibility with existing code bases built on previous versions of Play and Akka Actors. The Play migration guide is very comprehensive for migrating 2.0.x applications to 2.1.x versions of the framework, however migrating a version 1.x application to 2.x is not for the faint of heart.

Score: 3.5/5 — While simple to get started, the two things that really keep Play from being really easy to use are the complete backward incompatibility between versions and the requiring Scala to use templates.


Struts is definitely not the easiest to use. Let’s say you need to implement a new business spec with simple CRUD operation over an entity. You need to create actions with probably different action results, URL mapping/page navigation configurations in XML, form beans classes with their validation configurations in XML and finally, the view templates. Good luck with all that. Don’t forget that you need to make sure that all of the names match in classes/configurational files/views. Compiler won’t do that for you.

Score: 3/5 — Lots of classes/configuration files needs to be written for a single component.


JSF tries to provide an easy to use framework for creating reusable web components in your Java applications without a large learning curve. JSF 2.2 was recently ratified and released as part of the Java EE 7 specification. JSF is very easy to get up and running and often does not require extra downloads or configuration as the necessary code is bundled in any Java EE compliant application server. Assuming it’s not enabled already, getting JSF support in your application server can be as simple as enabling a checkbox. There are several great tutorials for JSF, some written by Oracle and others by third parties (MyFaces and others).

JSF can be a little confusing at times however, Java EE can be overwhelming and incredibly useful features can seem obtuse or obfuscated by poor documentation or easy to miss in the corpus that is the body of Java EE features. Documentation for JSF is often incredibly specific to certain tailored environments, and straying from the happy path often leads to frustration and woe for hopeful and aspiring Java EE developers.

Score: 4/5 — JSF’s tooling makes it easy to use and there are no external dependencies as long as you stay within the Java EE ecosystem, which JSF leverages well. There are also several built in components that provide tremendous benefit and some third party component libraries that look great.
















Spring MVC




Your time is too valuable to sit around waiting for your code to redeploy. Seriously, imagine how much more you could accomplish if you choose to Eliminate Redeploys from your daily routine!

4. Documentation and Community

For a good framework to continue improving, especially when not financially backed by a larger parent company (ehem, like VMWare, or the confusing new brand Pivotal), it’s important to have a couple things going for it. First, excellent documentation so that new users can quickly attain guru level easily, and secondly the willpower to not only establish the seeds of a community early on, but also to take a large part in interacting and fostering the community. Good examples of this are GitHub and NetBeans).

Spring MVC

Being the most used framework by Java developers definitely has its perks. There is so much information out there about Spring that a whole report could probably be dedicated to just listing and analyzing the available resources. The Spring website itself provides numerous tutorials both in video and written format, and it’s useful for beginners to the most advanced developer. There is a link to a GitHub repository with the Petclinic sample application – the go-to for a Spring MVC tutorial. Spring also hosts a blog on their website with articles written by the public as well as Spring team members.

The community is strong with this one. The Spring team actively encourages forking the Spring project repositories in order to make changes, fix bugs and add new features. They allow public access to their JIRA tracker in order to facilitate this. There are numerous Spring User Groups and Java User Groups that discuss Spring topics. Spring even holds an annual conference called SpringOne/2GX. The Spring hosted forums and SO are great places for asking and answering questions and the website blog and monthly newsletter keep developers updated on new technologies and accomplishments.

Score: 4/5Just look at these docs! You can get information about anything and these docs are mostly up to date. But if it comes to starting from scratch as a newbie (finding how-tos and tutorials), then the life will be harder.


There is a huge amount of information out there. Documentation section is actually a wiki, which can be modified by any logged in user It has an official manual, tutorials, screencasts, a sample app and more. If that is not enough, then look through 42k topics in the mailing list or search through nearly 12k grails-tagged questions on SO.

Score: 5/5 — Awesome documentation and a lot of extras, like screencasts. Big and passionate community.


Documentation? How about a book that you can use to swat an elephant! The Book of Vaadin is a must have reference manual for all your queries. It does cost to buy the book online, but you can download the PDF for free, or pick up the book at one of the many conferences the Vaadin folks sponsor. Online, there is also a bunch of documentation, including tutorials and demo videos, which are extremely easy to learn from and replicate. The community is strong with an active forum, blog, webinars, conference appearances and of course the community contributions on the Vaadin directory. StackOverflow also has many Vaadin questions, but it looks like for a quick response you’re better off heading straight for the Vaadin forums.

Score: 5/5 — Top class documentation, both online and in The Book of Vaadin. Video tutorials and demos are also impressive. Vibrant community.


GWT has surprisingly extensive official documentation. The majority of the new (beta) GWT project website is tutorials and framework documentation detailing everything from coding basics to using complex UI widgets and handlers. There are numerous FAQs, reference guides and overviews about pairing GWT with other frameworks. The site also has sections for books (dating back to 2006) written about GWT itself and paired with other frameworks (namely Vaadin), case study videos, sample projects, and presentations given at various conferences. Both the sample projects and presentations are available for download from the website.

Google also established a set of discussion groups and mailing lists that help users obtain support for technical issues and allow them to share their latest accomplishments and projects with the GWT developer community. Developers can benefit GWT by getting involved in general discussions on the GWT group and by becoming a GWT Contributor. As a Contributor, developers can share source code patches and updates to the project itself, expanding GWT’s features and functionality.

Score: 4.5/5 — Great up-to-date documentation, official and non, and active community.


Wicket has reasonable documentation and a somewhat active community. The Wicket website,, hosts a large compilation of available examples, sample projects, and resource links. The examples provided range from your basic “Hello, World!” to examples detailing specific Wicket framework features, such as fragments and AJAX. On the site there is a Wiki, Reference Library, and a list of books about Wicket. The resources are useful … and a little bit old.

The community is as active as they need to be, if not as extensive as other framework communities. The website lists regular Wicket bloggers with links to their websites – the owners seem to post every couple months about a variety of topics, but the list seems to be a little out of date with only a third of the listed bloggers having updated in the past three months. There is a more extensive list of bloggers on the Wiki. Beyond the blogs, Wicket set up an IRC for more direct support, there are a few dozen companies that provide commercial support, and there are a splattering of community meetups worldwide.

Score: 3/5 — The documentation is good and the community used to be very active, but recently it’s been slow.  The documentation hasn’t been updated since last year.


Play has a reasonably sized community with great documentation and the support of TypeSafe.

The community as a grass roots component as well with lots of great tutorials on the web, there are even some great and freely available screencasts introducing Play. The Play framework site has full reference level documentation available free of charge and even covers secondary documentation that covers the non-framework pieces of Play, like Akka and SBT.

The community is very active and there are several companies that base their main sites and applications on the Play framework. One of these companies is LinkedIn, and they independently publish documentation for the Play framework community. Bugs reports and feature requests are solicited from the community on a regular basis, which leads Play to have a robust and active community.

Score: 4/5 — Lots of great documentation from TypeSafe (Play) and external sources. Play’s full API is well documented and there are great tutorials that show off the scaffolding features of Play.


Struts documentation isn’t very organised. There are some guides, tutorials and cookbooks both on the official site and 3rd-party websites. After spending more time than you’d like searching, you will actually find a lot of resources: tutorials for beginners, guides on how to integrate Struts with Spring/Hibernate/%LIB_NAME% and detailed examples on how to use different Struts features. The community is big enough, considering the age and popularity of the framework, so you won’t be let alone with your problem. But the amount of dead links (e.g. to the “Wiki pages”) on the official website makes us a bit worried.

Score: 2.5/5 — Awful official documentation. User-written tutorials are slightly better.


JSF is unlike any other framework in our report for one main reason: it is fully supported and has a reference implementation from Oracle. Unlike the other frameworks in our report, JSF has a top down community with Oracle at the head paying employees to write documentation and create samples and examples. While the Java EE specification is determined by the Java Community Process (JCP), Oracle has a large part in determining and supporting features present in the specification. There is still a community based on JSF and there are a few exciting alternative technologies built on JSF, namely the MyFaces, PrimeFaces, and IceFaces.

Unfortunately, much of Oracle’s provided documentation for JSF is built around Oracle’s reference implementation of the Java EE tooling stack. Unless you’re a NetBeans and GlassFish user, you’ll be stuck looking for 3rd-party documentation sources. This is not necessarily a bad thing, there is a lot of great documentation available for JSF outside of Oracle’s sphere of influence, however it may not be as comprehensive and cover all of the features you want from the Oracle documentation. A simple search for JSF 2 tutorial on your search engine of choice will get you some great links, also youtube and other video sites have decent content.

Score: 4.5/5 — JSF has fantastic documentation provided by Oracle and there are tons of great books and online content from third party sources. The only downside of the documentation from Oracle is the reliance of their IDE and Application Server. Requiring Netbeans and Glassfish is definitely a detriment to the documentation and tutorials.












Spring MVC








Part II: Going Ninja

It’s time to Go Ninja and look more at the results of what your Web Framework will leave you with in your runtime.

This section includes what you now need to deploy into your runtime to run your web application, how it would perform under the pressure of heavy load and multiple users, as well as how it looks and how rich the UX experience is.

We’ll now focus on the remaining four categories:

  1. Framework Ecosystem

  2. Throughput/Scalability

  3. Code Maintenance/Updates

  4. UX, Look and feel

Keep reading, we’ll soon be able to tell you which framework, on paper, we think is the most awesome!

5. Java MVC Frameworks Ecosystem

The framework ecosystem covers how extensive the framework is in itself, it’s functionality, it’s build infrastructure and it’s integration with others. Very often, an large ecosystem can mean increased complexity, but not always. This section also depends heavily on user needs, which we will discuss further in the next report.

Spring MVC

Spring MVC’s ecosystem is well-developed. As it is based and dependant on the Spring Framework itself, it can benefit from tools like Spring Roo and Spring Tool Suite IDE. There are no problems with Maven dependencies as everything is available in a public Maven repository and also from SpringSource’s own Maven repository. There are 3rd-party solutions like MyEclipse for Spring, which includes scaffolding capability for Spring MVC.

Score: 4/5 — Still some very useful parts of the ecosystem are commercially available and this makes it not available for everyone.


Grails is a full-stack web framework, not just MVC. It contains a lot of stuff out of the box, but luckily, it doesn’t enforce it. Don’t like the built-in build tool? No problem, you can integrate with Maven or Ant. You’ve started using some NoSQL solution like MongoDB or Neo4j? You can remove Hibernate from underneath the GORM and exchange it with MongoDB/Neo4j.  You want to add caching or security capabilities? There is a plugin for that! Actually a lot of them (OVER 900: that provide a Groovy API for a lot of well-known Java libraries. And they are super easy to install – just add compile ":lib_name:lib_version" to your build script.

Score: 4.5/5 — Grails is a full-stack framework, but many provided parts can be replaced, and there is a big library of plugins


Vaadin doesn’t really provide an ecosystem as such. But does allow for it within the Vaadin Directory. For example, let’s say you wanted to use Hibernate with Vaadin, you’d need to download the plugin, and you’re ready to go. There is integration advice and documentation around how you can integrate with Spring, Flex, Liferay, Maven, but not much else. Ultimately, because the ecosystem doesn’t exist out the box, when you need to expand your application your complexity will grow as you support the different technologies and their integration.

Score: 3/5 — Can only go so far with integration, but is not an ecosystem out-of-the-box by any means.


GWT allows you to quickly build and maintain complex and highly-performant JavaScript front-end apps in Java. The GWT SDK allows you to write your AJAX apps in Java and then cross-compiles the code into JavaScript that works across all major browsers. The SDK supplies a core set of Java APIs, libraries, app server and the compiler, and you can also mix in your own JS code and existing JS libraries.

Score: 3/5 — GWT SDK with a core set of Java APIs, libraries, app server and compiler. Works well alone but better with others, and is not an ecosystem out-of-the-box.


Wicket is a full-featured framework that allows you to create reusable components and build up from those components in your projects to come. It is a server-side framework that has great AJAX support built into it and makes building pages with AJAX components a breeze. If you are a JavaScript fan, you can use your favorite client-side JS library to do things and then have Wicket server the data in any required format.

Score: 3/5 — Wickets gives you a full MVC with AJAX support, but plays well with others rather than standing alone.


Play really shines in this category, as it is bundled with SBT (Simple Build Tool) for building, Netty for a non-blocking networking I/O, Scala is used as a templating engine, and Akka is included for asynchronous operations. Play, unlike many Java web frameworks, includes a binary that is used for scaffolding of your applications. The Play framework is an all-encompassing ecosystem solely developed to increase developer productivity while minimizing the dumbing down of capabilities or shortening of feature lists.

Score: 4.5/5 — Play provides everything you need to develop, run, and test your applications. The only real downside is Play’s reliance on Scala for templating and SBT.


Struts doesn’t enforce anything else than just itself. You may choose from a variety of template engines, build tools, ORM implementations, dependency injection frameworks. There are some plugins ( that can help you with integrating Struts with other technologies. If there is no plugin, then most likely there is a user-written tutorial out there somewhere.

Score: 3/5 — Another pure MVC that is ready to be integrated with other technologies.


JSF’s ecosystem includes component libraries such as Richfaces, OmniFaces, Primefaces, IceFaces, ADF Faces as well as the extension points, including PrettyFaces, GMaps4JSF and Mashups4JSF. The real value however is being part of the Java EE specification. JSF can be easily added to your existing Java EE environments and immediately receives all of the benefits inherent in the Java EE ecosystem. JSF can be leveraged on non-EE containers as well, with open source support from the Apache Foundation with their MyFaces implementation of the JSF specification.

Score: 4/5 — Because it is part of the Java EE specification, JSF receives all of the benefits and tooling of Java EE. That includes great IDE support and a lot of functionality built into the application servers.







Spring MVC












6. Throughput/Scalability

What you choose in development will need to be supported in production. Throughput and scaling are very important factors as you don’t want to bottleneck your application because of a framework decision. This category takes a look at what each framework has to offer to help you application when there are more users and requests than lines of code!

Spring MVC

Spring applications are meant to scale as Spring is used in large-scale applications worldwide. It contains necessary components for parallel processing and solutions like EhCache can be attached easily to scale memory. Spring Batch enables to build multi-threaded apps, partition applications and do bulk processing.

Spring apps can be modularized and different modules can be set up on different hosts. These components can talk with each other using JMS (Java Message Service) for example.

Score: 4/5 — There is wide variety of options how to scale apps using in-memory caching or dividing applications into different parts and connecting them with messaging.


Grails is an abstraction over Spring and Hibernate. Are those two scalable? Yes. Will this extra layer negatively impact the throughput? Unlikely, it’s all Java bytecode in the end. Still not sure? Read the Testimonials and Sites sections on the Grails’ website to see what kind of big and fast applications are build using Grails.

Score: 4/5 — Standing on the shoulders of giants – Spring and Hibernate.


As Vaadin relies so heavily on it’s GWT implementation, it leverages many of it’s positives (while trying to reduce the pitfalls). One of the advantages is the way in which GWT turns Java code into JavaScript. Why is this an advantage? Well, JavaScript runs in the browser and so as an environment scales, the server back ends don’t run all the logic, the clients take a large portion of it. Does Vaadin add any complexity to the scaling nature of GWT? We don’t believe so.

Score: 4.5/5 — Takes the scaling value from GWT and doesn’t add any additional scaling complexity.


If GWT was created for one thing, it was created for scalability. GWT code looks similar to many other standard toolkit APIs but with asynchronous calls (though a Remote Procedure Call infrastructure is provided to make it feel like standard event processing). The included compiler is what makes GWT stand out.

The Java to JavaScript compiler hides browser differences so you can focus on the actual code without worrying about adapting to different browsers and browser versions; it analyzes your source for unreachable code and removes it; and it eliminates method call overhead by inlining code. So, whether you have a small app or a big app, GWT will analyze and compress the returned JavaScript to be as efficient as possible no matter what browser you’re using.

Score: 4.5/5 — GWT’s included compiler that converts Java to JavaScript is magic for efficiency and scalability.


Wicket comes up a little short on the scalability front. Because it is a server-side framework, building the resulting page to be rendered to the user is done on the server and will thus consume server resources. It may not be the best option for applications where throughput is a top priority. However, it does have great AJAX support so Wicket could be used to render the initial page skeleton and have the rest of the communication with the server done via AJAX requests. Just make sure you configure your components to use AJAX if possible.

Score: 3/5 — Wicket works well for scalability if that is your goal when developing the foundation; otherwise, you’re better off using another framework that doesn’t have such a huge server resource consumption problem.


Play is incredibly scalable with high throughput. When coupled with the native integration for Akka actors, Play enables ridiculously performant asynchronous applications ready your Big Data needs. The notion of Future really enables Play to deliver on the promise of high concurrency and large datasets. Built in JSON support assists with integrating into other web services, enabling your code to be more modularized. Even Netty is non-blocking, which should cut down on useless waiting.

Score: 5/5 — Play uses Akka actors to be incredibly scalable and allow for high throughput. It does require learning how to use Akka.


Similarly to Wicket, Struts is a fully server-side framework. If you need more power for rendering the pages, then adding more servers to your cluster should be the answer. Luckily, Struts-jQuery AJAX plugin can make things a bit more asynchronous.

Score: 3/5 — No extra features that would improve scalability, other than AJAX support.


JSF applications can be performant, but really the performance gains come from clustering Java EE application servers. JSF itself does not provide explicit support for asynchronous calls, and relies on the Java EE specification to provide @Asynchronous and @Schedule annotations on the business logic EJBs.

Score: 4/5 — JSF provides annotations that are useful for job management with asynchronous calls.









Spring MVC











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.

7. Code Maintenance/Updates

Releasing you first version of code is the start of a wonderful journey of support, migration and new features. But how wonderful will that journey actually be? Will you be in a state where each project, using the same framework is configured differently? Planning for the future saves regretting for the past.

Spring MVC

Unlike the convention-over-configuration frameworks like Grails and Play, Spring MVC is heavy and dense despite taking advantage of the Model-View-Controller paradigm (Spring -> MVC <-). Updating and code maintenance is manageable if you’re already familiar with the intricacies of the framework and the project itself, but if you’re just diving in it can be a little overwhelming and slow going. But still, annotations enable to access all kinds of data in a declarative manner and this way, not much hacking is needed.

Score: 3/5 — Annotations are cool. They make life so much easier. Multiple ways to configure. Server side logic is easy to maintain but if comes to managing layouts and complex UI-s, it will be hard.


Just like the Play framework, Grails follows the convention-over-configuration principle, which makes maintenance easier. It enforces the project structure, thus most Grails projects look very similar. Groovy is less verbose than Java, thus less code need to be written. Hot code reloading makes the updates even more fast.

Score: 4.5/5 — Convention over configuration makes most of Grails projects look similar and if you are new to Grails – those conventions are easy to grasp.


So you want to change your Vaadin implemented UI but don’t want to change all the code in the world? Well, it’s not actually that bad, as many of the Vaadin components share many of the same characteristics, so if you wanted to switch from one component to another to capture input slightly differently, e.g. from a drop down list to a table of elements, it is surprisingly easy to do so. Very often it’s just a case of switching the class names around and maybe touch up one or two attributes and you’re good to go. Code updates can be quite slow, but JRebel integration is supported.

Score: 4/5 — Very good code reuse and component class hierarchy model, as well as switchable themes, shame it can be a little slow to update.


Being a component driven framework with a JavaScript-esk feel (it does compile to JavaScript after all) gives GWT a leg up on manageability and extendability. The code is easy to step through line by line and the availability and use of widgets allows a lot of code reuse. The automatic code generation through the Design mode is relatively organized and manageable as well.

Score: 4/5 — Very easy to maintain and update but automatically generated code from the Design mode can be hard to deal with.


Maintaining and updating code written for the Wicket framework is manageable and further helped by its execution of the convention over configuration methodology. The user components are based on inheritance and so are easy to debug, and the separation of style and logic means you can reuse a lot of your code and easily change the look of your web application without worrying about breaking the logic. HTML templates are easy to modify and errors come out early and clearly.

Score: 4.5/5 — Separation between HTML and Java allows for easy design changes without ruining existing logic.  No additional configuration files to deal with.


Code written for the Play framework is readable, as the framework follows a convention over configuration methodology that makes most Play framework projects look very similar in structure. This enables a developer to switch between applications without having to relearn the ecosystem for every project. The built in templating system also helps with the readability of code and can help create incredibly powerful and useful applications with lower Lines of Code counts. Play also has reloading of components and code built in which definitely helps cut down on time during the development phase of your applications.

Score: 4/5 — The convention over configuration aspect of Play leads to readable code, however the reliance on Scala does limit the readability to Java-specific developers.


Similarly to Spring MVC, maintenance should not be a big problem if you are familiar with Struts, but if you are new to the project, the learning curve can be steep. Even if you have experience with Struts, your new project may have a bit different structure and different configuration.

Score: 3/5 — Lots of different aspects to grasp. Two Struts projects can also look pretty different.


JSF projects leverage existing design paradigms such as Model-View-Controller to help enforce maintainability and readability. The framework itself does not have any features that particularly impact readability or maintainability. One of the stated goals of JSF is to help developers produce better code, but we do not see how they facilitate that.

Score: 4/5 — JSF leverages pure Java syntax in well-defined paradigms to create projects that any standard Java EE developer can step in and work on.















Spring MVC




8. UX, Look, and Feel

One of the most important features! What does the end user see, what is their experience of the application and UI? It’s pointless having the most amazing framework if the user experience is poor. The scores in this section also reflect how hard it is to create the UI with each framework.

Spring MVC

Spring MVC has a very rich feature set to develop and maintain code on the server side, but despite its extensivity it still doesn’t provide any rich framework for building awesome interfaces. No matter, you can still use it to write a solid backend and use another framework intended for building your UI. It’s versatile and plays well with others, so, really, the world is your oyster.

Score: 2/5 — No re-usable and nice components. But templates are easy to manage and create.


Do you need something complicated in the UI? Then either create it yourself in GSP with a possible addition of JavaScript/CSS or find a specific plugin that will do the job for you. Most certainly you won’t have to implement a date picker yourself, but be ready to fine-tune your layout CSS by hand. The auto-generated project skeleton has some basic view templates and CSS to start with. Plugins include integrations with jQuery and Twitter Bootstrap, rich UI AJAX components and a bunch of other things.

Score: 4/5 — Plugins provide integrations with popular JS frameworks and include many rich UI components.


Vaadin themes are collections of layouts for components, custom images and CSS, The whole idea to have different themes is to separate the logic of components from their look and feel and being able to switch themes without changing the logic. A theme follows a specific directory layout, and with them you can specify the css for the default Vaadin components or create custom components.

One of the coolest things about themes is that you can inherit from existing themes, so when you need just to tweak a bit, you don’t need to create a monster or hack themes installed by default. This means you can inherit from a theme and just add the missing pieces.

Score: 5/5 — This is what Vaadin was made to do! Its themes are a joy to use, and the results are very slick and pleasing to the eye.


GWT is very versatile when it comes to customizing and awesome-izing the look of your web apps. Because it’s a component-based framework, you can modify the look of your app at any time without breaking the logic. This separation also helps the application render more quickly, consume less memory and make it easier to tweak during edit/debug cycles.

GWT allows you to associate style sheets with your project in order to further customize it. The GWT theme style sheets are associated with the application as a whole – there are three options: Standard, Chrome, and Dark. You can also create an application stylesheet(s) where you can define specific styles for your application in CSS.

Score: 5/5 — Theme hierarchy allows you to modify individual component look without break overarching application theme which allows for a great deal of easy and pretty customization.

Your time is too valuable to sit around waiting for your code to redeploy. Seriously, imagine how much more you could accomplish if you choose to Eliminate Redeploys from your daily routine!


Like the other component based frameworks, Wicket gives you a large selection of out-of-the-box widgets to choose from. If none are to your liking, the website links to a handful of good websites where you can find more Wicket Components, HTML, CSS and JavaScript to further customize your web application. It’s a very versatile framework and plays well with others, so the UX choices really fall to you!

Score: 3.5/5 — UX is pretty mediocre out of the box (solid 90s look) even with its large library of pre-canned widgets, but paired with a good framework your apps can look awesome.


Play has some basic themes, however there is not widespread support for component libraries built in. Play applications usually leverage LESS CSS and CoffeeScript mixed with templates instead of the CSS and JavaScript leveraged by traditional Java web applications.

Score: 3/5 — Nothing mind-blowing, but Play has some enhancements over standard JavaScript, CSS, and XHTML by providing LESS CSS and CoffeeScript mixed with Scala templates.


When you’re using Struts, most of the UX is up to you. Grab a front-end developer to write your HTML, CSS and JS and fill it with your data using JSP, Velocity or Freemarker templates. Struts has 3 predefined themes: simple, xHTML, and css_xHTML. They determine the HTML generated out of the JSP tags. New themes can be created and existing ones can be modified. Struts supports AJAX out of the box, thus there is no need to write JavaScript by hand for it.

Score: 2.5/5No built-in or 3rd party components. Some built-in AJAX support.


JSF is great for development teams that want to create great full-featured UIs without having to become JavaScript masters. There are a lot of great components already in the catalog, and there are also fantastic additions to JSF to provide even more high quality components. IceFaces and PrimeFaces are two examples of great JSF catalog additions. With the advancement of these extra components, some of the web applications created with JSF are indistinguishable from their desktop counterparts.

Score: 4.5/5 — The library of built in components is very full featured and there is also an extensive 3rd-party catalog available.

















Spring MVC


Part III: The Results!

Now we come to the fun part! Let’s collate all our results and make sweeping statements about which Web Framework you should all be using, mocking those who are not using what we consider to be their best option… Kind of…

The Results

First of all, lets recap all the scores in each category for all frameworks. We’ve marked the (joint) winners for each category in blue:

Rapid Application DevelopmentFramework ComplexityEase of UseDocumentation & CommunityFramework EcosystemThroughput/ ScalabilityCode Maintenance/ UpdatesUX/Look and Feel
Spring MVC2.53.5344432

Interestingly each of the frameworks we looked at either wins, or jointly wins at least one category, apart from Spring MVC and JSF. Let’s see how this feeds into the grand totals:

FrameworkOverall Score
Spring MVC26

Well, there’s certainly no runaway winner, in fact, the top 5 are only separated by 3.5 points! But then a gap separates them from Wicket, Spring MVC and Struts. Vaadin and Grails just take the top spot, which seems fair, looking at how they stood up to our tests.

Grails came out on top for 5 of the 8 categories, doing particularly well around the Rapid application development, documentation and community with top marks. The only area it  struggled a bit with was the framework complexity category, mostly because of it’s reliance with Spring, GORM, Groovy and more adding layers and layers of abstraction.

Vaadin won 3 of the categories, and also got a 3/5 in one of the categories, but was typically matching Grails blow for blow through the competition. It excelled in its documentation and community category which is excellent as well as the UX, look and feel category, which to be fair is what Vaadin is all about.

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.

GWT wasn’t far behind, which you’d expect given how similar it is in functionality to Vaadin. In fact it matched it in all categories apart from 3, where Vaadin only pulled ahead by a half point in Rapid App Development, Ease of Use and Documentation and Community: arguably some good reasons that Vaadin was maybe created over GWT.

Interestingly, after mentioning that JSF hadn’t won any of the categories, it sits in 4th place, mostly due to it’s solid performance throughout, only dropping below a 4/5 twice, in Rapid Application Development and Framework Complexity. It’s worth mentioning that calling JSF a “web framework” is often debated due to it’s inclusion in the Java EE stack, so we’re glad to see it perform strongly considering it’s specific place in Java.

Play could have finished higher, but for the framework complexities and ease of use. It really isn’t a framework that is very easy to get up to grips with quickly. We use Play at ZeroTurnaround and this is certainly the vibe from the engineering team. Once you get used to Play you can create applications very quickly, but where it really excels is in the scalability and throughput.

Spring MVC, Wicket and Struts didn’t do particularly well up against the other frameworks. Spring did reasonably well in quite a few categories, but really fell short in the UX, Look and Feel category as well as the Rapid Application Development category. Struts was poor across the board as was Wicket, apart from one victory in the Code Maintenance/Updates category which really put it above Spring in the rankings.

In the end Grails and Vaadin are the big winners, followed reasonably closely by GWT, JSF and Play. There you have it. Now you can go home ;-)

Your time is too valuable to sit around waiting for your code to redeploy. Seriously, imagine how much more you could accomplish if you choose to Eliminate Redeploys from your daily routine!

Summary of Findings and a Goodbye Comic

Wow, you made it to the end! Or maybe you skipped to the end ;) Either way here’s the report summary in manageable byte-sized pieces.

For those of you pulling a TL;DR (too long, didn’t read), here is a sum up of each category we measured.

  • Rapid application prototyping

    • Here we see quite a range of scores, with Grails and Play coming out on top, due to the mostly to the scaffolding support. Vaadin was close behind and the Vaadin Directory of plugins is worth a mention. Spring and Struts really struggled here, with few out of the box components.

  • Framework Complexity

    • Vaadin, GWT and Struts prove to be the simplest of frameworks with fewest dependencies, while Play struggles, particularly with its reliance on Scala knowledge and SBT.

  • Ease of Use

    • Grails and Vaadin did well when it came down to the ease of use, particularly due to the configuration, and design mode. Spring and Struts again suffered, due to the amount of knowledge required to use and the amount of configuration required.

  • Documentation & Community

    • Grails and Vaadin again took top spot with their vibrant communities and extensive docs. Struts and Wicket have problems with their official documentation, so fared badly again.

  • Framework Ecosystem

    • Grails and Play both have good ecosystems, including build support all the way to tools and plugins. Spring MVC also has a good ecosystem, although some of which is commercial. Other frameworks are quite specific to their task, but do have integrations with other projects.

  • Throughput/Scalability

    • Play was easily the winner here as it’s features are so suited to scaling and throughput, supporting async applications with Akka actors. GWT and Vaadin also did well as their model is based around client side execution.

  • Code Maintenance/Updates

    • Grails and Wicket did particularly well with most config relying on default convention. Wicket also has a nice HTML/Java split which makes changes much easier.

  • UX, Look and Feel

    • Vaadin and GWT excelled here, with neat usage of customizable themes and the ability to inherit from existing themes. Presentation wise, they are both very easy on the eye. Spring MVC and Struts both suffered here, clearly not one of the goals of the framework.

So what does this all mean?

As with our Great Java App Server debate, not all frameworks are created equal. In the same way that comparing WebLogic with Jetty doesn’t exactly make sense to some readers, some of you will surely find issue with comparing Spring MVC, which is part of a much larger framework ecosystem, to Vaadin or Struts. Also, in reality you might choose a combination of frameworks, rather than just one, making use of the best aspects of each framework. This is why we are preparing a second part to this report, where will measure these same frameworks from the use-case perspective, thereby slightly muting the straight numbers seen in this report. After all, a large team of developers creating big enterprise apps might be prepared to spend more time getting set up with a more heavyweight framework rather than a hobbyist developer.

We’re hoping to hear from product or team leads from each other frameworks, so we’ll be able to hear some commentary from the horse’s mouth. So stay tuned for that, and be sure to reach out to us in the comments section below, or ping @JRebel_Java.

Read next:

Responses (135)

  1. Avatar  


    July 30, 2013 @ 9:52 pm

    Excellent article, But I´m not too convinced that Play was best on Throughput/Scalability because others frames can deploy on very strong Java EE Containers like GlassFish, JBoss,WebLogic, Wensphere,etc that are proven excellent on Throughput/Scalability.

  2. Avatar  

    Claudiu Ion

    July 31, 2013 @ 3:29 am

    don’ forget resin container

    the guys from here

  3. Avatar  

    Andrea Del Bene

    July 31, 2013 @ 11:46 am

    Don’t want to be self-referential, but the documentation for Wicket has been really improved and updated recently :) :)

  4. Avatar  


    July 31, 2013 @ 12:48 pm

    To master Play’s Scala based template engine is not a harder than learning every other template engine. Actually you don’t have to know Scala at all.

    You’ve counted Scala as a disadvantage several times in your comparison, but I think it is a really powerful and clean language, once you’ve mastered it. You can do so much more with so much less code compared to Java.

    Scala is not a disadvantage, Scala is a big win.

  5. Avatar  


    July 31, 2013 @ 1:05 pm

    This is the most useless Java web framework comparison I have ever red. Too generic, too subjective and biased. Nothing was said, document is full of generic boilerplate parts crowned by dusty score valuation.

  6. Avatar  


    July 31, 2013 @ 1:08 pm

    IMO that’s a subjective assessment. Since we used Play2 for our own projects, the developers acknowledge that scala templates certainly helped in many cases, however with its own quirks.

  7. Avatar  

    Adam Koblentz

    July 31, 2013 @ 2:52 pm

    I’d say that requiring Scala knowledge in a Java framework is a disadvantage. If we were discussing a PHP framework that required Ruby, I do not believe anyone would disagree.

  8. Avatar  

    Simon Maple

    July 31, 2013 @ 3:03 pm

    Sorry to hear you disagree so strongly. As our Rebel Labs team is mostly comprised of humans, the text will always be subjective and opinionated and I believe it makes for the most interesting and valuable of articles and reading. If you would like more in-depth information, we have posted more in-depth blog posts on most of the frameworks we discussed in the report on the Rebel Labs blog. The report is already 50 pages, or so, in size which many think is already very long. I suspect we wont see eye to eye on this one, but it’s not always right trying to please everybody :)

  9. Avatar  

    Han Zhang

    August 1, 2013 @ 7:38 am

    But for building a large app, code maintainability outweighs many other factors, no? So even Struts sits at the bottom of your list by scores, in reality, when building an app with a large number of fine grained features, limited developer resources, large number of users, which one do I pick? Struts. :)

  10. Avatar  

    Simon Maple

    August 1, 2013 @ 8:41 am

    Hey Han, Very good points. These are actually all planned for our second part of the report. These are merely the category scores. The second report will examine real world app types and weight the categories based on their requirements. This will then allow us to provide recommendations on an app type basis.

  11. Avatar  


    August 1, 2013 @ 8:50 am

    Though overall it is really a good article, but it lacks many aspects.For e.g at some point Author is talking Struts as legacy framework while there is already a new version of Struts derived from WW named as Struts2 while struts has already been declared close for development.

    For UI, i believe both STruts2 and Spring-MVC provides a lot of flexibility of use any view technology or use build in support .Struts2 already providing beautiful Jquery plugin which provides many Jquery powered widgets out of the box while author is talking about Ajax support which was based on deprecated DOJO plugin.

    I believe there are many real time factors which was not considered while doing this comparaion.

  12. Avatar  


    August 1, 2013 @ 12:03 pm

    This is no easy task to compare java web frameworks so this article deserves consideration as it does a good job to summarize some of them.

    But I clearly agree with the conclusion : you are comparing oranges with apples.

    Also, I miss some “real world” metric : maintanability, going mobile, going services oriented (i.e lots of small apps working together), testability

    I’ll wait the second part to tell you my full opinion ;)

  13. Avatar  

    Marc Sch

    August 1, 2013 @ 6:10 pm

    I agree, it’s way too generic. A more interesting comparison would involve building an advanced prototype and then looking at things such as performance, caching, lines of code etc.

  14. Avatar  

    Han Zhang

    August 1, 2013 @ 8:12 pm

    Simon’s talking about Struts

  15. Avatar  

    Yannick Majoros

    August 1, 2013 @ 8:44 pm

    Agreeing with some others here: I think there is too much bias in this article. Giving points is bound to be a problem.

    Something that isn’t addressed is the fact that most those frameworks are not part of any spec. I know it’s boring, but I’m convinced it *is* important for the long-term minded professional.

    Been using Struts and Vaadin in professional contexts. You always end up spending lot of time on implementation details, that are not part of any specification. Any problem with component X or feature Y? That’s how it’s implemented, you have to live with it. Maybe it will change in a new version (and break things).

    In contrast, JSF has multiple implementations and is well-specified. Any problem with component Z? Check the spec, you have some reference to have the bug corrected. Plus, nowadays, it’s equivalent in functionality. I don’t even get why I would think at using something else, that would roughly do the same, but without the standardization. That also makes big difference regarding documentation, e.g. the Book of Vaadin might look like a full documentation, but it just can’t compare to a full specification.

    Another thing that I always look at when using someone else code is typing. Vaadin, for example, is full of Object parameters, casting, string parameters, … Those things will break at runtime. JSF has still to evolve in this, but at least you can get your java code mostly type-safe.

    After years of having to deal with them, my general idea of those non java-ee frameworks is that they are the work of some uncontrolled volunteers, some of them creative but not led by engineers. The demo looks nice, but it requires a lot of knowledge of the framework only implementation.

    In contrast, I like the fact that Java EE (5, 6, 7…) is a powerful, well-engineered ecosystem that’s been maintained with a vision.

  16. Avatar  


    August 1, 2013 @ 8:55 pm

    Very good comment! But could you elaborate about bias? Bias towards what? Rebel Labs doesn’t relate to any of those frameworks business-wise, and the marks are given by individual devs – of course those marks are subjective. I would say that given the set of categories in which these frameworks are given the standings are pretty fair.

    Well, I wouldn’t give GWT that many points for UI, but yet again – that’s my subjective assessment.

  17. Avatar  


    August 1, 2013 @ 10:47 pm

    This is a nice review really, but difficult as well. You either have to be an absolute beginner in all frameworks and then test which one you get productive with first, or you have to be an expert in all of them.

    In the weeks before this report there were individual reviews of most web frameworks, but not for JSF. Did I miss something, or did you guys forgot to post it?

    Although I generally agree with the JSF scoring, I do have a few remarks about the text.

    >prototype applications require just as much configuration as a full application

    Simple prototype applications in JSF require no configuration at all. See for example this one:

    There is no required web.xml, no faces-config.xml or anything else. When deploying to a simple lightweight Web Profile server (e.g. TomEE) there’s not even any jar to download and put into web-inf/lib or any extra dependency to be put in a pom.xml. As the article shows, zip those files up in a war and copy it to an app dir of TomEE, GlassFish, etc.

    I’m not sure how much simpler things can become, especially for prototyping.

    >JSF are the wizards available in most IDEs that generate most of the boilerplate code and configuration for you.

    I’m really curious here; what boilerplate code and what configuration would that exactly be? (honest question) Is there any such configuration or boilerplate in the article I referenced that such wizard would generate?

    IDEs work great with JSF for auto-completion of tags, auto importing of namespaces, and to auto-complete and navigate into EL expressions, but I haven’t seen much JSF developers really using any wizards to generate configuration, since when beginning there’s simply isn’t any that’s needed.

    The complexity review is the only section in the report when I really disagree with the points raised. The text just doesn’t feel coherent.

    >JSF is incredibly complex, and that is the largest downfall of the framework. However, this is not JSF’s fault, this is due to the Java EE specification and the inflexibility of runtimes available.

    So JSF is complex because of the Java EE specification? What’s in Java EE that makes JSF complex to use then? Why are the runtimes inflexible? Inflexible with respect to what?

    >There are open source implementations of the JSF specification that do allow the use of non-Java EE containers like Tomcat

    This sounds a bit weird…

    There are ONLY open source implementations of the JSF specification, namely Mojarra and MyFaces. They both indeed run on Tomcat (and even on Jetty). The sentence seems to suggest that the “normal” JSF implementations are closed source, but if you look closely and know where to look, there really also are open source ones. This couldn’t be further from the truth really.

    >which cuts down tremendously on the complexity of having to run a full Java Enterprise application server

    I just don’t get this… I really don’t. What complexity of having to run a full Java EE application server? TomEE is a 25MB archive. You download it, unzip it, and start it. It’s exactly the same as you do with Tomcat! The same goes for JBoss, GlassFish, Resin… it’s every time just a download, unzip, run. Nothing more. Every modern container starts up in a few seconds (JBoss EAP 6.1 on my system is 1.5 seconds, TomEE is 2.something…).

    You guys at zeroturnaround did the application server report, so I guess you really should know this.

    In fact, as mentioned above, running the simple JSF app I referenced earlier is much less complex on any of the modern application servers than on Tomcat. With JBoss, GlassFish, Resin, Geronimo, Liberty, JOnAS, … it’s download, unzip, start, deploy those 3 source files. With Tomcat it’s download, unzip, start, look for JSF website, hunt jars, find right version, download, copy jar to web-inf/lib, deploy 4 (or 5) files. It’s not a super big deal of course, but it’s 2 extra steps compared to a Java EE server.

    > JSF is very easy to get up and running and often does not require extra downloads or configuration as the necessary code is bundled in any Java EE compliant application server.

    Is this a different person writing? It seems to contradict the earlier text. Though I naturally agree with this, it left me a bit confused here.

    >Assuming it’s not enabled already, getting JSF support in your application server can be as simple as enabling a checkbox.

    Isn’t Liberty the only server that requires this “checkbox” (an entry in server.xml)? I don’t think I’ve ever seen any other server requiring this, but I’m eager to learn what other one also wants this (if any).

    >Java EE can be overwhelming and incredibly useful features can seem obtuse or obfuscated by poor documentation or easy to miss in the corpus that is the body of Java EE features

    I agree with this point, Java EE needs to have more documentation that represents Java EE as the framework itself, not as a collection of the alphabet soup JSF, CDI, JPA, etc. For instance using CDI backing beans in JSF, with EL 3.0 expressions and Bean Validation constraints is really well integrated. You really wouldn’t tell most of the times you’re dealing with 4 separate specs. Yet indeed, core documentation often has to be looked up at 4 places.

    > Oracle has a large part in determining and supporting features present in the specification.

    This is technically true. Oracle is leading the JSF specification and has the ultimate say. Technically…

    In practice however the spec lead (Ed Burns) runs JSF in the most open source way possible. JSF was the first specification of Sun that had an open source implementation, the first one that had a fully public JIRA for community issues and where things were discussed openly on a public mailing list.

    If you follow the mailing list discussions a bit then it becomes clear how much the Mojarra developers ask for opinions and agreement of the non-Mojarra and non-Oracle people all the time. If you look at the features that made it into JSF 2.2 (see then you can see that many of them were community submitted ideas and many others were chosen based on community voting. At the start of JSF 2.2 I remember Ed Burns asking everyone to vote for their most wanted features in JSF 2.2.

    > There is still a community based on JSF and there are a few exciting alternative technologies built on JSF, namely the MyFaces, PrimeFaces, and IceFaces.

    This is perhaps not 100% correct. MyFaces is not an alternative technology build on JSF, MyFaces *IS* JSF. As mentioned above, it’s one of the implementations of the JSF spec (Mojarra being the other).

    PrimeFaces and IceFaces (please don’t forget RichFaces here ;)) are not really “alternative technologies”. They are component libraries. One of the major goals of JSF was to enable to existence of such collections of components (widgets, controls). They are not competitors to core JSF, nor do they specifically fix flaws in JSF that Sun or Oracle forgot about. The fact that they exist means that JSF succeeded with one of its goals; to enable a rich ecosystem of available third party components.

    >JSF’s ecosystem includes component libraries such as Richfaces, OmniFaces, Primefaces, IceFaces, ADF Faces as well as the extension points, including PrettyFaces, GMaps4JSF and Mashups4JSF.

    Nice enumeration here :) One tiny correction; though OmniFaces definitely has its share of components, it’s generally considered to be a utility library (like Guave for Java SE) and not in the same space as RichFaces, PrimeFaces and IceFaces. A bit of a larger correction is that ADF Faces is a bit of a different thing. There’s a regular component library called Trinidad that is derived from ADF Faces, but ADF itself is difficult to explain. It is a complete higher level framework where the UI part is kinda like a fork of JSF with many things added, but typically lagging behind the latest “normal” JSF. Better not touch this subject in a casual JSF review ;)

    > JSF can be easily added to your existing Java EE environments and immediately receives all of the benefits inherent in the Java EE ecosystem. JSF can be leveraged on non-EE containers as well, with open source support from the Apache Foundation with their MyFaces implementation of the JSF specification.

    This again sounds like “the other person” wrote it again. Good text and almost seems to contradict the earlier statements again. Just wanted to note here again that the Oracle implementation is also fully open source and also runs on non-EE containers.

    >JSF applications can be performant, but really the performance gains come from clustering Java EE application servers.

    It also performs quite well without any clustering involved, see this article:

    I like that you mention @Asynchronous can be a performance boost as well :) I don’t see this often being mentioned in (JSF) reviews!

    >One of the stated goals of JSF is to help developers produce better code, but we do not see how they facilitate that.

    I think the way Facelets templates works, with the template clients and such, and the way components are bound to backing beans via the concept of bi-directional EL expressions really helps to produce better code. It’s really an easy way to cleanly separate UI layout and backing data.

    Okay, the few remarks got a bit longer than originally anticipated, but I hope it’s useful ;)

  18. Avatar  


    August 2, 2013 @ 8:56 am

    Than saying that Struts is legacy framework is totally wrong assumption

  19. Avatar  

    Santosh Maskar

    August 2, 2013 @ 11:06 am

    I think you forgot mention the stripes ( which has gained popularity in terms of use from last 5 years.

  20. Avatar  


    August 2, 2013 @ 11:15 am

    Stripes is nice and we even support it in JRebel. But the report would not fit all the frameworks – there are 100500 of them in the wild :)

  21. Avatar  

    Yannick Majoros

    August 2, 2013 @ 2:55 pm


  22. Avatar  

    Yannick Majoros

    August 2, 2013 @ 3:03 pm

    Ok let’s not expand about bias (just my feeling) and say I just don’t think the review is objective. @henk53:disqus commented in details about jsf, exposing some random assertions which simply aren’t true. Same lack of objectivity for Vaadin, in my opinion: just asserting it’s quite easy to use with nice results out-of-the-box and giving it high scores without too much debate. Not my experience, I think this specific one is a real mess ;-)

  23. Avatar  


    August 2, 2013 @ 3:53 pm

    Fair enough. How about you take same categories and try rating ’em yourself, and then let’s compare, how will the results differ? That would be quite an interesting test.

  24. Avatar  

    Yannick Majoros

    August 2, 2013 @ 4:01 pm

    Lacking time, but why not if it’s not urgent. I could do some of the frameworks, not all of them. Still wondering if grades are relevant, though.

  25. Avatar  


    August 2, 2013 @ 4:06 pm

    Just pick a few. I’m planning to do that myself also, just to see how my personal preferences match the results from the team.

  26. Avatar  

    Han Zhang

    August 2, 2013 @ 6:00 pm

    Out of the ones in this comparison, I like Struts2 the most.

    It strikes a very fine balance between function granularity and abstraction. Most of the dish-washing type of work are packaged away into fine grained APIs, which live on its very flexible interceptor-based architecture. With OGNL and xwork’s validation, it takes away much of the tedious data conversion and validation type of work. The user data live in same object structure from JSP all the way to the database.

    It does have a learning curve looks like the shape of the square root. Once you reach the plateau part, you are extremely productive. The more I use Struts2, the more I appreciate what it offers. It’s the #1 MVC framework I will choose to use any day for non-trivial app with extremely limited developer resources and large user base requirements. I see its life in the next 10 years, definitely not a legacy framework at all.

  27. Avatar  


    August 2, 2013 @ 6:03 pm

    I was also wondering about author perspective. I am working with struts2 and Spring-MVC from quite a long time and i always prefer Struts2 due to flexibility and option to add my custom plugin as well interceptors stack

  28. Avatar  

    Han Zhang

    August 2, 2013 @ 6:18 pm

    Yep, agree struts2’s open and flexible core architecture is its most liked feature. Value stack, OGNL, validation, and xwork (command pattern) are my favorite features, among others.

  29. Avatar  

    Jevgeni Martjushev

    August 5, 2013 @ 1:20 pm

    We didn’t explicitly call Struts a legacy framework, but rather said that “Many devs see Struts as a legacy technology”.

  30. Avatar  

    Dani Pardo

    August 6, 2013 @ 5:13 pm

    After reading the article I cannot but feel quite sad: It’s just the amount of bloat, and the obsession for reaching architectural perfection that has lead us to frameworks so complex. Maybe we should get back to the basics, using plain servlets and jsp :)

  31. Avatar  


    August 8, 2013 @ 5:19 am

    Where is zk?

    I think for the ease of use it is the best. Practically no XML required if you want to code everything just in Java. Rich set of components.

    In my view that is a significant omission.

  32. Avatar  

    Luc Bourlier

    August 8, 2013 @ 9:17 am

    There an error in the result table on the last page. Play is the ‘winner’ in the Throughput/ Scalability category with a 5, but the scores of Vaadin and GWT with 4.5 are highlighted in blue.

  33. Avatar  


    August 8, 2013 @ 11:24 am

    As you can see the report features only a few frameworks. It would have been an enormously log PDF if every framework was included.

  34. Avatar  


    August 8, 2013 @ 11:26 am

    I advocate for NoFramework movement! Perhaps, one day, I will create a framework and call it “NoFramework” :)

  35. Avatar  

    Simon Maple

    August 9, 2013 @ 7:47 am

    Thanks for the feedback, we’ll update when we refresh

  36. Avatar  

    Simon Maple

    August 9, 2013 @ 9:08 am

    Is nobody going to comment about how cringe our trailer videos are? We’ll make them worse and worse if you don’t stand up and say something!

  37. Avatar  


    August 9, 2013 @ 11:42 am

    How it is possible to evaluate performance characteristics without real load testing and measuring? “Will my application perform will in production if it gets hit by Slashdot effect?” “You use Hibernate and Spring? Then surely it will! They are giants!”

  38. Avatar  

    omid pourhadi

    August 11, 2013 @ 10:49 am

    where is the Jboss Seam ?

  39. Avatar  


    August 12, 2013 @ 6:50 am

    Thanks for your hard work of making such challenge report.

    I am in the process to evaluate and choose web framework for my next project. This is why I read this article from beginning to end. However, I found the info from this article is not useful as I expected.

    My question is – how come the most popular web framework just get the second to bottom score in your ranking system recommended?! Your ranking system is not totally-unreasonable, but I have to say it is not as useful as it should be, since it is not helpful to us to understanding the fact. Either some of ranking values used are not accurate, or some more important factors missing over there.

    Anyway I think your survey result is the most valuable point in this report, since it shows the kind of result comes from the group intelligence of the java community. Thanks again.


  40. Avatar  

    Sudheer Avula

    August 12, 2013 @ 7:01 pm

    A very good write up on comparing web frameworks in different aspects….

    This is a very good source of information to conquer the maze of web frameworks. I could at least filter some of the frameworks based on the score.


  41. Avatar  

    Hisham ARagheb

    August 23, 2013 @ 10:34 pm

    I guess component based frameworks were not meant to be used when you have designers at all. Designers can’t cope with all component based frameworks rubbish syntax, they barely know the syntax of JSP and i think that was enough for them. That was why i hated JSF from the first time i used it since we had terrible problems with be honest, i don’t blame them at all since we the developers did really suffer from that extra layer of complexity and squinted our eyes when looking at any page contents

    Let’s be fair, programmers can play with html, css and js, but the opposite side can’t.

    That’s why i consider request/response frameworks to last while we should wait the death of all component based frameworks and i’m pretty sure that oracle/sun will dismiss JSF sooner or later.

    Come on, HTML is improving very fast, web projects are taking a steep steps toward mobile apps and rich client interface apps which is very difficult to achieve with component based frameworks. Component based frameworks are meant to be for freelancers or those companies who don’t have designers. It’s the programmer role to do every thing with such frameworks.

    In my opinion, Spring MVC is the best framework by the means of abstraction from the view and it’s easy to learn curve. I have also used struts 2 which was excellent but unfortunately it’s not adopted enough and very few documentation.

    I would suggest that oracle/sun should adopt struts 2 as its standard framework for the view layer and to stop wasting time on JSF.

    That’s my opinion according to practical experience

  42. Avatar  


    August 29, 2013 @ 3:58 pm

    So the only ones that I know (Struts and Spring) are the worst. Oh my!

  43. Avatar  


    August 29, 2013 @ 4:00 pm

    They aren’t the worst. Those just didn’t score high in this selection for these categories (which is also subjective).

  44. Avatar  


    September 4, 2013 @ 5:13 pm

    Come on, you don’t need to write form bean classes in Struts and you certainly don’t need to map that with xml.

  45. Avatar  


    September 4, 2013 @ 10:27 pm

    Could anyone suggest me best share hosting provider for java? thanks

  46. Avatar  

    Marteijn Nouwens

    September 9, 2013 @ 6:56 am

    Nice review. Note that I found 1 thing missing. Code maintenance and such. For an example. JSF el expressions do not enforce compile time checks of existing properties/functions. Whereas gwt enables this is a really good way. The code has to compile in java. This is an aspect in front end frameworks that is mostly overlooked. There used to be an option to compile the packaged war to check faulty jsp pages/properties. Does anybody know if that is possible for JSF :-)

    I do develop Gwt and JSF. But given a choice would go for GWT any time. A lot more possible.

  47. Avatar  

    Marteijn Nouwens

    September 9, 2013 @ 7:14 am


  48. Avatar  


    September 10, 2013 @ 1:16 am

    Nice write-up.

    One small nitpick; Vaadin does actually have a bit more overhead than GWT. In Vaadin all user interaction is sent to the server, as opposed to GWT where user interaction takes place client side.

  49. Avatar  


    September 10, 2013 @ 11:58 pm

    JBoss Seam development has been halted

  50. Avatar  

    Anıl Özselgin

    September 22, 2013 @ 5:21 pm

    Some Java frameworks are for developing modern web sites using cutting edge CSS, Javascript coding. Other framework are for creating enterprise application with no html coding. So you can’t develop a social network with JSF. You can create a CRM application for a bank with JSF but nothing with frontend complexity.

    We have two buckets.
    Bucket for enterprise applications: JSF, GWT and Vaadin. These are for applications with simple frontend needs.
    Frameworks for web: Grails, Play, Spring MVC, Struts, Wicket.

    I think that frameworks had to be compared seperately keeping that in mind.

  51. Avatar  

    Florin Marcus

    October 15, 2013 @ 10:27 pm

    I am reading such comparison for years and as much as I love reading them, I understand that you need to take them for what they really are: one (or more) talented software engineering is taking a dive into various technologies with the purpose of producing an article. From a “tutorial level” perspective . In reality, is highly improbable to find a person having enough in-depth knowledge about several frameworks, years of production experience with each, in order to draw a conclusion.

  52. Avatar  

    Dmitry [d9k]

    October 27, 2013 @ 10:37 pm

    I personally choosed Vaadin after reading, but it seems that catastrophic little amount of websites are using this framework.

    Only 3 sites out of top million!
    1 site out of 100’000!
    Zero sites out of 10’000…
    How would you comment it? Looks attractive, but why so unpopular?
    For example Play framework have 30/13/2 scores and GWT 207/34/14.

  53. Avatar  

    Dmitry [d9k]

    October 27, 2013 @ 10:40 pm

    Thanks for comment! I’m choosing right framework for having a try.

  54. Avatar  


    October 27, 2013 @ 11:33 pm

    imo, Vaadin is best suited for enterprise apps, not the websites.

  55. Avatar  

    Dmitry [d9k]

    October 28, 2013 @ 2:12 am

    What is the good choise if I would like to develop sites on Java?

  56. Avatar  


    October 28, 2013 @ 7:25 am

    As usual, the answer is – “it depends”. Spring and Struts2 are very good frameworks for building large websites. But this is my own subjective opinion – you should just try whatever you picked and learn from that. Maybe Vaadin is what you’re really looking for – just give it a try.

  57. Avatar  

    Dmitry [d9k]

    October 28, 2013 @ 8:19 am

    As far as I know Magnolia CMS is written on Vaadin.
    I think I’ll try it for websites development. )

  58. Avatar  

    enric jaen

    November 6, 2013 @ 1:27 pm

    Thanks for this inspirational article.
    Another issue I think should be addressed is the deployment facility. At the end, the application must be deployed at some platform. Questions such as which providers does this framework support? How much money does it cost? Is this provider a PaaS? and maybe others questions..

  59. Avatar  

    enric jaen

    November 6, 2013 @ 3:04 pm

    I just read about ZK and it’s impressive the amount of large companies using it

  60. Avatar  


    November 6, 2013 @ 10:17 pm

    This is about the same as for any other framework out there… It is very compelling to put as many frameworks into the comparison as possible, but you still have to cut at some point.. The report selected based on the productivity surveys that we have conducted in previous years.

  61. Avatar  

    Michael Mosmann

    November 26, 2013 @ 2:40 pm

    I wrote a comment on this with the title: Choosing a web framework – that’s not easy.

  62. Avatar  


    November 29, 2013 @ 5:58 pm

    Your distinction makes no sense at all. Why exactly are JSF, GWT and Vaadin in one bucket and those others in another?

    This distinction becomes really weird when you realize that JSF and Wicket are rather similar in both paradigm and architecture.

    I somehow suspect your classification is based on which framework has a vocal and hyping community behind it, so it comes down to: hip & cool: web, boring and uncool: enterprise? But this doesn’t make sense either. Wicket and Struts don’t have a hippy community behind them at all.

  63. Avatar  


    November 29, 2013 @ 6:04 pm

    What of bunch of nonsense. Component frameworks are bad because designers can’t work with html, css and js?

    So how do you think the non-component based frameworks get their stuff on screen? By displaying designer created PDFs or Flash? Are you for real???

    Component based frameworks allow for either a very quick application of existing components (PrimeFaces in particular has an excellent collection, but there are others like RichFaces) that lets you do a lot of stuff in literally no time, OR they allow you to organize your own stuff.

    Creating a component in JSF is just putting some HTML + CSS + JS on a Facelet (.xhtml) and voila; you have a reusable component.

    Oracle should definitely not adopt Struts 2 as the standard framework. OMG! They should instead focus on making JSF even better than it already is. Did you take a look at JSF 2.2? It smokes the competition!

  64. Avatar  

    Anıl Özselgin

    December 2, 2013 @ 7:10 am

    Can you develop a html rich website like tumblr with JSF? That is overuse. Distinction is not based on architecture, it is based on usage of the frameworks.

  65. Avatar  


    December 2, 2013 @ 10:29 pm

    Well, does tumblr use Grails, Play, Spring MVC, Struts or Wicket then???

  66. Avatar  

    Anıl Özselgin

    December 3, 2013 @ 7:35 am

    Tumblr doesn’t use java for frontend needs. What is the point in your question?

  67. Avatar  


    December 6, 2013 @ 11:46 pm

    Indeed it doesn’t. But you used tumblr as prove that JSF can’t be used to develop an html rich website. Since tumbl doesn’t use Grails, Play, Spring MVC, Struts or Wicket, I guess those also aren’t suited for html rich websites then?

    Otherwise it’s just an “is-so/is-not” game. I can claim that Tumblr can be made with JSF, you claim that Tumblr can be made with Grails. But Tumblr isn’t build with either. What was the point of brining Tumblr into the discussion in the first place?

    I’m not sure if you have ever looked up some benchmarks, but Grails and Play don’t perform particularly well and are much slower than JSF. Wicket is faster, but still slower than JSF and uses more memory.

    Spring MVC can be faster when used with JSP, but modern Spring MVC uses Thymeleaf which is slower and uses more memory. Spring also puts more strain on the garbage collector since it creates so many small intermediate objects during request handling.

  68. Avatar  

    Anıl Özselgin

    December 7, 2013 @ 8:23 pm

    Faster/Slower is not the point.
    Nobody uses JSF for HTML rich pages. If you claim it can be, show me the examples. I can show you Spring MVC powered HTML Rich websites. We are using it. JSF creates dirty javascripts. If you want to be competent in todays web, you have to write your own javascript, css, html. JSF/GWT creates dirty frontend codes -like frontpage/dreamweaver- with full of tables.

    Give me please frontend rich website names which are using JSF. That will end the debate :)

  69. Avatar  


    December 11, 2013 @ 3:53 pm

    I believe Wicket is a component framework that is ideal for web designers to work with. Designers for Wicket work with plain HTML + CSS. Apache Click is another good component-based framework that uses Velocity for HTML templates.

    It goes to show that a component-based framework need not necessarily be a problem for designers.

  70. Avatar  


    December 11, 2013 @ 4:01 pm

    You might take a look at Apache Click for a simple component-based framework. One of its principles is to stay simple. I have only played with it so far.

  71. Avatar  

    Hisham ARagheb

    December 12, 2013 @ 11:49 pm

    You missed the context. I mean designers can’t cope with tons of components and tags with custom attributes, as they find it easier to create a page from scratch and copy/paste from previous work without any need to amend a component to suit their needs.

    Yes you can prototype a page very fast but definitely you will face hell when you have a huge application with rich interface where many parts of the page hide/show based on ajax request/response. This type of applications act as if many pages reside in one page and change based on user behavior.

    I tried jsf 2.1 and i hated it. I am not biased against it without a reason.

    I have developed internet banking products and i know that from experience.

    As long as you’re tied with JSF it’s ok. This is a discussion session not a fight pal.

  72. Avatar  

    Ari Lendakari

    December 25, 2013 @ 11:53 pm

    Well, I was just hanging around when I saw what Anil is saying. Ok, I’ve been working with JSF 1.x and 2.x for two years. I’m going to take his sentences one by one:

    “Faster/Slower is not the point”. I would consider it to be actually one of the points shouldn’t it? Isn’t it relevant for a framework to be faster or slower?

    “Nobody uses JSF for HTML rich pages”. Well, I don’t know if you’ve ever worked with JSF, but probably you would know there are some third party component libraries like Primefaces or Icefaces. Here you have a couple of links that show some of the companies that are using them:

    They are actually many, aren’t they? Ok, that’s just a list of companies that use such third party libraries. JSF can also be used without them in order to design the components yourself and provide your own JS code for them.

    “JSF creates dirty javascripts”. JSF doesn’t create javascript code by its own. Third party component libraries DO it and you can choice between them (Primefaces, Icefaces, Richfaces, Apache Tomahawk). If ALL of them are creating ugly JS code for you, then just don’t use them and create your own JS code, as you could do to “be competent” nowadays. Personally I prefer avoiding having to write JS-CSS if the provided components suite my requirements.

    “JSF/GWT creates dirty frontend codes -like frontpage/dreamweaver- with full of tables”. Well, I don’t know about GWT, but give me ONE example where JSF creates dirty frontend code by its own.

    Having said that, I think I can go bed ;-)

  73. Avatar  


    January 9, 2014 @ 6:32 pm

    Hi, I am working almost 10 years with Java web frameworks like JSP, Struts, JSF+Richfaces, JSF+Primefaces, and I am happy because technology is finally getting away from JSF. I agree with Anil in some points, but mainly I want to say, I have workerd in big Java projects like a CRM and ERP, and JSF was always a bad election. The last sample, was an ERP developed using JavaEE + Primefaces, the most delays was because its very hard to customize JSF/Primefaces components, it are very error prone, hard complex, etc. Obviously you can say ‘why to modify components?’, but client’s don’t think like developers and want its requirements implemented, and UI components customizations are the most complex to manage at JSF/Primefaces. Be a JavaEE addict is not a good thing, we want to be free and see what is good and what not.

  74. Avatar  

    Ari Lendakari

    January 13, 2014 @ 7:45 am

    Alvaro, probably Primefaces components have their main issue in styling, that’s true. Most of the components are based in background images, which are so difficult to customize. However you’re yourself saying your problem was Primefaces, not JSF. Remember JSF creates pure HTML markup (with some embedded jquery), which you can customize on the way you want. You still have the choice of using components or not (or using another more customizable library like Richfaces), anyway having the possibility to choice is great, isn’t it?. Remember that all a JSF servlet does is to translate a facelet view into raw HTML! However deciding what you want to put there (or using components or not) is your own choice.

  75. Avatar  


    February 5, 2014 @ 2:18 am

    Say goodbye to “web frameworks”. Bring on the REST frameworks. Create a Javascript, HTML5, CSS rich UI App and call it a “Web App”. I might suggest AngularJS/Knockout/BackboneJS as frameworks on this side of the equation.

    Let the server be simple REST server.

  76. Avatar  

    Fran Serrano

    February 6, 2014 @ 6:27 pm

    Sure, they are really cool ;O)

  77. Avatar  

    Fran Serrano

    February 6, 2014 @ 6:41 pm

    In my opinion there are two assumptions here with which I have some doubts:
    1.- Assuming that no Spring knowledge is available would mean that this is not an option at all “scaring newbies away”.
    2.- Assuming that Spring MVC is used without any set of UI widgets (JQuery UI for instance) could be wrong in most of the cases.
    Spring MVC is in general wrongly underestimated in the report as it provides the flexibility to use whatever javascript widget set or javascript MVC library is currently available with still providing the possibility of a good path to going mobile, service oriented and so.
    I still agree that is not fast enough for building prototypes. For this I would use JSF + Primefaces (or Vaadin, with which I have not worked yet enough)

  78. Avatar  

    Fran Serrano

    February 6, 2014 @ 6:52 pm

    I’m not saying it’s the best, but it’s really easy to setup and deploy: Give Jelastic a try.
    You can also use Heroku with which I have less experience

  79. Avatar  


    February 11, 2014 @ 12:22 pm

    I’ve tried most frameworks. Been through the history as well: Servlets, JSP, Struts etc., Everything I used made me feel like there was a much better, productive and most of all Object Oriented way to do UIs in Java.
    My search came to a glorious end when I found Wicket. I found Wicket, it didn’t find me. I found it because I was looking for something just like it. It’s the product that you dream up in your mind and then start to think “I should make this” and then you realize someone else already has – bliss!
    I didn’t choose Wicket because of some flash marketing campaign or some high paying consultancy said I should get it on my resume. Wicket is not promoted by a bunch of sheeplike, droid army which I’m reminded of every time I talk to someone trying to tell me how Spring MVC, based on the ancient “action oriented” Web UI development paradigm is somehow superior or more productive than a “component oriented” framework like Wicket.
    Yeah, so in summary if you like OO and really “get” OO, you’ll love Wicket. If you don’t get OO it’s features and benefits will be completely lost on you.

  80. Avatar  


    February 22, 2014 @ 8:38 pm

    Hi Simon,

    This article is pretty good to understand the Java web frameworks. However I am not clear that, if Grails is overall winner wrt most of factors, why Spring MVC is popular than Grail.


  81. Avatar  

    Vish pepala

    February 25, 2014 @ 1:04 pm

    I used Spring and Struts frameworks for my projects. Spring is extremely good. Struts (go to hell).

  82. Avatar  


    February 27, 2014 @ 4:20 pm

    I switched to grails, and after the initial (medium) learning curve its been great!
    I still get occasional hibernate issues, but I have gotten good at solving them.

    The automagic GORM is amazing. Book.findByTitle(‘Othello’). FTW. Switched to another j2ee project where there are xml mapping files, ugh, looks like a step back in technology.

    The HTML/CSS is best done using a CSS library like T-Bootstrap. The linkage between javascript MVW like Angular is still left on the table, which, I guess is good.

    Performance is something that must be fine tuned when dealing with larger a website datastore.

    I never heard of Vaadin, I might look in to it.

  83. Avatar  

    Steve Cook

    March 4, 2014 @ 11:46 pm

    GWT and Vaadin are easier to interface things like CRM. I am not 100% sure of Vaadin, but GWT is fully structured around CSS. It is also designed with Ajax integrated as part of it instead of separate which can lend strength to some of the older frameworks that had to work it in later.
    I agree that frameworks have different strengths and weaknesses, but Web vs. Enterprise is not a category to look at. Architecture has little to do with the space it resides, instead it has to do with data loads, scaling, and complexity of the page. GWT and Vaadin excel at complex UI because their focus is there, dynamic front ends, complex and data intensive search, etc. Sites like E-Bay would find great benefit from GWT, especially since the back end of the site could get very complex and hard to maintain in a MVC restricted architecture.

    GWT can manage the model, security and validation on the server, offload the controller and view to the client. Add in HTML 5 and you have a recipe for next gen online games.

    One problem I see in people I have worked with is that programmers are getting lazier or less educated (not sure which). They think MVC is the only way to go, and agile is the only means to get there. Each application needs to be designed for its specific needs, each framework evaluated for what it can do for the project. In this way GWT and Vaadin have an advantage, as they allow you to decide the backend seperately.

    A point on contention, GWT has a standard backend, google-apps. While it is intended for use with publishing to Google’s applications, it can be deployed on any standard web service. So I totally disagree with it not having an eco system, just a lot of people don’t choose to use the one it defaults to.

  84. Avatar  

    Joaquin Ponte

    April 10, 2014 @ 11:39 pm

    +10! same :)

  85. Avatar  


    April 21, 2014 @ 6:53 pm


  86. Avatar  


    April 25, 2014 @ 11:03 am

    We are also trying to do a java framework too. Some of the constrains we hold our self to are zero conf (continuous delivery), no application container and strong typed templating. Our project is called Core9 a nice thing is that it uses the new JDK8 nashorn engine to use javascript as an embedded scripting language.

    Another thing we try to do is to keep the concepts used in the framework very low to reduce the learning curve and to reduce complexity the mother of all evil :-).

  87. Avatar  


    April 25, 2014 @ 11:44 am

    Nice! is it possible to take a look the framework somewhere in GitHub?

    Zero conf, meaning that the application depends on the environment where it runs? I.e. environment variables, etc?

  88. Avatar  


    April 28, 2014 @ 10:10 am

    Yes we now use 1 env var -DDEBUG=true :-) we introduce configuration by what we call features and those are pulled from git repositories.

    Using git internally to the framework was a real eye opener we still have to discover all the benefits!

    To load modules we scan the classpath for module annotations and cache them.

    We basically created the project based off a big list of annoyances we had working with different platforms varying from magnolia-cms, spring to wordpress, drupal and magento.

    The things we liked from those projects we used to inspire us and for the things that annoyed us we looked for solutions.

    The software had to work well with DTAP environments that was a big issue. Also we set our self the goal of continues delivery hence the zero config setup. Also the extreme modular approach we took helps with that. We try to be very strict with implementing only api’s. is the github repo.

    Always looking forward to some feedback or pull requests!

  89. Avatar  


    April 28, 2014 @ 10:14 am

    Nice. Making use of git internally might be a nice feature indeed. LiveRebel uses git internally too.

  90. Avatar  

    Armen Arzumanyan

    May 30, 2014 @ 7:58 am

    JSF2.2 is the best, with primefaces, with facelets with his validators/converters, with integration with HTML5 it have not any alternatives, with JSF you can have rapid development, JSF faster than others, you can have client side or server side development, you can use JSF and connect your web with java classes even not using any JSF components. Grails GWT or Struts, Play framework is not for business application, you will just waste time.JSF is the java web standard.Spring MVC is good, but much more usefull use Spring just as a backend or use Spring services.JSF itself can be as frontend and as backend, DI in JSF from the start and better than in Spring. If you know JSF and develop project with JSF you will success. Better to use pure JSP/Servlets or even PHP than GWT, GRAILS, or Struts, wicket. JSF also modern web framework than others.

  91. Avatar  

    Armen Arzumanyan

    May 30, 2014 @ 8:00 am

    with JSF you can develop any type of web application, but for example with grails or gwt you will every day solve problems which is already solved 5 years ago. Instead of your business logic you will focuce to solve GWT problems or grails problems.

  92. Avatar  

    Anıl Özselgin

    May 30, 2014 @ 8:16 am

    Can you develop with JSF. No. There are limitations. Nobody makes a HTML5 site with JSF. Nobody creates a website with billions of page view with JSF. Because it is only for creating panels with built in components.

    Or OK, show me your most decent web project developed with JSF.

  93. Avatar  

    Armen Arzumanyan

    May 30, 2014 @ 8:35 am

    Sorry but you do not read JSF tutorials carefully, panels and components needed for every projects, but if you not use JSF, you just use javascript or jquery components, JSF have not any limitations, problem is what people do not understand JSF, components is just only face part of JSF. And high performance site is not depend any frameworks.Here is short list of JSF projects , I developed the biggest web applications for 2 departments, clients from USA/Canada/India/Russia , job search portals, matching services, social networ and much more. :) good luck

  94. Avatar  


    June 10, 2014 @ 7:03 pm

    I think there is a bias in favor of web frameworks which are similar to that which the reviewer already heavily uses.

    Consider the evaluation of a framework’s “learning curve.” For Wicket you don’t need to learn XML, Javascript, Servlets, JSPs, or JSTL. You do need to know these for many other frameworks — but because the reviewer is already familiar with those tools he doesn’t count the effort of picking up those technologies as being part of a framework’s learning curve.

    In most frameworks the creation of reusable custom components is much more difficult than when using a fat client Java GUI library, so most web developers acquire a style of work which minimizes reliance on customized presentation components. A person who does not habitually rely on creation of custom components will therefore tend to undervalue Wicket’s ease of reusable custom component creation.

  95. Avatar  


    June 11, 2014 @ 5:34 am

    Can any one tell about ZKOSS framework..???? Should we use it..????

  96. Avatar  

    Marco Di Carlo

    July 9, 2014 @ 3:52 pm

    Very nice review. So far in my work experience I used struts1, struts2 and spring MVC in differents projects, I always tried to get the best from the web frameworks for finding good fast working code solutions when I had a position and the power to choice.
    Perhaps this is not the common way others developer use a web framework, but on Client I prefer to use web technologies as html, css, javascript (jquery)
    on Server I rely on the chosen framework, communicating from/to client using ajax with xml or json, this allowed me to develop, deploy and maintain complex web apps very fast being in charge of every part of the code. My curiosity brought me to test JSF and I was very disappointed maybe because I am used to develop a web app in a very flexible way, creating, changing, deleting, hiding, elements on the screen, that JSF not allow to do but needed in modern web.
    At the moment I am trying to learn and test GWT and thanks to this review I will have a look to all the others frameworks as well.

  97. Avatar  


    August 2, 2014 @ 1:44 am

    Really nice overview and analysis of JSF. Thanks!

  98. Avatar  

    Matej Kvaššay

    September 7, 2014 @ 3:31 pm

    Thx for article, it was really helpful starting point for me as a beginner.

  99. Avatar  


    September 11, 2014 @ 2:21 am

    Well, Spring MVC is just a small part of Spring Framework. Spring provides good suport for databases, hadoop etc. None of the others can do that. Spring can work with hibernate and without it. I do not agree with the comparison. Besides latest version of Spring require very little application set-up. Just use annotations.

  100. Avatar  


    September 16, 2014 @ 11:14 pm

    I found this article interesting, as a developer transitioning to Java. This article works well in that respect.
    For the people wishing it was more exhaustive in nature, go write your own comparison and post a link in the comments here?

  101. Avatar  


    October 9, 2014 @ 6:49 pm

    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.

  102. Avatar  


    October 17, 2014 @ 4:49 pm

    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.

  103. Avatar  


    November 28, 2014 @ 3:43 pm

    JSF on second place. OMG! Seriously??

  104. Avatar  


    November 28, 2014 @ 3:47 pm

    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.

  105. Avatar  


    December 15, 2014 @ 1:00 pm

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

  106. Avatar  

    Adam Koblentz

    December 15, 2014 @ 1:11 pm

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

  107. Avatar  

    Lambda Pool

    December 17, 2014 @ 7:51 pm

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

  108. Avatar  


    March 4, 2015 @ 1:55 pm

    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 :)

  109. Avatar  


    April 13, 2015 @ 6:24 am

    Just check on you to see if you’re still happy with Wicket. i’m a wicket beginner and before I joined my current company I had never heard of it. Is it worth the time learning it? I’d appreciate any input

  110. Avatar  


    April 14, 2015 @ 2:51 pm

    Wicket is underrated. If it was the one framework supported by sun or oracle instead of jsf, things would be much easier these days. Learning wicket is very easy and uncomplicated. However I disagree with the author and wicket lacks many custom components that are supported with primefaces/jsf duo. And you will find yourself spending lots of time writing your own custom ones. And another downside is memory footprint is too high. Other than these two wicket is a beast and fun for a pure java developer. If you are a web developer by origin(html,css,js) you may not like it. If your company uses it learning it won’t hurt. It’s my first choice for my personal projects.

  111. Avatar  


    April 15, 2015 @ 9:08 am

    why are you comparing front-end presentation frameworks with back-end oriented ones??

  112. Avatar  


    June 5, 2015 @ 7:31 pm

    JSF does not combine content with presentation. If you used JSF that way, then please do not do that. Also, simple things take minutes or seconds to do in JSF. When was the last time you used JSF or Java EE? If it was pre-Java EE 5 or pre-JSF 2.0, then you’re not even talking about the same framework as the article.

  113. Avatar  


    July 2, 2015 @ 4:44 pm

    How about html in renderers? I’ve seen it. Maybe it isn’t supposed to be that way, I sure hope so but still, if I compare how terribly slow JSF dev goes as compared to e.g. ExtJS we currently use, then I must say, JSF is lagging lightyears behind.

  114. Avatar  


    July 5, 2015 @ 9:04 pm

    Have a look on It’s a framework of frameworks, so you can escape choosing low level ones.

  115. Avatar  

    RoshanKumar Mutha

    October 19, 2015 @ 1:28 pm

    Guys i have used struts, jsf and Spring. If you do not need integration of many component then JSF is too good as it provide lots of built in components and strong ajax support(JSF2.0 with java annnotation). you can use some popular libraries along such as primefaces and richfaces which has almost all web controll with complete functionality.

    Spring can be used where you integrated with other components and use differnent modules of spring.

    Baseline both jsf and Spring mvc provides Dependency injection. Fast CRUD Application with good Ui can be build fast using JSF.

  116. Avatar  

    RoshanKumar Mutha

    October 19, 2015 @ 1:36 pm

    If you client want very much customised UI then yes JSF can be chosen.

  117. Avatar  

    vladimir valev

    January 1, 2016 @ 9:21 am

    Very well done! Anyway what about Servlets3.x + Freemarker? If you like to be in 100% control and to use fairly simple Controller for all? Vladimir Valev

  118. Avatar  

    Shweta Parmar

    January 12, 2016 @ 4:09 pm

    Thanks for this amazing and great post on shareit download man!

  119. Avatar  

    waled khan

    March 15, 2016 @ 1:50 pm

    wow this post is very much interesting and I used
    iTube Apk Download to watch more good java and coder videos from youtube

  120. Avatar  


    May 25, 2016 @ 9:12 am

    When ever you get locked out of your car and need a professional car unlocking service. Call us we are the Best in Dallas. We also do Car Key Recovery and Replacement. So no matter what time of day or night. No matter what type of car, truck are van we got you covered. We will have you back in and on the road in a flash. Call now for Service.Shareit Download Free

  121. Avatar  

    xender forpcc

    June 5, 2016 @ 6:00 am

    thank you so much

  122. Avatar  


    June 28, 2016 @ 6:52 am

    Click here to download SHAREit for PC free.

  123. Avatar  


    July 12, 2016 @ 7:37 am

    Click here to download Prisma for Android free.

  124. Avatar  


    July 13, 2016 @ 3:41 am

    I love Marmite :D :D

  125. Avatar  


    July 25, 2016 @ 9:27 am

    Check here to Prisma App Download free.

  126. Avatar  

    TechOn top

    August 19, 2016 @ 8:40 am

    Simply I am agree with you. FULLSTOP. No, more questions.

  127. Avatar  

    TechOn top

    August 19, 2016 @ 8:43 am

    +25 hahahahha

  128. Avatar  

    indu reddy

    August 30, 2016 @ 10:57 am

    For new latest updated features in single app for sending messages, images,videos etc download allo application.
    google allo apk

  129. Avatar  

    indu reddy

    August 30, 2016 @ 2:45 pm

    Features of Kingroot app checkout here
    kingroot apk

  130. Avatar  

    Aamir Faiz

    August 31, 2016 @ 8:18 am

    Nobody can regret the truth behind the scene. I am completely satisfy with you. You cannot even enjoy Halloween 2016.

  131. Avatar  

    waled khan

    September 2, 2016 @ 12:55 pm

    LG G6

  132. Avatar  


    September 2, 2016 @ 6:26 pm

    Thank you for sharing This knowledge.Excellently written article, if only all bloggers offered the same level of content as you, the internet would be a much better place. Please keep it up. Check out

  133. Avatar  


    September 8, 2016 @ 1:19 pm

    System Requirements For SB Game Hacker APK Download
    sb game hacker

  134. Avatar  


    September 8, 2016 @ 1:20 pm

    For awesome features of your phone download framarootframaroot

  135. Avatar  

    Viviiy Owill

    October 1, 2016 @ 12:39 am

    Though overall it is really a good article, but it lacks many
    aspects.For e.g at some point Author is talking Struts as legacy
    framework while there is already a new version of Struts derived from WW
    named as Struts2 while struts has already been declared close for

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.