Choosing Between Vaadin and JSF

With the recent release of Primefaces 3.0, JSF finally reaches an unprecedent level of maturity and utility that puts it face to face with other popular Rich Internet Applications (RIA) options, such as Google Web Toolkit (GWT), ExtJS, Vaadin, Flex and others. This open source project also proved to be very active and in a constant growing path.

I have been working with JSF + Primefaces since October 2010, when I started developing the project JUG Management, a web application conceived to manage user groups or communities focused on a certain domain of knowledge, whose members are constantly sharing information and attending social and educational events. JSF is a standard Java framework for building user interfaces for web applications with well-established development patterns and built upon the experience of many preexisting Java Web development frameworks. It is component-based and server-side user interface rendering, sending to clients (web browsers) pre-processed web based content such as HTML, JavaScript and CSS. My experience on this technology is openly available on

Meanwhile, I had the opportunity to create a Proof of Concept (PoC) to compare JSF and Vaadin in order to help developers and architects to decide between one of them. Vaadin is a web application framework for RIA that offers robust server-side architecture, in contrast to other Javascript libraries and browser plugin-based solutions. The business logic runs on the server while a richer user interface, based on Google Web Toolkit (GWT), is fully rendered by the web browser, ensuring a fluent user experience.

The result of the PoC was surprisingly interesting 🙂 It ended up proposing both technologies instead of eliminating one of them. I found out, exploring available books, articles, blogs and websites, that despite being able to implement all sorts of web applications, each technology has special characteristics, optimized to certain kinds of those applications. In practical terms, if we find out that JSF is better for a certain kind of application, that’s because it would take more time and code to do the same with Vaadin. The inverse logic is also true. In order to understand that, we have to visit two fundamental concepts that have direct impact on web applications:

  • Context of Use considers the user who will operate the application, the environment where the user is inserted, and the device the user is interacting with.
  • Information Architecture considers the user of the application again, the business domain in which he or she works on and the content managed in that domain.

Notice in the figure bellow that the user is always the center of attention in both concepts. That’s because we are evaluating two frameworks that have direct impact on the way users interact with web applications.

Visiting the concepts above we have:

Some applications are available for internal purpose only, such as the ones available on the intranet, other applications are used by external users, such as the company website.

Users of internal applications are more homogeneous and in limited number, which means that the UI can be a bit more complex to allow faster user interactions. That explains the fight Microsoft Office vs. Google Docs. The last one is not yet fully acceptable in the office environment because it has less functionalities than Microsoft Office. The latter is, on the other hand, more complex and more expensive. However, a limited number of users to a larger number of features makes acceptable to have some additional costs with training sessions to profit from the productivity features.

A company website targets heterogeneous users in unlimited environments. It is not possible to train all this people, thus simpler user interfaces with short and self-explanatory interactions are desirable.

Considering the environment, we would recommend Vaadin for homogeneous users in limited environments and JSF for heterogeneous users in unlimited environments.

Different devices demand multiple sets of UI components, designed to look great from small to large screens. Fortunately, both frameworks have components to support the full range of screen sizes from regular desktops to mobile devices. The problem is that different devices bring different connectivity capabilities and the application should be ready to deal with short band-width and reduced transfer rates. In this case, Vaadin seems to be more suitable for multiple devices, as long as the variety of devices is not so extensive, because the user interface is rendered locally, using JavaScript, and it has a richer Ajax support to optimize the exchange of application data with the server.

Business Domain
In principle, good quality UI frameworks such as JSF and Vaadin can implement any business domain. The problem is how experienced the team is with the technology or how small is the learning curve to master it. Business is about timing and the technology that offers the best productivity will certainly win. If your team has previous experience with Swing then Vaadin is the natural choice. If the previous experience was more web-oriented, manipulating HTML, CSS ans Scripts, then JSF is recommended.

