But let’s start with the framework I know better than most: JSF. As you may or may not know, I’m a contributor to a JSF component library, so you’ll get first-hand information. It goes without saying that it may be a bit biased. That’s the drawback of getting first-hand information. By the way, if you’re interested in a quick summary, you can jump directly to the State of the art (2016) paragraph.
JSF – why should I care?
Don’t be fooled by what you read in the forums. Many developers speak ill of JSF and call it a dead horse. But JSF is still alive and kicking in 2016, especially in Europe and Brazil. Like so many other things in the information science space, JSF frequently becomes a victim of flame wars. There are so many critics of JSF I decided to address them first before explaining what JSF is. Feel free to skip this paragraph if you’re not biased against JSF.
Putting it in a nutshell, there are two sources of criticism. First, the 1.x versions of JSF were really bad. (At least I’m told so, I never used it). But the designers of JSF have learnt their lesson and corrected many design flaws of JSF 1.x. Version 2.0 was a big step forward, and subsequent versions became even better. If you’ve suffered from version 1.x and ran away crying, let me tell you that using a current JSF version is fun.
Be that as it may, JSF is still very popular in a variety of countries, in particular in Brazil and in Europe.
I’d like to add a third point. I often feel JSF is annoyingly clumsy. I suspect many developers shy away from JSF because the feel the same. That’s why I contribute to BootsFaces. This framework is dedicated to making a developer’s life simpler.
What is JSF?
JSF is a server-side web-application framework trying to abstract from the peculiarities of the browser. Strictly, speaking, it’s even wrong to say JSF is a web framework. The web is only the most popular target platform. There’s at least one JSF implementation running on JavaFX: Captain Casa. I don’t know about their market share, but the company exists since 2007, and they seem to have found their stable niche. It’s definitely an interesting approach to writing desktop applications.
Until JSF 2.2, the key feature of JSF were its components. Components are the building blocks of JSF. I’ll list a couple of component libraries in a minute. As you’ll see, the range of components is impressive. There’s everything from simple input fields to full-blown map engines and statistical charts. Unfortunately, many people felt restricted by the pre-defined components, so JSF 2.2 added a second programming paradigm:
- You can adopt an HTML5 coding style. More often than not, this will result in an HTML-centric coding style that doesn’t need JSF component libraries. Instead, you can use popular client-side components libraries like jQueryUI or Bootstrap. For example, there are two powerful client-side data tables for Bootstrap: Bootstrap-table and Datatables.net. The latter works both with or without Bootstrap.
- You can employ a powerful component library like PrimeFaces or BootsFaces. These components offer a lot of features out-of-the-box, but they are usually a bit opinionated about how a UI should look like. Like said above, components are a mixed blessing. They serve almost every requirement, but sooner or later most projects are confronted with a requirement the component doesn’t quite meet. In such a situation, you’re stuck. JSF has been developer with extensibility in mind, but few developers dare to extend predefined components, so it’s an all-or-nothing game. Even so, the UI component libraries are one of the most compelling reasons to use JSF.
JSF component libraries: GISFaces
Let’s start with a small but exciting player. GISFaces is specialized on displaying maps. Using maps with GISFaces is surprisingly simple. GISFaces uses a number of maps services that are available publicly and for free, so I suppose you can use the maps in your own applications, even if you publish them on the internet1
Unlike most other JSF libraries, GISFaces is closed source. Plus, you need to register yourself before you can use it. But according to Chris Duncan, that’s not a big deal. His comment below has a lot of additional information on the registration process in particular and GISFaces in general.
JSF component libraries: PrimeFaces
These days, PrimeFaces is the most popular JSF component framework. It offers a rich set of components, including such exotic components for statistical charts and flowcharts. PrimeFaces also simplifies AJAX. Recent versions of PrimeFaces added support for mobile devices, accessibility (e.g. screen readers) and responsive design.
From today’s perspective, the default theme of PrimeFaces looks a bit old-fashioned. But that can be helped with a wide variety of predefined or custom themes. PrimeFaces supports Themeroller, so it’s easy to create a theme yourself. Or you can by a thema from PrimeTek, the company backing PrimeFaces, or a third-party vendor.
PrimeFaces is an open-source library published under an Apache V2 license. Only support and bug-fix releases cost money.
Cutting a long story short: PrimeFaces is highly recommended. Even if I’m the contributor to another JSF component framework that seems to be competition, I’m very impressed by PrimeFaces, and it’s always a lot of fun to use it.
JSF component libraries: BootsFaces
BootsFaces is a slightly smaller component framework build around the Bootstrap framework. In other words: responsive design and support for mobile devices where built in from day one. Originally designed to be a small framework concentrating on the layout, it rapidly grew to a full-blown JSF component library offering roughly 70 components.
BootsFaces generates much more compact HTML code than most JSF frameworks. Most components of BootsFaces generate a native Bootstrap component. Usually, that means compact HTML code. Most of the rendering takes place on the client, relieving the server from having to care about every aspect of the UI.
Other notable features are the advanced search expressions and the AJAX framework. Both have been inspired by PrimeFaces, but go far beyond. The general idea of BootsFaces is to simplify JSF. The innovative approach to AJAX is an example of this.
Like PrimeFaces, BootsFaces is published under a business-friendly Apache V2 license. Despite its low version number, it has attracted a lot of attention. The 2000 downloads-per-month mark has been crossed in May. That’s a much smaller market share than PrimeFaces has, but the figures keep growing, and BootsFaces has been designed with compatibility to PrimeFaces in mind. The goal of the team is not to replace PrimeFaces, but to allow cherry-picking.
JSF component libraries: ICEFaces and RichFaces
These are two early JSF component frameworks that used to be popular but have almost fallen into oblivion since then. If I’ve followed the new correctly, the development of RichFaces has been canceled this year (2016).
ICEFaces still seems to be an active project, but it’s lost much of its popularity in recent years. Among other things, there was some commotion when ICEFaces copied a lot of the source code of PrimeFaces without telling. Strictly speaking, this was legal (the Apache V2 license is very liberal), but the JSF community didn’t appreciate that. Be that as it may, ICEFaces added a couple of very interesting concepts to the JSF world. “Automatic AJAX” detected the changes of the JSF tree, allowing for much more efficient usage of the network. ICEFaces also was a pioneer in exploring push technology with JSF.
Talking of automatic AJAX, it might be interesting to mention BabbageFaces. That’s project of mine bringing automatic AJAX to the greater JSF world. BabbageFaces was very successful in the lab, but it didn’t work as well in the real world. It only works if the HTML code generated by your JSF page is valid XML code. That’s hardly ever the case, so I consider BabbageFaces an interesting but failed project. Plus, advances in network technology reduced the need for such a framework.
Another canceled experiment of mine – but one that’s used by a small group of developers in production. The idea of AngularFaces was to eliminate AJAX request by moving the logic to the client. More specifically, the client uses AngularJS, which is very similar to JSF.
By the way, AngularFaces is not a component library. It’s designed to be a plugin to every other JSF framework (though it has only been tested with Mojarra and PrimeFaces).
AngularFaces attracted a lot of interest in the JSF community. In particular, developers working on JSF frameworks were fascinated. Developers just using JSF frameworks were a lot less fascinated. Most developers shied away from having to deal with both the complex lifecycle of JSF and AngularJS. In my eyes, the integration was successful enough to take the scare out of it, but since the general experience of software architects is to keep things simple, AngularFaces never took off. In a way, that’s a pity: it’s a good tool to migrate from JSF to AngularJS.
The next version of AngularFaces (if it ever materialized) will target Angular2 and – possibly – AngularBeans.
That’s a very active project targeting a highly specialized market: Liferay. As to my experience, it’s better to program Liferay natively (i.e. by using JSP and Spring MVC), but LiferayFaces offers an interesting bridge to the JSF world. It’s suffering from the same problem as AngularFaces: both Liferay and JSF have a complex lifecycle, and it’s not easy to integrate them. That’s not a small achievement. And it works: I’ve successfully developed JSF applications with LiferayFaces. There’s a major developer productivity penalty, but if you are already using Liferay for some reason, the advantage of LiferayFaces is that it integrates your JSF pages seamlessly with the AlloyUI theme of Liferay.
JSF component libraries: ButterFaces
ButterFaces is another component framework based on Bootstrap, but for some reason, it’s almost orthogonal to BootsFaces. It focused on components, neglecting the layout. In theory, that makes it the ideal companion framework to BootsFaces, but currently, it’s still a bit tricky to integrate the two frameworks. The teams are working on that.
Although this has little to do with the features and shortcomings of the framework itself, I’d like to point out the innovative interactive showcase of ButterFaces. It allows to manipulate the attributes of the ButterFaces components and to see the effect in real time.
JSF component libraries: HighFaces
HighFaces is published under a business-friendly Apache V2 license. However, the underlying Highcharts JS library is not. It’s free for non-commercial use, but both commercial usage and support cost money.
JSF component libraries: TieFaces
TieFaces is a very similar library. It focuses on charts. Plus, it delivers Excel support. You can turn your browser into a spreadsheet using a few lines of JSF code.
There are also a couple of proprietary JSF frameworks. I won’t cover them not only because they aren’t open source, but because I’m under the impression that they have a limited market share. Suffice it to say they exist.
By the way, virtually every JSF developer knows one of the developers of OmniFaces by his nickname BalusC. He’s the helpful soul answering countless questions about JSF on StackOverflow.
State of the art (2016)
Putting it in a nutshell, JSF is an old technology. Many developers even consider it outdated. Plus, JSF isn’t a simple framework. It takes some time to master it. But that doesn’t mean it’s a bad framework. Quite the contrary, once you’ve mastered the learning phase, you can write JSF application surprisingly fast. JSF is particularly well suited to large-scale applications, i.e. the enterprise market. It’s not optimized for small applications or games. But it really shines in the class of application it’s designed for.
The advantages of JSF are its rich set of powerful component libraries, it’s sophisticated lifecycle, its built-in validation framework and its seamless integration with JaveEE2. The drawbacks are the component libraries, the lifecycle, the validation framework and the integration with JavaEE. Each of these features may stand in your way. For example, many developers try to combine JSF with Spring. That’s possible, but there are so many drawbacks that I’d call it a stupid idea. If you insist on using Spring, you’re better off with Spring MVC.
Currently, there’s a lot of uncertainty whether Oracle is going to continue to support JavaEE 8 as it was planned a couple of years ago. There’s a major shift towards cloud computing, and in theory, this might result in Oracle dropping JSF. But I suppose the JSF community is vivid and strong enough to survive such a move. Countless companies use JSF. If Oracle were to stop JSF development, there’s probably a successor in no time. Plus, most of the progress of JSF is driven by the component libraries. But until JavaOne 2016 all this is speculation. The official statements of Oracle state they continue supporting JavaEE 8. That should include JSF. That’d be good news: a lot of effort already went into developing JSF 2.3.
Wrapping it up
Regardless of what they tell you, JSF isn’t dead yet. I’m not sure I’d base a new project on JSF (unless it’s based on BootsFaces, of course). But if you do, you don’t do anything wrong. JSF is a mature technology with a lot of freely available documentation, and it’s still evolving. Maturity may seem boring at first glance, bit it also means superior toolchains, high developer productivity, long-term support, and happy customers.