AngularJSdesktop GUIJavaFXJavascriptJSF

Which Is the Hottest UI Framework in the Java World: JSF or JavaFX?

One of my web site’s visitors inspired me to write an article about which of the Java GUI frameworks I recommend. They specifically wanted to compare JSF and JavaFX. So I’ll begin with these two frameworks before I talk about other frameworks as well.

Please feel free to leave a comment if you’d like to add something. The article covers a lot of frameworks, and I can’t know every framework equally well.

Update Aug 05, 2017:

Since writing the article, Java UI framework have become remarkably unpopular. Nowadays the majority of front-end developers quarrels whether Angular, React or another JavaScript framework is the tool of choice. This blog covers these frameworks frequently, so I keep the original post online. Personally, I think it’s a weird idea to drop the Java frameworks. I’m teaching Angular, so I’m biased towards the JavaScript world. Even so, I believe there are good reasons to continue using the Java based frameworks. Like always, it depends on your application. There’s no “one size fits all”. At least not if you care about a good user experience.


Java Server Faces is the GUI framework offered by JEE. So if you choose JSF, you can’t do anything wrong: it’s part of the JEE standard. You don’t have to worry that other JEE features like CDI or JSR303 Bean Validation aren’t supported1. There are a lot of other pluses: JSF is mature, it’s flexible and it’s supported by a huge community. There are great component libraries like Primefaces, BootsFaces, and OmniFaces, just to name a few. And you can easily extend it. No doubt about it, JSF is here to stay.

Well, actually, many developers and architects do claim JSF is something to get rid of. In particular, the rise of new HTML5 frameworks makes many people feel uncomfortable with JSF. There’s an excellent article on why JSF has fallen into disgrace lately.

Update Aug 05, 2017: For a couple of months, even Oracle, the owner of JSF, was suspected to drop JSF. Luckily, the OmniFaces team and a couple of other developers continued developing JSF. Nowadays, JSF is mostly a community project. It’s still (or rather: again) part of JavaEE 8, but I think JSF doesn’t need the JavaEE standard. It’ll survive no matter if it’s part of the standard or not.

Back to the topic. Why has JSF become unpopular?

One of the reasons is that JSF 1.x had a lot of problems. In 2017, the current version is 2.3. This version is a far cry from the 1.x versions. The problem is that there are still many developers out there who got their fingers burnt with JSF 1.x. These negative emotions are still prevalent in the discussions on forums like Reddit and Hackernews.

However, there are a few disadvantages of JSF, even if we talk about the current versions. First of all, you have to write a lot of XML code2. Sometimes this is really annoying: For instance, JSF doesn’t recognize the data type of the data it displays. If you want to display a date, you have to add a converter. That’s two additional lines of XML code – for every date input field in your application. Quite a tedious task.

Our team decided to write a tiny JSF component library to alleviate the pain. The good news is it’s easy to do write such a library. The bad news is you have to do so if you don’t want to put up with the verbosity of the standard. Truth to tell, soon you don’t have to put up with it: One of the goals of my open source project AngularFaces is to make writing JSF applications less painful.

Originally JSF has been designed as a classical request-response-framework. It follows closely the traditional paradigm of web pages. This paradigm makes for simple application development, but it also makes for a bad user experience. I guess I don’t have to repeat the arguments: today everybody’s doing AJAX to overcome the limitations of the classical request-response cycle. Of course, JSF 2.x can do AJAX as well. But once you’re writing AJAXified JSF applications, JSF starts to become surprisingly difficult. It’s got a steep learning curve, but beware: you shouldn’t underestimate the time it takes to become a successful JSF programmer. If you’ve got an experienced JSF guru on your team, make sure they coach the newbies.

JSF 2.2

Version 2.2 of JSF is gentle evolution and radical revolution at the same time. For those about to stick with Facelets, there are a lot of nice improvements, such as a new wizard scope (aka Faces Flow). Prior to JSF 2.0 we only had a very short-lived scope (the request scope) and two long living scopes (application scope and session scope). JSF 2.0 filled the gap by offering the view scope, which probably is the scope of choice in most cases. Flow scope takes the idea even further. It allows variables to survive after leaving a page, provided the new page belongs to the same logical group of JSF pages. As I mentioned above, this is typically used with multi-page wizards.

The revolutionary aspect of JSF 2.2 deals with HTML 5. Beginning with JSF 2.2, you can also use traditional HTML tag instead of JSF facelets. JSF attributes are added to HTML tags using a special prefix. The advantage of this approach is the HTML code can be displayed natively by a browser (with having to use the JSF engine). Of course, the browser won’t display the page perfectly, but it’ll suffice the needs of most web designers. That’s a nice alternative to facelets (even though I still prefer the facelet-centric approach).

The other advantage of JSF 2.2 is flexibility. JSF 2.2 adds “pass-through attributes” that are simply included in the HTML-code without further processing. This enables you to do interesting things, such as combining AngularJS with JSF: I used pass-through attributes to implement the first proof-of-concept of my AngularFaces component library.

Another nice feature of JSF 2.2 I almost missed is it is extremely friendly to web designers. Traditionally, web designers define the look and feel of your application using the widgets of the browser. Powerful JSF widget libraries such as PrimeFaces and RichFaces re-implement many standard widgets. For instance, the PrimeFaces SelectOneMenu (aka drop-down-menu or combo box) does contain a traditional option list – but it’s invisible. Your web designers CSS files are useless.

Recently, I’ve experienced this mess myself. My team had a lot of trouble when we tried to integrate our web designers CSS files with PrimeFaces. JSF 2.2 offers an alternative: simply use standard HTML5 widgets and make them into JSF widgets by adding the JSF namespace attributes:

<input type="text" jsf:value="#{bean.firstname}"/>

The drawback of this approach is you don’t benefit from the power of advanced widget libraries such as PrimeFaces, RichFaces or – for what it’s worth – AngularFaces. However, many teams report they are better off with the HTML5 friendly markup. If you’re working with a web designer, the default styling of the widget library almost always stands in your way, making even simple changes difficult.

But they say nobody’s doing JSF today!

Rubbish. You often hear developers say JSF has been replaced by Javascript because it’s difficult, it’s slow, it’s ugly and it doesn’t meet your customers’ expectations. Don’t believe that. Many, many developers only know JSF 1.x, which has gained a solid reputation to be a pain in the ass. But that’s the past. JSF 2.2 is a modern, highly customizable framework used a lot in the industry. PrimeFaces 4.0 alone has been downloaded half a million times.

