Which Is the Hottest GUI Framework in the Java World: JSF or JavaFX?
http://www.beyondjava.net/blog/hottest-gui-framework-java-world-jsf-javafx/
One of my web site’s visitors inspired me to write an article about which of the Java GUI frameworks I recommend. He or she specifically wanted to compare JSF and JavaFX. So I’ll begin with these two frameworks, before I talk about other frameworks as well.
One of my web site’s visitors inspired me to write an article about which of the Java GUI frameworks I recommend. He or she 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 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, Apache MyFaces and ICEFaces, just to name a few. And you can easily extend it. No doubt about it, JSF is here to stay.
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, Apache MyFaces and ICEFaces, just to name a few. And you can easily extend it. No doubt about it, JSF is here to stay.
There are a few disadvantages of JSF. 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 display. If you want to display a date, you have to add a converter. That’s two additional lines of XML code – for every date 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.
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 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 in your team, make sure he coaches the newbies.
If your guru is an experienced JSF 2.0 guru, that is. JSF 1.x programmers typically used a lot of HTML code in there JSF pages. As to my conviction, this is a bad idea. Better stick to facelets. Of course there’s a lot of JSF 1.2 code out there, and there are even interesting frameworks such as SAG’s CAF based on JSF 1.2. But still: JSF 2.0 is a major improvement over its predecessors, so I recommend to use the newest version possible. At the time of writing, this is version 2.2.
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 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 tipically used with multi-page wizards.
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 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 tipically 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 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 into 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.
The new kid on the block: JavaFX 2.x
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.
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 an JavaFX 1.0 topic.
JavaFX 2.0 is a pretty new GUI framework. So expect a few glitches. The good news is that it’s likely to improve over the years. And I suppose people will start to write JavaFX component frameworks if JavaFX is going to be popular.
Many people dismiss JavaFX because they fear incomplete deployments. Its difficult 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 a several nice tools to deploy programs in a company network, but sooner or later something goes wrong. 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.
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 version 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.
If you aren’t satisfied with the components JavaFX delivers – some folks consider them to playful to use them in a business application – you mave 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 a 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.
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 a 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.
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 collegues 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 an REST API. Modern Javascript frameworks make it easy to call a REST service.
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 an 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 easily: 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 simple store the login informations 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 web sites 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.
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 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.
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 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 an HTML5-framework a co-worker of mine recommended these days. Until now, I only had the opportunity to have a cursory glance at it. But even so I liked what I saw. While sharing some features with AngularJS, it seems to focus on the HTML part of your applications. It relies heavily on LESS – an interesting way to simplify CSS stylesheets – and it offers built-in support for responsive design4. Like Angular, it’s based on the well-known jQuery framework. The similarity of the two frameworks even makes it possible to write a component library offering AngularJS components to Bootstrap applications (see Angular UI).
Bootstrap is an HTML5-framework a co-worker of mine recommended these days. Until now, I only had the opportunity to have a cursory glance at it. But even so I liked what I saw. While sharing some features with AngularJS, it seems to focus on the HTML part of your applications. It relies heavily on LESS – an interesting way to simplify CSS stylesheets – and it offers built-in support for responsive design4. Like Angular, it’s based on the well-known jQuery framework. The similarity of the two frameworks even makes it possible to write a component library offering AngularJS components to Bootstrap applications (see Angular UI).
GWT and Vaadin
GWT follows a most 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.
GWT follows a most 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 good. 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 companies crucial secrets. Remember, the code is converted to Javascript and executed on the client.
If exposing your companies secrets 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 companies 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 you 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.
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 you 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.
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 article5. Nonetheless, I’d like to mention two frameworks because I believe them to be good: Play 2 andTapestry. I didn’t try either framework myself, but I’m told they are not too bad.
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 article5. Nonetheless, I’d like to mention two frameworks because I believe them to be good: Play 2 andTapestry. 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 to write 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.
Swing and SWT
For the sake of completeness I should cover Swing and SWT as well.
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.
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. 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. But still, I suspect JavaFX will become a more interesting player in the long term.
Conclusion
Are you looking for the silver bullet of the GUI frameworks? Well, there’s none. There are a few guiding question that help you to chose a suitable framework:
Are you looking for the silver bullet of the GUI frameworks? Well, there’s none. There are a few guiding question that help you to chose 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, your 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 a 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 have their pros and cons. So at the end of the day it depends on your customers 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 (FXEperience.com)
a discussion on StackOverflow.com on Java GUI frameworks (led in 2011)
Ember vs. AngularJS
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)
- 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. ↩
- 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 add converters and facets. ↩
- 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. ↩
- i.e. rendering HTML pages that look nicely not only on large screens, but on smaller displays as well ↩
- Among others this includes the frameworks my team and I wrote. I’d like to mention them, but they are closed source. ↩
This entry was posted in AngularJS, desktop GUI, JavaFX, Javascript, JSF and tagged angularJS, ExtJS, groovyfx, GWT, javafx, Swing, SWT, Vaadin on byStephan Rauh.
