How to update a popular article that made it to rank 2 on the Google search results? My survey article about Java UIs is three years old, so it clearly needs an update. Instead of rewriting I decided to write a series of short articles each covering a single UI framework. I'll concentrate on the JavaScript and Java world. On my list are MVC 1.0 (aka Ozark), Angular2, D3.js (even it's not a general-purpose framework), JavaFX and many others. Maybe I'll also add an excursion to the Microsoft world. For instance, UWP / Xamarin is an interesting UI framework I'd like to cover.
JSF
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 learned 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.
Second, JSF is an old, even outdated technology. Old by the definition of computer science: it's still useful, and it still evolves, but you simply don't need it anymore. Ten or fifteen years ago, it was a good idea to render HTML code on the server side. Simply because there was no other option. HTML and JavaScript programmers had to keep the difference between the browsers in mind, JavaScript was slow and far from being a useful standard, and you couldn't write UI components. Nowadays, browsers have evolved a lot. There are so many useful UI components in the JavaScript world that it seems ridiculous to generate them on the server side. Even worse, powerful JSF components tend to generate a lot of code, which results in long page load times. Processing input on the server feels like a bad idea, too. It means a lot of network traffic. More often than not, the result is an application that doesn't feel responsive.
However, that's only one side of the coin. Under certain circumstances, JSF still has its advantages. For instance, it puts less drain on your cell phone's battery, and it runs smoothly on old or cheap clients (if optimized accordingly). You know, most readers of this blog live in the United States or Europe, where it's fairly common to own both a powerful smartphone and access to fast internet, but there are many countries in the world that are far less privileged. In fact, there are many people in your country that can hardly afford internet access. According to this speech, minimum wage workers in India need to work one hour just to access 15 web pages. Even in Germany, minimum wage workers have to work a couple of hours just to achieve the cheapest possible access to the internet. From this perspective, it makes a lot of sense to keep both web sites small and the CPU requirements low. JSF can do this much more efficiently than most applications based on JavaScript. It goes without saying that most JSF applications aren't optimized for low CPU usage and low network traffic. All I say is if you need to optimize, JSF may become very attractive.
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 they 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.
However, the vast majority of JSF developers develop applications running in the browser. As things go, trying to keep developers from learning HTML, CSS and JavaScript turned out to be an illusion. As a consequence, both the core JSF standard and every popular JSF component framework have options to add JavaScript and CSS. That's the ugly secret nobody tells you when you start programming JSF: good JSF developers have to be familiar with many technologies and at least two programming languages (Java and JavaScript). From this point of view, programming the browser directly with HTML, CSS, and JavaScript seems to be simpler. However, JSF is a mature technology with a lot of industry support. It's not likely to vanish within the next five years. The average JavaScript framework has a much shorter life expectancy. That's one of the reasons why I believe JSF programmers are more productive than pure JavaScript programmers. Other reasons are the powerful tool chain and the seamless integration with the Java backend.
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 predefined 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. Following this approach takes most of the sting out of the flame wars against JSF. You still use some of the concepts of JSF, but you're up to your own to use HTML, JavaScript, and CSS the way you like. This approach is very attractive to many developers who are already familiar with web development.
- 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 developed 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 internet[1]
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 buy a theme 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 were 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.
BabbageFaces
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.
AngularFaces
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 life cycle 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.
LiferayFaces
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 life cycle, 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 a highly specialized JSF libraries focusing on charts rendered on the client side by Highcharts, a JavaScript library bringing interactive charts to the browser.
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.
Proprietary frameworks
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.
OmniFaces
Honestly, I can't think of a JSF project without OmniFaces. OmniFaces is the Swiss army knife of the JSF world. At the same time, it's a most unusual JSF framework. OmniFaces doesn't bring many visual JSF components. Instead, it's sort of orthogonal to other JSF component frameworks. It adds what's seems to be missing in the core JSF framework. Notable examples are predefined universal converters, lazy loading of JavaScript libraries and much more. The developers of OmniFaces are members of the JSF 2.3 EG, which allows them to add popular features of OmniFaces to the JSF standard.
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) (still valid in 2018)
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 life cycle, its built-in validation framework and its seamless integration with JaveEE.[2] The drawbacks are the component libraries, the life cycle, 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.
(not so) Uncertain future (2018 edition)
Since I wrote the article, many things have changed. At the time, the future of JavaEE looked uncertain, to put it mildly. I didn't express my thought verbatim in this article, but I had reason to believe the days of JavaEE as we knew it were counted.
Luckily, the community raised their voices loud enough to impress Oracle. Much of this is the result of what Reza Rahman and the Java EE Guardian did. Reza even quit his job as a Java evangelist at Oracle to stand up for his dreams. I'm deeply impressed by this move, and I'm glad his gamble paid out.
Be that as it may, in September 2017, JavaEE 7 was released, including JSF 2.3. In March 2018, there are still few application servers supporting JSF 2.3, but I'm positive that's going to change soon. It's possible to use JSF 2.3 with a simple Tomcat (adding CDI). You can use Wildfly. The next version of TomEE and IBM Websphere Liberty Profile are going to support JSF 2.3, and if I'm not mistaken, they're going to be published soon.
JSF as a community project (2018 edition)
The 2016 turmoil had several consequences. First, everybody working at Oracle temporarily left the JSF train. Some of these people have returned, some of them haven't. In the meantime, work on JSF 2.3 continued. But it has become a community project. Among others, the OmniFaces guys - Bauke Scholz (aka BalusC) and Arjan Timms - stepped in to fill the vacuum. Currently, I'd say there are enough active key players to ensure the future of JSF.
As for JavaEE itself - well, that's history. Oracle has abandoned it, but they didn't simply drop it. Instead, they handed it over to the Eclipse foundation. So now we've got the successor of JavaEE 8 in its incubator phase. For legal reasons, it's also got a new name.
JavaEE is dead. Long live Jakarta EE!
Uncertain future (late 2016 edition)
Currently (2016), 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, but it also means superior toolchains, high developer productivity, long-term support, and happy customers.
However, I'm not sure I'd start a major JSF project in 2016. Client-side frameworks and ecosystems like react.js and Angular2 are rapidly catching up, so maybe it's time to migrate to JavaScript or TypeScript. However, the development in the JavaScript world is still so fast it's difficult to choose the right framework if your application needs to be maintained five, ten or even twenty years.