On the other hand, there are good reasons to move code to the client. That’s where the CPU power is. A server has to share its CPU between thousands of clients, so it’s obviously better to shift the logic to the client. Only that it’s not always true: the server runs on hot caches, so sometimes a shared server can outperform a vast number of clients running on tiny cell phones. Plus, executing complex Javascript on a cell phone costs precious battery life. If you’re interested in the topic: Some time ago I raised an interesting discussion on Reddit about the weaknesses of JSF. Watch out for Henk’s comments in particular: he’s got profound knowledge about JSF, which allows him to prove many prejudices about JSF wrong.

So while there’s no doubt Javascript has become surprisingly important during the last five years and continues to gain momentum, it’s nonsense to call JSF (or server-side GUI frameworks in general) doomed. It always depends on the use case. That said, I’d like to point you to my pet open source project AngularFaces which solves the question by simply combining JSF and Javascript.

The new kid on the block: JavaFX 2.x / JavaFX 8

JavaFX itself isn’t exactly new. JavaFX 1.0 was the successor of Swing, trying to start over in a radical way. Too bad it was too radical an approach to most people, so hardly anybody cared about JavaFX. As far as I can see, even SUN didn’t care much about JavaFX. After years of neglect, Oracle chose to spend some money in JavaFX when they bought SUN. JavaFX 2.0 is almost as different from JavaFX 1.0 as JavaFX 1.0 was from Swing.

Putting it in a nutshell, JavaFX 2.x is very interesting indeed. I like the look and feel of it. At the JAX conference, one of the speakers puzzled me by claiming JavaFX didn’t match the look and feel of the client operating system. So far, I didn’t notice any mismatch between JavaFX 2.0 and Windows, so maybe it’s a JavaFX 1.0 topic.

JavaFX 2.0 was a pretty new GUI framework. So you had to expect a few glitches. Now that JavaFX has been released, I suppose it’s evolved a bit (but I didn’t try myself yet). Plus, I suppose people will start to write JavaFX component frameworks if JavaFX is going to be popular.

By the look of it, Oracle supports JavaFX strongly with Java 8. The new version (called JavaFX 8 to align it with the underlying Java version) has finally become a first class citizen. Now it’s part of the classpath by default. The previous version was a bit odd in that it was delivered with the JRE, but you had to include it in the class path manually. Almost needless to say JavaFX 8 also supports Lambdas, simplifying GUI programming significantly. Plus, a couple of embarrassing gaps have been closed with JavaFX 8. For instance, there’s a date picker widget at last.

Many people dismiss JavaFX because they fear incomplete deployments. Applications running on the client have a long history of installation problems. It’s a real challenge to ensure that every PC of a major company uses the same Java version, the same configuration and the latest version of your program. Granted, there are several nice tools to deploy programs in a company network, but sooner or later something goes wrong. Try to install the software on – say – a thousand desktop PCs simultaneously, and you run into all kinds of problems. For instance, it’s difficult to deploy a program to a machine that’s been switched off. Nifty solutions like Wake on LAN simply won’t work if somebody pulls the plug. The deployment problem can be solved (e.g. by updating the program at every start), but you’d better think about it in time if you don’t want to end in deployment hell.

Just to make sure a fine framework isn’t ignored for the wrong reasons: the deployment problem can be solved. I’m convinced desktop applications should be run by desktop frameworks. Using the browser as the operating system of your intranet may be popular, but it is ridiculous. Browsers aren’t made for this kind of things, although I have to admit they are catching up rapidly. Actually, they are catching up so fast I expect to have to remove this paragraph in a year or two. Nonetheless, desktop frameworks benefit from a key advantage: they have much more CPU power and memory available than server side applications that have to serve hundreds or thousands of sessions on the same CPU simultaneously.

Every once in a while I observed people objecting JavaFX because they’d already had a look at JavaFX 1.0 and didn’t like it. That’s an unfair trap. The second version of JavaFX does a lot of things different than its predecessor. Most people I talked to who know both versions like JavaFX 2.0 a lot better. The most important difference is JavaFX Script has been abandoned. Nowadays you are relieved from having to learn a new language just to use JavaFX. Since JavaFX 2.0, knowing Java – and optionally XML – will do. There are two ways of writing a JavaFX page: either you build the object tree in Java (much the way you do in Swing). That’s the approach I recommend. It’s slightly tedious, but if offers a lot of flexibility and it allows you to reuse parts of your page in a simple way (just by refactoring the code creating the object tree into a method).

The approach many others recommend is to use FXML (describing the page in XML). At first glance, this is a clever idea: JSF pages are also defined as XML files, and hardly anybody tries to construct JSF pages in Java. In fact, hardly anybody knows it’s even possible. The advantage of using XML is the pages can be processed by tools. In particular, there’s a visual editor, the scene builder. YouTube has a video giving you a good impression of Scene Builder.

However, when I wrote a program with JavaFX 2, I soon switched to Java because I felt the scene builder wasn’t flexible enough. It the same old story: graphical tools are nice to get started, but in the long run you realize doing it the hard way is actually easier. Of course, that’s at least partially a question of taste, and I suppose both FXML and Scene Builder have improved in the meantime. The nice thing about JavaFX is you have both options. Learners should definitely start with Scene Builder and FXML, but once you’ve got the hack of it, give the native Java API a try.

Recently, more and more people tell me there’s a third way to program JavaFX: good old HTML. JavaFX 8 has a decent HTML rendering engine making it interesting to use HTML, CSS and Javascript in a native desktop application (see the Javascript section of the JavaFX documentation).

If you still aren’t satisfied with the components JavaFX delivers – some folks consider them to playful to use them in a business application – you may want to have a look at this component library: ControlsFX (also see OIO’s short article on ControlsFX).


GroovyFX simplifies JavaFX a great deal. JavaFX is very verbose. Well-written GroovyFX code can be very concise. Maybe even more important, it’s strictly declarative. JavaFX code tends to be an iterative mess. If you’re allowed to write Groovy code, GroovyFX is highly recommended. But beware: it doesn’t seem to be mature yet. In particular, the documentation – well, most of the documentation has yet to be written.

I described GroovyFX and JavaFX in much detail in a former article.

Is JavaFX better than JSF?

No. It’s not. Neither is it worse. It’s just a different domain.

JSF is a web framework. You can use it to write applications running in a browser. JavaFX doesn’t allow you to write browser based applications (unless you think about applets). JavaFX’s domain is the desktop. If you want to write an application for your company’s internal use, JavaFX is a great choice. Of course, modern browsers are powerful enough to run a Javascript version of Quake 2. But if you want to do 3-D-rendering, integrate Excel sheets, or if you want to interact with other application on your desktop, using browser technology is a weird idea3. In the Windows world, you’re probably better off with .NET. If you prefer to use a JVM language, JavaFX is a nice alternative.