Content is a very relevant criterion for choosing between Vaadin and JSF. In case the application needs to deal with volumous content of any type, such as long textual descriptions, videos, presentations, animations, graphics, charts and so on, then JSF is the recommended over Vaadin because JSF uses a web content rendering strategy to profit from all content-types supported by web browsers without the need for additional plugins or tags. The support for multiple content is only available on Vaadin through the use of plugins, which must be individually assessed before adoption.

Last, but not least, we have the user, who is the most important criterion when choosing a UI framework. We would emphasize two aspects:

  1. The user population: the largest is the target population the highest are the concerns about application compatibility. It must deal with several versions and types of browsers, operating systems, computers with different memory capacity and monitor resolution. All these without failures or security issues. For larger populations, the most appropriate technology is the most compatible one in a cross-platform environment, which is the case of JSF, since it uses a balanced combination of HTML, JavaScript and CSS, while Vaadin relies only on JavaScript and CSS. But shorter populations would have better profit with Vaadin because cross-browser compatibility is and will remain being a very hard work to be done by Vaadin’s development team behind the scene.
  2. User’s tasks: If the application is intensively operated by users then it is expected that it has more user’s tasks implemented. On the other hand, if the application is rarely used or has short intervals of intensive use, then there is a lower concentration of user’s tasks. According to the PoC, Vaadin is the technology that provides the best support on delivering user tasks with richer user interaction because of its fast visual response. JSF is less optimized on which concerns the user interaction.

In conclusion, instead of discarding one of these frameworks consider both on the shelf of the company’s architectural choices, but visit the criteria above to make sure that you are using the right technology to implement the expected solution. A simple way to apply those criteria would be to assign weights to each criterion, according to the project’s characteristics; set which technology is appropriate for each criterion; and sum the weights for each technology. The highest weight elects the technology to be used in the project.

