Beyond Java

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.

JSF

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 supported.^[1] 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 code.^[2] 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:

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

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 idea.^[3] 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.

AngularJS

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 angular-tips.com. 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 beyondjava.net).

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

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.

Wijmo

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

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

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.

BootsFaces

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.

Meteor

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

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 article.^[4] 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. Stackoverflow.com 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.

Conclusion

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!

Adam Bien comparing client-centric vs. server-centric Java GUI frameworks

Writing JSF libraries

JavaFX and GroovyFX

JavaFX News, Demos and Insight (FXEperience.com)

a discussion on StackOverflow.com 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 angular-tips.com

Dave Gruber comparing ten Javascript MVC frameworks (including nine frameworks not covered by this article)

JSF, GWT and AngularJS compared

criticism concerning AngularJS