There’s a video showing the domain of JavaFX very clearly. Dierk Koenig and his colleagues wrote an application to manage a container terminal. Their customer also asked for a 3D visualization. I doubt something like this can be done with JSF. This is the domain of desktop computing:

On the other hand, if you want to write a true remote application, JSF is a good choice. If have to be careful about latencies, JSF isn’t ideal to process huge amounts of data or do a lot of interaction with the server.


Frameworks like AngularJS or ExtJS are ideally suited to solve those problems. You can write entire applications in Javascript. You can even get rid of the Java server if you define WebServices or a REST API. Modern Javascript frameworks make it easy to call a REST service.

I’m just beginning to learn AngularJS. Judging from what I saw and tried so far, Angular is a very interesting and exciting web framework. It’s simple, it’s powerful and it utilizes the CPU power of the client. In particular, JSF developers should become familiar with AngularJS pretty easy: many of the basic concepts are remarkably similar.

There’s an excellent introduction to AngularJS at Chances are you’re going to be absolutely convinced to use AngularJS after reading the article (unless you’re suffering from the Javascript allergy that’s so common among Java web developers).

But again, beware of the risks. Writing an entire application in Javascript means executing it on the client. It can be read and analyzed by hackers or by your competitors. Sometimes you even don’t want your customer to read your code. With Javascript, your code is an open book. You can obfuscate the code, but you can’t hide it. So I guess you’ll want to implement at least some of your business logic on the server. That, in turn, blurs the boundaries of the MVC pattern. Some of the logic is implemented on the server, and another part of the logic is implemented on the client.

Another caveat is the language of AngularJS applications: Javascript. Java programmers aren’t automatically good Javascript programmers (and vice versa). The languages are very different, and the philosophies of the languages are different, too. It’s the same as I mentioned above: don’t underestimate the learning curve. It may be steep, but there’s a lot to learn.

At the same time Javascript offers a lot of benefits. HTML5 allows you to store data locally. This helps you to write a web application resilient to offline periods. Applications running on a cell phone can’t always rely on a stable server. Mobile devices can be moved outside the cells’ reach. A JSF application won’t survive the server disconnect. That’s the realm of HTML5 centric frameworks.

Angular is a pure client framework. That’s a difference to the other web frameworks I mention in this article. Most of them include a server component, so it’s easy to access databases and server resources. Angular is different. It makes it easy to create a REST call, but you have to provide the server-side service yourself. That’s not Angular’s domain.

However, sometimes it’s easy to provide a REST server. For instance, there are add-ons to MongoDB providing a REST interface. And many ESB’s provide REST interfaces, so your Angular Javascript application can access your SAP system almost natively.

Security, authentication, and authorization are hot topics with pure Javascript applications. You have to be aware every request can be intercepted or forged by hackers. So you can’t simply store the login credentials on the client. I guess you have to provide a small security component on the server. So you end up with an almost pure Javascript application, but small Java components remain. Of course, you can write the server-side components in any language, including PHP. The latter language makes AngularJS interesting for smaller websites running on a cheap plain vanilla web server (such as

According to Dave Gruber, AngularJS benefits from both strong community support and a healthy ecosystem. He shows an Ohloh statistic indicating AngularJS is one of the most popular Javascript GUI frameworks, following Backbone.js. So chances are you won’t do anything wrong choosing AngularJS: AngularJS – like most other frameworks covered in this article, with the possible exception of Swing and JavaFX – is here to stay.

AngularDart and AngularJS 2.0

Update Feb 6, 2017: I don’t want to delete the next four paragraphs because they reflect my earlier view, but things have changed a lot in the meantime. AngularJS 2.0 has been renamed to Angular, it has been released and as far as I know, nowadays nobody’s talking about Dart. It was a great language, but it couldn’t cooperate with JavaScript, and that was a serious problem. Instead, there’s a language with a similar approach, but 100% compatibility to JavaScript: TypeScript. Using Angular with TypeScript is arguably the best option among the approaches discussed here. Second only to using BootsFaces, the framework I spend so much time contributing to :). (Truth to tell, there’s more to this claim than just shameless self-advertisement. I’m really convinced BootsFaces is an interesting and useful framework).

Historic paragraphs:
In recent months I’ve read a surprisingly big bunch of criticism concerning AngularJS. They say it’s too complicated, a typical product of the enterprise Java world, playing in the same league as EJB 2.0 and portal servers. Well, interesting developments often raise wild rants by those who don’t participate, so this might actually be a sign of quality. I for one managed to ignore the ugly parts. They do exist (and probably we should call them sophisticated instead of calling them ugly), but you can spend a lot of time with Angular without ever needing those advanced features. Data binding is the core feature of Angular, and it’s a feature many enterprise developers love. It’s also a feature hated heartily by web designers who prefer to tinker around with the DOM directly. This is a valid approach, too: Simple programs don’t need a powerful framework abstracting from the DOM.

In any case, I’d recommend using AngularDart instead of AngularJS. Dart is an optionally typed language compiling to Javascript. The optional type system allows for much better IDE support. A couple of days ago AngularDart 1.0 has been released, so the main reason not to choose AngularDart has vanished.

So I recommend AngularDart to everybody who’s ready to learn a new programming language. By the way, Java programmers get almost immediately productive with Dart. Dart is almost Java the way it was meant.

Those insisting on Javascript may also be interested in looking at AngularDart. The Angular team call AngularDart a preview of AngularJS 2.0. So expect a lot of breaking changes with AngularJS 2.0. However, I don’t expect AngularJS 2.0 soon: at present, there’s no release date set. Probably it’s going to be Q4 2015 or later. The latest presentations of the AngularJS 2.0 stirred up the community, by the way: the Angular team have learned a lot over time and want to do a lot of breaking changes.
(End of the historic section)

Kendo UI Core (optionally with AngularJS)

In July 2014 Telerik published a new version of their renowned Kendo UI framework. Kendo is a very popular GUI framework in the Javascript world. There’s a nice showcase, a lot of documentation, many examples and even a “Kendo DOJO”: example pages including an editor, giving you the opportunity to modify the sample code and to look what happens – without having to install anything locally.

From my perspective, the exciting feature is the brand-new AngularJS integration. Using Kendo UI you’ve got the power of AngularJS, a couple of themes to choose from and roughly 40 widgets covering most of your needs. My first impression is the combination of Kendo and AngularJS makes for a very pleasant way to program great web applications.