24 thoughts on “Choosing Between Vaadin and JSF

  1. Disclaimer first: I’m a member of the Vaadin team.

    Great article! We’ve worked really hard for making Vaadin the best framework for building desktop-like browser UIs, and you outline the differences pretty well. However, regarding the browser support aspect I’d like to point out that Vaadin supports all major desktop browsers, including IE6. We take this pretty seriously, so if there are problems with cross-browser compatibility please file a ticket at and we’ll fix it.

    Vaadin is also very easy to embed, so it’s straightforward to implements more demanding parts of your UI with Vaadin without having to rewrite the whole app.

    In any case there are no silver bullets, so you should always try out at least a few options to make an informed decision on which framework is right for your app.

  2. Hello Henri,

    thanks for your comment and I appreciate the work you guys have been done to make Vaadin a great product.

    As I stated in the text concerning the browser support, “[…] cross-browser compatibility is and will remain being a very hard work to be done by Vaadin’s development team behind the scene.” So, I recognize such dedication, but it is really good to hear that from you 😉

  3. Hi Hildeberto,

    have you also tried Wicket? IMHO this framework combines the positive aspects of both JSF and Vaadin.
    Wicket shares with Vaadin the Swing ‘philosophy’ but at the same time gives you a full control over web elements (HTML, CSS, JavaScript).

    That’s my 2 cents but, for what it worths, I consider booth JSF and Vaadin two good solutions 😉

  4. We did a similar comparison a while back, but in our case we found JSF to be more suitable for an Intranet application (which serves a department of about 150 people on a single server).

    Maybe it’s because many developers in our team already think in terms of pages, but overall the UI we had in mind (which is rather rich since it’s an Intranet app) was fairly easy to create with JSF 2 and the rest of Java EE 6.

    We indeed also use PrimeFaces. RichFaces was also evaluated, but the rather bad support for paging and sorting in their datatable put us off.

    The view scope and view parameters are used a lot in our app, and they work great for making pages that can be book marked. The integration with bean validation is also really great and Facelets templating works like a charm.

    In addition to our own evaluation, we took a look at a “famous” Vaadin application (blackbeltfactory), but many of us were a bit appalled by it. The UI experience really is troublesome there, especially for a public site. Now maybe the problems are elsewhere and their backend and/or UI designer is to blame, but it was the last straw that made us choose JSF/Java EE 6/PrimeFaces.

    1. Yes, building the whole site with Vaadin is one approach, but sometimes it’s better to use something else for content that’s mostly static, and use Vaadin just for the more interactive parts.

      One example for this is the site itself: it’s a Liferay portal with several Vaadin applications embedded in it. Liferay is used for overall structure, CMS type stuff, access control etc., and Vaadin is used to implement eg. the add-on directory ( and the comparison matrix (

      While Vaadin supports all major portals using one is by no means necessary. It should be easy to use Play, Wicket or any flavor of JSF for the same purpose.

  5. Really nice to read intelligent analysis that comes up with fresh views useful for actually choosing frameworks by application domain – not just listing tiny details. Would love to read the reasoning behind recommendations, but even without those it is easy to agree with most lined drawn.

    (also to be noted – it is possible and sometimes wise to combine multiple frameworks in the same application. I have not tried to do this with PrimeFaces and Vaadin, but do not see any reasons why it could or should not be done)

    1. Hello Jonnas,

      The reasoning behind the recommendations is based on the original work of Gaëlle Calvary about user interfaces adapted to several context of use, which is available at and the O’Reilly book “Information Architecture for the World Wide Web” available at These links are also available in the text when you click on “Context of Use” and “Information Architecture”.

  6. Hello Andrea and Henk,

    the way we develop using these frameworks is not widely relevant, except for the time to market in the business domain criterium.

    The important thing it the result of the development, the rendered user interface. This is what impacts the environment, devices, content and so on.

    Visiting Wicket’s website, we don’t clearly see the potential of this framework to render great user interfaces as we can see in Vaadin’s website ( and Primefaces’ website ( It’s clear the advantages offered by Wicket for the architecture and for developers, but I don’t think that Wicket is selling very well its user interaction part. This way, it is difficult to evaluate this framework from the user point of view, who is actually sponsoring the project/product.

  7. @Hildeberto
    > I don’t think that Wicket is selling very well its user interaction part. This way, it is difficult to evaluate this framework from the user point of view, who is actually sponsoring the project/product

    I believe, user interaction part must be handled separately by a pure client-side focused JS frameworks like jQuery(+jQueryUI) or Bootstrap.js etc. It’s no longer 2003, when server-side heavy lifting was necessary to make web pages usable…

  8. Hi Fyodor,

    This is exacty what Vaadin and part of Primefaces do for you. Vaadin uses GWT to render the user interface as a pure client-side JS framework. It use Ajax to exchange information with the server. the difference is that you don’t have to know a semicolon in JavaScript to develop your user interface.

    Some Primefaces’ widgets use JQuery to provide some great user interaction functionalities. Not everything is fully dynamic in the client-side but it is a matter of time. The framework is gradually going on this direction.

    So, don’t worry! We are not talking about old stuff 😉

    1. With the difference that JSF tries to transparently synchronize state in a distributed system. It gives a false illusion of a consistent system while it is full of race conditions and hidden costs.

      Why not just steal the JavaScript component under the JSF component and use it directly ? That is if you can navigate your way through a number of unneeded layers and wrong abstractions …

    2. Hi Anonymous,

      I must desagree with you on which concerns JSF. I don’t see any sign of “false illusion” in it. If I may say, your criticism also applies to several other web frameworks. There is no such a think like a perfect framework. If you want to be aware of every single detail, then you should avoid any framework and develop everything by yourself, which is not what people usually do, and I would never advice that.

      I think you are very focused on implementation while the focus of the article is the decision process to choose between two relevant web frameworks, going beyond implementation details. The discussion about implementation is endless and even if you decide to implement everything by yourself, avoiding those web frameworks, I think some criteria above also apply to you, because it’s a good idea to consider the context of use and the information architecture to deside which is the best user interaction model for the case.

    3. @Anonymous

      What JSF does is allow for an easy to use, high-level connector between client side and server side code. In its simplest form, JSF components are just a fairly thin wrapper around JS components.

      Without this wrapper, you would not only have to manually bind server side services to your client side components, but you would also have to write the server side validation yourself.

      This last issue is critical and is often forgotten by proponents of pure JavaScript approaches for the UI. Calling out to a JAX-RS service is one thing and processing the (XML) data it returns, but processing the post back is quite another thing.

      JSF is not necessarily about state, but state can be quite useful for various things. For instance, loading an item to edit when entering a page and keeping it around for subsequent post backs by using the view scope. Yes, the client could do this as well, but for a lot of situations this means writing DTO types or duplicating types on both the server as well as on the client.

      And don’t forget that client side UIs have much more “hidden costs”. In a server side framework, the total page processing time is fairly clear. In many situations, the client side rendering time is trivial. Not so with client side UIs. Monitoring the server you might be under the impression that your app response is really fast, but in reality it might be dog slow since client side rendering is much harder to measure.

  9. Nice comparison with interesting aspects!

    But I’m not sure that I can agree with this comment: “Considering the environment, we would recommend Vaadin for homogeneous users in limited environments and JSF for heterogeneous users in unlimited environments.”

    As a fact you can see that GWT (the server-side implementation like Vaadin is not important here) is used by some Google products:

    Hotel Finder
    The New Blogger
    Chrome Webstore
    Product Search
    Public Data
    New Google Groups
    Google Health (discontinued)
    Google Wave (discontinued)
    PlayN (basis of Angry Birds)

    … and as you can see GWT is definitely a good choice for “heterogeneous users in unlimited environments”. This is why:

    – GWT means browser independent (compiled for different browsers, no need to develop extra stuffs), you don’t have to check your JavaScript for many browsers… OK, if you use jQuery you will also have this.
    – GWT means a lot of things will be executed on the client side (browser), so if you have a lot of access to your app, you don’t have a huge load on your server. If you just use plain GWT (without Vaadin), you can move a lot of things to the browser. JSF is very server-oriented.


    1. Hi Lofi,

      if you look at it carefully, Google provides more than one user interface implementation for some of their products because they know that there will be exceptions where those products may not work properly.

      GWT is indeed a great framework and I have no doubt why Vaadin has chosen it to be part of its core, but GWT’s Time-to-Market is higher than Vaadin for two reasons: First because Vaddin has a higher widget set and hundreds of plugins available to extend it, giving flexibility to deliver faster. Second, Vaadin allows the full abstraction of the communication between the client and the server, clearly giving more productivity by reducing the complexity of the application.

    2. Hi Hildeberto,

      I have nothing against Vaadin 😉

      I just cannot agree that using JSF + JS + CSS + HTML better for heterogeneous users in unlimited environments. You also need to offer more than one UI if you are using JSF + JS.

      Using GWT you can also doing something like:

      “You could degrade gracefully by creating an html structure that is just ‘good enough’ (with form posts, linked menus, etc) and then have GWT attach to each part of that structure, augmenting its behavior. For example, make an HTML drop down dynamic, replace a link to another page with a component that opens a lightbox, or replace a link to another page with an XML http request to do the same thing (e.g. cast a vote).”



  10. If we are starting from scratch, new to Java and jsf, productivity point of view, which is more productive. Jsf or vaadin? I appreciate the input. Thank you.


    1. Hi Anand,

      The article is about to decide between those technologies even when you start from scratch. Shortly, it depends on what you want to do. If it is a content-based website publishing different kinds of contents, then JSF is recommended. If it is a web application to control some business scenario, then Vaadin is recommended.

      From the programming point of view, you will write more code with Vaadin, but the result is impressive. You write less code with JSF, but you have to rely on a good UI library, such as Primefaces, to have good results.

  11. I’d like to say that I can create a complete page with all its functionality in less than a day using Vaadin.

    Using JSF, you can only wonder how much time it will take… and IF you are going to finish some day with something that actually works… because JSF is full of subtle bugs…

    JSF has been in development for more than 10 years and they still can’t iron away all its design bugs…

Leave a Reply

Your email address will not be published. Required fields are marked *