Kendo UI Core is the open-source offspring of a commercial library. You have to pay for the most interesting features (such as the grid component). However, even the open source widgets are useful enough to recommend Kendo UI Core.


Wejmo is another popular framework in the Javascript world. I didn’t have the opportunity yet to look at it, so suffice it to say it exists and has been recommended to me by a couple of friends. And that there’s also an Angular integration.

Are JSF and AngularJS antagonists?

AngularJS and JSF are intended to be antagonists. Either you use JSF, or you do something modern like AngularJS. On the other hand, our everyday experience shows frequently opposites meet. So I made up my mind to create an open source project combining JSF (more precisely: PrimeFaces) and AngularJS. Most likely this is a weird idea from the AngularJS point of view (even though I’m not sure about this yet), but I’m pretty sure to be able to smooth some rough edges of JSF. If you’re interested, have a look at my AngularFaces project.


Bootstrap is slightly different from the other frameworks discussed here. Strictly speaking, it’s not a GUI framework – unless you add the optional Javascript libraries which turn Bootstrap into a client-side web GUI framework. An earlier version of the documentation said

“Built at Twitter by @mdo and @fat, Bootstrap utilizes LESS CSS, is compiled via Node, and is managed through GitHub to help nerds do awesome stuff on the web.”

This pretty much sums it up: Bootstrap is a collection of CSS files making it difficult to write an ugly web page. Follow a couple of simple rules, and you’re rewarded with a decent-looking application. Of course, Bootstrap encourages clean HTML code which can be customized by a web designer easily – but the bottom line is Bootstrap pages usually look good even without the help of a web designer. Bootstrap makes it simple to implement a responsive design, i.e. a page layout that adapts automatically to smaller screen sizes. Your application may require a lot of scrolling on a tiny smart phone screen, but it’s still usable – not a small achievement!

Bootstrap has two core ideas:

  • It divides the screen into twelve columns. Widgets are aligned automatically to the columns. Smaller screens don’t display the columns side-by-side but start to stack them over each other.
  • It provides a basic set of CSS classes to style your widgets.

What makes Bootstrap even more interesting is its limited scope. It’s only CSS. Even the Javascript is optional. This allows developers to combine Bootstrap with many other GUI frameworks. For instance, it’s very simple to combine Bootstrap with HTML5-style JSF 2.2. The other day I even managed to combine Bootstrap with PrimeFaces, which is slightly surprising given the vast amount of ThemeRoller CSS code PrimeFaces generates. The is made simpler by the Bootstrap theme offered by PrimeFaces that makes many PrimeFaces widgets look similar to Bootstrap.

AngularJS can also be combined with Bootstrap. To make things easier, there’s a component library offering Bootstrap-style AngularJS components (see Angular UI).

Bootstrap has an innovative approach to CSS. The CSS stylesheets aren’t written in CSS at all. Instead, Bootstrap 3 relies heavily on LESS – an interesting way to simplify CSS stylesheets. The next version, Bootstrap 4, is going to use Sass instead of LESS.


At this point I should mention BootsFaces. This is a small JSF library simplifying Bootstrap to JSF programmers. You don’t have to know much about CSS – BootsFaces does this for you. The current version, 0.8.0, consists of 45+ components, offers decent AJAX support and advanced search expressions inspired by PrimeFaces. Talking of which, it’s a design goal of BootsFaces to play nicely with PrimeFaces. The general idea is to use BootsFaces for the basic layout and the bread-and-butter-components, and PrimeFaces for the advanced components. You can also combine BootsFaces with AngularFaces and OmniFaces.


In October 2014 Meteor reached version 1.0, so I decided to add it to the article. At first glance, it resembles Angular, but the supporters of Meteor claim they haven’t just written a library, but an entire infrastructure which gives you a head start.

GWT and Vaadin

GWT follows a very innovative approach: you write the entire application in Java. But it’s executed in Javascript. A good portion of your code is cross-compiled to Javascript and uploaded to the client.

Judging from the presentations I’ve seen, this approach works surprisingly well. In former times the GWT compiler used to be slow, but today, they seem to have solved (or at least alleviated) the problem. As far as I can see, GWT is an excellent choice – but again, there’s no way to hide your code. It shouldn’t contain your crucial company secrets. Remember, the code is converted to Javascript and executed on the client. However, as Mohammed Qurashi mentions in his comment at the end of this page, not every piece of code is sent to the client, so you company secrets are not exposed to the client if you implement them in a back-end service.

If exposing your company secrets still is a topic to you, think about Vaadin. Vaadin is a GUI framework based on GWT. It adds another abstraction layer to GWT. A friend of mine is enthusiastic about Vaadin, so I suppose it’s a good choice, too. And it protects your company secrets better: the portion of your code that’s transmitted to the client is much smaller. Most of the code remains on the server, thus resembling JSF.


Grails is a Groovy-based framework for web applications. Grails allows you to write a simple web application in virtually no time. I highly recommend it for creating prototypes of your application. Whether you want to build your application on Grails is a different question. Frameworks like Grails depend heavily on defaults – but once you start to customize the default look and feel of your application, working with Grails starts to resemble working with every other framework: it’s labor. Grail’s a lot of fun because you can deliver results quickly, but once you’ve started to fine-tune your application, progress slows down a lot. Nonetheless, I consider Grails a very interesting framework you should give a try. Even if you don’t want to use it in production it may serve you well as a rapid prototyping framework.

By the way, two of my apprentices impressed me when I told them to evaluate Grails. One or two days later they showed me a working prototype, and by the end of the week, they gave a one-hour lecture on how to use Grails. Needless to say, they were very enthusiastic, and after their lecture, the audience was buzzed, too. Oh, and they didn’t know Groovy before. So don’t shy away from Grails just because you don’t know Groovy or the Grails framework. It’s pretty simple. You’ll get to speed in no time.

Other frameworks

There are only so many frameworks a guy can learn – not to mention using them. So I can’t help it, there are a lot of interesting GUI frameworks I didn’t mention in this article4. Nonetheless, I’d like to mention two frameworks because I believe them to be good: Play 2 and Tapestry. I didn’t try either framework myself, but I’m told they are not too bad.

Spring MVC is also worth mentioning. It integrates (surprise!) nicely with Spring, but the programming model is pretty basic: it’s still good old JSP. So I guess you can use it to serve simple use cases, but I wouldn’t recommend writing a full-blown event-driven AJAX application. For instance, Excel-style table editors are clearly beyond Spring MVC’s scope (unless you’ve got a good tag library providing you the advanced features). On the other hand, most web applications aren’t that complex, so this may be enough for you. At this point I should admit I don’t know Spring MVC myself too well – I just repeated an opinion I overheard some time ago and which is backed by my cursory glances at the documentation.

Update July 19, 2014: In the meantime, I read some Spring MVC documentation. Basically, Spring MVC is good old JSP programming with a Spring tag library. If you’re big into JSP programming, it will do the job. However, I always found JSP programming tedious (it’s programming “on hand and feet”). You’re better off with higher-level abstraction such as the PrimeFaces or Kendo widgets if

  • you like the predefined look and feel
  • and you don’t want to do any sophisticated stuff the third-party widget wasn’t designed for.

During my last project, we ran into both kinds of problems. Nonetheless, I don’t recommend using base technologies such as Spring MVC or manipulating the DOM tree directly with jQuery (or even without jQuery, for that matter). Widget libraries offer a lot of functionality you don’t see at first glance – such as caring about security. For instance, while it’s certainly possible to hack a JSF 2.x page, many attacks are blocked just by using JSF.

Swing and SWT

For the sake of completeness, I should cover Swing and SWT as well.

Swing isn’t a bad framework, but it’s JavaFX’s predecessor. There’s no support anymore. If you’ve got to maintain a Swing application, there’s no pressing need to migrate to JavaFX, but if you’re writing a new application, I recommend JavaFX 2.x.

Nonetheless, there are still people who are using Swing, actually being quite fond of it. For one, many apprentices are taught Swing (at least in Germany). Second, it’s the basis of many, many applications. Developers have built a lot of experience with Swing. has the answer to almost every question you’ll ever ask about Swing. Read “Swing in 2013 – is it worth it?” to learn more about why some people still like Swing. (Truth to tell, many other developers seem to hate Swing. It’s one of those frameworks causing emotions, sometimes even raising flame wars).

SWT looks a bit more promising. SWT is the framework Eclipse is based on, so I suppose you already know it’s a nice framework. It’s easy to use, it’s mature, and there’s a great SWT showcase. Actually, the showcase and the SWT snippets are the features I like best about SWT: they give you a head start (much as the showcases of the major JSF libraries do). There’s nothing wrong with SWT, especially in the Windows world. It’s a framework based on native OS components, so it’s the best possible match concerning the operating system’s look and feel. Last time I wrote an application with SWT, the only complaint I had about SWT was it was a little limited. That’s a couple of years ago (version 3.2), so chances are this problem has vanished, too. But still, I suspect JavaFX will become a more interesting player in the long term.

Qt and Qt Jambi

Qt (pronounced “cute”) is a C++ GUI library with a very long history: development began in 1991. It supports a wide range of devices, including Android, iOs, and Blackberry. Qt Jambi is a project making Qt available to Java developers. Truth to tell, I don’t know much about Qt or Qt Jambi, but after looking at the project site and the Git repository I decided to add them to the list. Qt Jambi has a long history, too. It started back in 2006 and counts roughly 4000 commits. However, in 2014 the development slowed down. The last commit was done on September 8, 2015. So I suspect the project has been abandoned.


Are you looking for the silver bullet of the GUI frameworks? Well, there’s none. There are a few guiding questions that help you to choose a suitable framework:

  • Do you want to write a desktop application, a server-centric web application or an application running on mobile devices?
  • Does it have to be Java? If you restrict yourself to Java you miss some interesting JVM GUI frameworks (e.g. Play, Lift, Grails, Dart’s Web UI, just to name a few).
  • Is your customer happy with simple forms, or do you need full-blown AJAX applications offering almost the same features as a desktop application?
  • Do you need complex server side validations and calculations? If so, you’re better off with a server-centric framework like JSF, or a desktop framework like JavaFX.
  • Does your web application have to support offline periods? This can be achieved best with an HTML5 framework like AngularJS or extJS.

Putting it in a nutshell, I’d recommend JavaFX if your customer wants a desktop application (and if you know how to keep out of deployment hell). If your customer wants a web application, I recommend GWT, Vaadin, AngularJS or JSF. Each of these frameworks has their pros and cons. So at the end of the day, it depends on your customer’s needs. But then – that’s the way it ought to be!

Further reading:

Adam Bien comparing client-centric vs. server-centric Java GUI frameworks
Writing JSF libraries
JavaFX and GroovyFX
JavaFX News, Demos and Insight (
a discussion on on Java GUI frameworks (led in 2011)
Ember vs. AngularJS
What is AngularJS 2.0 going to look like?
AngularJS 2.0: Sneak Preview on data binding
TodoMVC shows a simple to-do-list implemented in 60+ GUI frameworks
an excellent introduction to AngularJS at
Dave Gruber comparing ten Javascript MVC frameworks (including nine frameworks not covered by this article)
JSF, GWT and AngularJS compared
criticism concerning AngularJS

  1. Currently, JSR303 is only partially supported by JSF. As far as I know, this will be fixed in a future version. If you need full JSR303 support today, simply add Apache’s ExtVal.jar.
  2. It’s a common prejudice that JSF pages can only be written in XML. It’s possible to write them in pure Java. But it’s not easy – especially when it comes to adding converters and facets.
  3. There are solutions for each of the problems, but they are clumsy. Except for 3D-modeling: HTML5 offers some neat support for this. But currently using HTML5 excludes a lot of possible users.
  4. Among others, this includes the frameworks my team and I wrote. I’d like to mention them, but they are closed source.

54 thoughts on “Which Is the Hottest UI Framework in the Java World: JSF or JavaFX?

  1. One thing to know about the difference between GWT and Vaadin is that GWT is evaluated on the client. E.g. a button disable/enable action doesn’t go to the server.
    With Vaadin each and every item will get send to the server, that means when you click on a button, a request get’s send to the server, evaluated and if you need to update something else then a response is send back.
    In return that means that you dirty little company secrets stays a secret.

    1. Exactly. I’d already written it between the lines, but I updated the article to make your point more obvious. Thank for your clarification!

    2. Have you worked on webfirmframework (AKA wffweb)? This is also a kind of server side framework but we can decide where the event needs to be handled. Eg:- button click, In wffweb, we can handle this event in the client side, server side or both sides. More details can be found the event attributes in the developers guide. Vaadin provides builtin components but wffweb provides all HTML5 tags and attributes by which we can build any UI.

  2. Spring MVC isn’t a GUI framework. You can use any view technology you want with Spring MVC (including JSF).

    1. Not quite. Most likely you’re referring to Spring (without MVC), which is indeed a general-purpose framework. You can combine Spring with JSF (but you should have very good reasons to do so because CDI combines a lot nicer with JSF than Spring does).

      Spring MVC is a Spring module. It’s a full-blown GUI framework. Both Spring MVC and JSF are MVC frameworks, so they are clearly competitors. Read more at this Stackoverflow discussion on combining JSF and Spring MVC.

      1. I gotta go with Andy here (and not just because he has the same name as me 🙂 ). Spring MVC is not a GUI framework. It’s entirely server side, and says nothing about how the view is presented. Sure, you can populate an HTML page with data from your model using JSP tags, but Spring MVC offers nothing presentational. It’s the HTML and CSS that’s creating your ‘GUI’. In fact you can develop ‘headless’ Spring MVC apps that just serve AJAX.

        1. Andy and Andrew are correct – Spring MVC is most definitely not a GUI framework. It provides its own tag library, but this is to facilitate the Spring MVC framework. Spring MVC is about Front Controllers, Controllers, Services and Beans, all of which reside well and truly on the server.

          1. Maybe we can agree on “Spring MVC is a lightweight GUI framework”. You’re right – as far as I know Spring MVC doesn’t offer sophisticated GUI widgets. It’s a rather small extension to JSP. You’re free to combine it with a variety of client side frameworks. That’s a big difference to component oriented frameworks like JSF, which offer you almost everything you need, but make it difficult to combine them with other frameworks. However, server-side controllers and beans also play a crucial role in JSF, and nobody doubts JSF is a GUI framework.

  3. Well, I think that as in many other cases, the truth is a bit in the middle. While not being a GUI framework (in that it doesn’t offer any “advanced” GUI components like grids, or calendars or stuff), Spring MVC si not a bare-metal-serve-anything web framework. It is very opinionated about how you build your app, it expects params to be called in some way, processed and validated in some way, and then presented through a view technology (JSP or another). Hell, it even has a full taglib covering the normal html controls for an easier binding.
    Saying that you can use it to just serve AJAX is almost as saying that you can use JSF to serve xml by using some Facelets ui:repeat and xml tags. You can do it, but it wasn’t thought to do that. And I bet almost nobody uses it just like that. Most of the time you’ll combine it with some YUI, JQuery, Bootstrap or some other js framework for easier Ajax, but the application logic will be in those Spring beans and the whole application-flow will be based on the well known Spring MVC way.

  4. I really don’t understand this “exposing company secrets” argument against GWT. Which kinds of secrets would they be? I think people claiming this as the problem should be able to demonstrate a couple of real-world examples of such secrets getting inadvertently exposed through GWT client code.

    I have written thousands of lines of such code, and nobody ever raised this kind of issue.
    GWT client code gets deployed as *obfuscated* Javascript, by default (see
    Also, the truth is that web applications written with older technologies (Struts 1.x, mainly) used to have quite a bit of un-obfuscated Javascript code embedded in JSP pages and shared “.js” files, which could easily contain details not meant to be seen by users. Yet, again, this didn’t seem to be much of an issue, back then or now.

    In my opinion (based on experience with Struts, JSF, GWT, and jQuery), when developing a Java-based web app GWT is the best choice, as it provides huge advantages with hardly any disadvantages. To me, it would only make sense to use something else if your back-end is not going to be written in Java.

    1. Point taken. Obfuscation might make a lot of people feel more comfortable with GWT (and AngularJS/AngularDart, and so on). I’m going to start a poll about it.

      As for the secrets: consider an online loan program. Among other things, the program checks whether you’re solvent or not (the so-called “credit rating” – see for more – but still cursory – information). Typically, this algorithm includes many different aspect like your age, your job, your income whether you paid back loans in the past and much more. The rating formula is considered a company secret of finance institutes. They don’t want to make it public because otherwise everybody would enter the “correct” values – and get the loan even if they can’t even pay the interests.

      1. Comimg in defence of GWT, the above example that Stephan mentioned about “rating” and the company little secret – we do not code that in GWT client side code, we code that in the GWT backend service layer residing in JEE services and accees them through GWT rpc (remote procedure call) to server. That way the secrets are never converted into runtime javascript.

        1. That’s good to know. I’ve updated the article.

          You know, the first question my co-workers and my boss asked me when I told them about GWT was “you don’t want to expose all our knowledge, do you?”. Maybe an irrational fear (in most cases, at least), but a fear many people nourish and cherish.

  5. There is an alternative tool similar to GWT called Dragome. But this one is about compiling bytecode to js, and it also has UI components support. Things like Incremental compiling, Java 8, HTML template are already supported.
    And there is no need to wait to ECMAScript 6 to be standardized because it already allows use of dynamic proxies continuation (js yield), classes, lambda (arrow functions).

    Project URL:

    1. That maybe because Google did not back GWT to the maximum by marketing it, but now it is an open source, I have been developing enterprise application with it for a while, it is an excellent framework build on Java language and as you probably mentioned in your post an excellent software engineering principles, an example in this regards is its MVP(model view presentation) as well as Google own activity and places paradigm, that makes developing and maintaining large application a developers delight.

  6. What were the factors JSF not adopted widely despite being good component based model? Especially CRUD kind of application can be built in 5 minutes with JPA, CDI, JSF using NetBeans IDE. Perhaps more learning curve?

    srihari konakanchi

    1. I asked almost the same question a couple of minutes ago on reddit. I’m very curious about the reactions. The learning curve of JSF is surprisingly nasty, but then, show me a GUI framework that’s really simple. The last one I saw was the GUI of Adabas Natural. That’s a server side framework without real client interaction (basically it follows a simple request-response paradigm), and it’s pure text, no fancy widgets. Nowadays customers demand more, and that’s what makes it difficult, no matter which framework you use.

      Javascript based GUI frameworks make the application feel more responsive and have a lot of other advantages, but they have their problems, too (the most notable one being Javascript itself, which is not to everybody’s taste). In particular, they don’t make programming simpler. Just different.

      Has anybody else an idea why JSF starts to come out of fashion recently?

      1. The first answers came, and they are interesting (Which weaknesses does JSF have?. There are good reasons why not to use JSF, but the most important reasons seem to be rumors and personal preferences. JSF 1.x seems to have been bad, ruining the reputation of its successor, too.

        Many people don’t like the the level of abstraction of JSF. It decouples you from HTML, CSS and Javascript. For example, it’s no fun at all to work with a web designer on a JSF application: many of them only know pure HTML, so their CSS files don’t work with JSF widgets.

        1. [en] (Translated by
          I’d like to add to your comment that it’s wrong to say that (using JSF) you decouple (yourself) from HTML, CSS and JavaScript. You can personalize the components of a JSF library with CSS. I’ve done that without running into problems. In other words: At the end of the day, web designers can make modifications without any inconvenience.

          Quiero hacer un aporte a tu comentario, es un error decir que se desacopla el html, css y javascript, los componentes de una liberiria jsf, se puede personalizar con el css esto ya lo he realizado y sin ningun problemas osea que finalmente los diseñadores web puede hacer las modificaciones sin ningun tipó de incovenientes.

          1. Yeah, that’s what I told our web designer, too. Take the HTML code generated by our component suite and tweak them here and there using CSS. Can’t be so difficult, can it? But he wouldn’t listen to me. He didn’t know anything about JSF, and he didn’t care. He sent use a native HTML+CSS page. It was a hell of a job to translate this to a set of CSS files compatible to JSF.

            Second, the general idea of JSF is that developers don’t need to know much about HTML to get started. Later, they need to customize their pages, and that’s where CSS comes into play. It’s an afterthought. Plus, using a JSF component library, it’s impossible to modify the HTML code generated by the component. And why should you want to? The component generates good HTML code, so there’s no need to change it. That’s what I mean with decoupling.

  7. You should also try the JSML GUI Framework. It allows you to easily create guis with java through a separate markup language. It is very powerful and supports a lot of features

  8. I feel so far behind in technology as we are still using JSP at work with legacy Struts 1 applications that are 10 years old. At least we are moving toward Spring MVC for new development. I work in a University I.T. shop where our web applications are small and usually written by a single person (no teamwork, one person writes a web app end to end). I guess it’s like working in a silo while technology passes me by.

    1. Hi Tom,

      you make that sound like a bad thing – but maybe it isn’t. First of all, you’re application does its job, doesn’t it? So your customer is happy. They are not happy if you were to implement the newest breed of technology each year. Technology evolves so fast, many developers feel they can’t catch up. Stability is worth a lot (unless it becomes stagnation, which seems to be your problem).

      By the way, I know your situation. In 2002, my team and I started to write our own company framework. We started with the business logic, continued with the GUI and finally added a decent framework for the persistence layer. Our framework was very successful. I daresay even today it beats most popular frameworks. It was tailored to our company’s needs, and that’s something no external framework can offer. But still, after 5-10 years we felt we’re victims of our own success. When I learned about annotation-based Hibernate and JSF, it dawned on me we’re wasting time. Our framework strongly resembled JSF and Hibernate. Basically, the only difference was that we used German class names instead of English class names. The problem was, management didn’t allow us to investigate these standard frameworks because we had spent so much money on our own framework.

      As things go, our management also decided we had to use Liferay, which killed our home-bred framework (together with our productivity, but that’s another day’s story). So we had to chose a GUI framework in no time and learn it in a hurry. As you can imagine, this didn’t work out: JSF has many, many pitfalls for inexperienced developers. By the way, that’s why I started the AngularFaces project and joined the BootsFaces project. I want to bring the simplicity and productivity of our good old company framework to the JSF world.

      Cutting a long story short, sitting in a silo may feel bad, but that doesn’t mean you’re better of in the technology train passing the silo. Technology is a moving target, and if you try to catch up and to employ every technology of the day, you won’t achieve anything.

    1. It’s interesting that you rant anonymously. Plus, I’d like to hear from you what you prefer instead. Mind you: do you think your comment helps any of the 200 daily readers of this article?

  9. Hi,
    I am a CS student soon to graduate. I am currently trying to learn several things before I graduate to land a junior/entry level job before graduation. In one of the job aplications I did, the interviewer asked for experience with a GUI api, such as swt, swing or preferably javaFx. I downloaded javaFx and have been trying to learn it for a few hours. My question is, how much value would this add to my portfolio? Is javaFx a good GUI api to learn?

    1. Difficult to say. As far as I know, my company does at least one JavaFX project at the moment. So it can’t be that bad a choice. From an educational point of view, JavaFX is as good a GUI to learn as any. When you start to learn the next GUI framework, you’ll recognize many concepts you’re already familiar with.

      On the other hand, nowadays many job interviewer look for stream-lined applicants. They prefer you to be productive from day one. That’s silly, but that’s the way it is. So I’d recommend to learn a web GUI framework. If you live in the United States, that’d be a JavaScript framework such as AngularJS, Ember, Backbone (just to name a few, there are a lot more interesting JS frameworks). In other parts of the world, you might also be interested in learning JSF.

      You may also ask yourself whether you are interesting in programming mobile devices, internet applications or desktop applications. Maybe that helps you with the decision.

      But on the long run it doesn’t matter. You almost certainly have to learn a new framework at your job. So, if I were to interview you, I’d ask which GUI framework you know, and continue with detailed questions about that particular framework. I’m interested in knowing whether you understand the general ideas and principles. I hope I’m not the only job interviewer to think so.

  10. Very nice!
    We did a comparison of frameworks like JSF (PrimeFaces, ADF), vaadin, … some time ago. The full report is available as simple PDF:

    BTW There is a UI Technology independent solution for GUI development. Use Swing or JavaFX or eg vaadin. or other toolkits. The framework name is JVx. There are some screenshots with different UI technologies:

    1. It’s hard to believe you’re more productive with ADF than with PrimeFaces. Of course, it depends on the task at hand and on what you’re experienced with. I just doubt it’s a general pattern. ADF has its advantages, but I’m told it’s suited best to large enterprises. But it doesn’t surprise me that there are more productive frameworks than JSF (according to your statistics). JSF isn’t the most simple framework in the GUI world. Once you’ve mastered it, it’s just great, but it takes some time to get to this point.

  11. Your mom and you must be living under the rock for the previous 10 years. Primefaces is using jQuery without you even noticing it. dumbass

    1. First of all, I recommend you stop insulting people you don’t know. Mind you: the internet is not the anonymous space it used to be.

      That said, I’m pretty puzzled by your comment. Yes, it’s true, PrimeFaces uses jQuery. So what? I don’t see how my being a dumbass is connected to PrimeFaces using jQuery?

  12. Dear All,

    I would like to know the performance of Angular JS and Grail / Groovy in real world experience.

    Could you pls provide the same.


    1. Actually, most of the time you don’t have to care about UI performance. Other key part of your application are much slower. Just think of database accesses or SAP calls.

      AngularJS feels extremely fast. It’s rendered on the client, so there’s not delay caused by network traffic. Plus, you don’t need such a powerful server. Much of the load is moved to the client. Nonetheless, the Angular team has improved the performance tremendously with Angular2. If I’m to believe the marketing guy, Angular2 is one of the fastest UI framework on the market.

      In theory, Grails is a lot slower. For one, Groovy isn’t the fastest language in the JVM world. Second, it’s a server technology. However, I believe the performance of Grails is adequate. I don’t think you can implement a 3D game using Grails, but if you’re doing one of the typical business applications, I wouldn’t worry too much about UI performance. Like I said, in most cases the bottlenecks of the application are outside the UI layer.

    1. It’s funny you said that just now. Yesterday a developer raved about the simplicity of Vaadin to me. But he’s a developer who works a lot with heavy-weight architectures. So I guess he isn’t afraid of generating tons of JavaScript. I guess it’s the same old story: frameworks like Vaadin try to make your life easier by deciding many things for you. If these opinionated decisions match your requirements, you’re well of. If you don’t, you are in hell.

  13. Hi,

    thx for the article.

    I think in general it’s difficult to compare web frameworks with desktop GUI frameworks without thinking about the whole infrastructure and architecture of a project. Within the web frameworks it is difficult to compare frameworks like Wicket with AngularJS. The rendering when we use a pure Java implemented Wicket framework especially the binding is server side executed opposed using AngularJS. From a technical point of view a big difference how the communication is decoupled.
    Do we want to describe our GUI like it is possible with FXML? When yes, do we want to use an proprietary meta language like FXML to do it? e.g. approaches like XUL are more open…(That discussion is another big topic not covered here completely)

    I think there is more then only the question with which technology I can develop my GUI better/faster or with which technology I get the better look and feel. Everybody says it must be CSS ready! The weight of the look and feel subject from a projects point of view is maybe the first thing we have to discuss. Easy expressed, when we dont’t have CSS designers in our project and we won’t split the project responsibilities for designers and developers, what benefit do a project have to have the most flexibel framework regarding CSS? (This question regarding CSS is provocative – that was my goal. Important is always the need and not only what is cool)
    The question if a project is targeted to a browser or not could be an important security question! Many people says…ahhh…all must be HTML5 and browser ready. The more secure communication with JavaFX, WebStart in combination with SOAP / HESSIAN / Protobuf(google)/ .. with your server could be the more important question the the advantages of HTML5.

    Is it a real need that the new application is mobile ready?
    Could web service be used?

    The question regarding the lifetime of a project is very important, 10 years ago struts was state of the art, where is struts today(?). Do we want to use commercial third party tools? But then we wire our development to proprietary things? Or are there components in the architecture we need official support (For many open source projects it is not possible to get professional support)
    Do we want to know which development team is behind an open source project? From my point of view that’s an important question, think about the decision google made years ago regarding GWT ;-(
    It is not so funny to invest hundred of thousands in a project and then to explain the management – sorry – but development of the open source software will not be continued.

    What I’m missing….that’s why I write that comment…

    Better would be to define once in our life the topics/features to be compared and which infrastructure comparisons make sense to use the different GUI technologies. Otherwise we discuss this topics again and again and what is missing in one comparison and in the other not 🙂

    best regards

    1. Good points. I planned to update the article, anyways. Your thoughts are very useful for this.

    1. Oops – yes, I’ve promised that, and so I should deliver any time soon… thanks for reminding me!

  14. I would also add ZK to the list. It is easy to get started with and based on simple Java standards with tons of built in high quality Ajax widgets. Plus you only need to know Java, no JavaScript or CSS knowledge is required (of course if you have some then that would be great for you but it isn’t a necessity.

  15. Like your discussions and knowledge of frameworks.
    I wanted to know the UI frameworks which is fast and easy to implement and also has a good reputation in the market. I am about to complete my BscIT degree.

    1. Why? Too many options? Too few? Things have changed since I wrote the article? Come on, tell us more!

  16. Maybe you can rewrite your last paragraphs and include VertxUI too. It’s a 100% Java client-side web framework, without any graphical choices on itsself, for example it integrates very well with Bootstrap and similar graphical libraries. And you can still use JUnit to test your code. Thanks!

    1. Sure. Mind you – this blog is full of articles about PrimeFaces. But never mind – the article is roughly 5.000 words long, but it scarcely covers the JSF component libraries. Voilà:

      You can use JSF either as a stand-alone framework or you can add a component library. In former times (until JSF 2.1), almost everybody felt the need to add a component library. JSF 2.2 added pass-through attributes, making it a lot easier to use libraries such as Bootstrap or Material Design. Nowadays, you can choose between using a component library trying to match your needs or doing it all yourself. The latter approach usually means more flexibility for the price of writing more code.

      I’ve used bare-bone JSF 2.2 in a project. There’s nothing wrong with it. It’s a good choice.

      Before continuing, I have to admit that I’m a regular contributor to BootsFaces, a JSF component library. Plus, I’m on good terms with both the PrimeFaces and the OmniFaces teams.

      On the other hand, if you decide to add a component library, you save a lot of work. The price you’re paying is a certain loss of flexibility and being restricted by the UI design of the component library. In most cases, that’s a fair trade-off, but you should be aware of it.

      In 2017, I daresay there are only two major competitors: PrimeFaces and BootsFaces. Maybe also ButterFaces. All the old champions such as RichFaces, ICEFaces and so on have gone. Apache Tobago still exists, and it’s getting better each year, but if I’m not mistaken, it fills only a small niche of the market. Even so, it’s alive and kicking.

      Originally, we designed BootsFaces to be a companion framework to PrimeFaces. It’s possible to use it this way, and many developers do so. Somewhere on this blog, there’s an article how to do so. You have to apply some CSS tweaks. Most architects don’t like such tweaks, so most people either use PrimeFace or BootsFaces.

      PrimeFaces has a far broader market share. Plus, they offer professional support. On the other hand, BootsFaces is younger, and we’ve learned a lot from PrimeFaces. Consider it a fresh new take on JSF.

      No matter which choice you’re using, don’t forget OmniFaces. Technically, OmniFaces is a component library, too, but it focuses on non-visual add-ons to JSF. Plus, it plays well with both PrimeFaces and BootsFaces (and almost every other JSF library).

      There’s that. If you’re a Java programmer, JSF is one of the best choices. However, in 2017, things have changed a lot. The vast majority of UI developers prefer JavaScript. The number of JavaScript developers is a lot larger than the number of JSF developers ever was – simply because it covers JavaScript developers, former .NET developers, former Java developers, PHP developers, and so on. So using Java for writing the UI layer has fallen out of grace. The JavaScript world has become much more dynamic. So I recommend having a look at React, Angular, and Vue.js. My personal favorite is Angular, but the other two choices are definitely worth a look, too.

Comments are closed.