An ever recurring topic of discussion is, when starting major maintenance or a new project, is: What web methodology/technology should we use?

This discussion is more often than not a very lopsided discussion where progression is weighed with familiarity. These days, this results in a discussion about either JSF, HTML5 with ReST or something else, such as Vaadin, Wicket or one of the many many many others. For this post, we'll limit ourselves to JSF vs. HTML5 with ReST.

JSF representing the traditional well-known and well-established technology vs the shining new HTML5. The most common choice is to just stick with the well-known JSF and avoid the silly complex HTML5. For the most part, this will work, but JSF suffers from a fatal 20-80 rule because of a common mistake:

"We just have a simple web application."

The first 80% is indeed simple, usually, this first 80% is the first software release. Then users decide that their application is not really that simple and that very simple application just doesn't do what they would like. At this point, they break free from the simple application and decide they want some more complex functionality, usually in the form of bits and pieces of JavaScript to make the application more interactive. This is where things go wrong, because that last 20% will take the other 80% of the time to complete, YMMV.

The release of JSF 2.0 fixed a lot of these problems, but at the core, JSF still doesn't play nice with the concept of interactive applications. To find out why this happens, we look at exactly this core of JSF. JSF is designed to solve one very specific problem: binding, the coupling Java bean values to values on a web page. This binding problem is the whole reason for the 7 life cycle stages and the desire to not annoy the user when something goes awry. This binding problem and the approach JSF took (which, to be fair is a perfectly fine approach), is that JSF was designed to bind statically, that is, there's an intermediate page that JSF interprets and uses to generate the result page, then reconstructing this same page when processing the results and constructing a new resulting page after an action is done. This all is:

1. Quite expensive,
2. Error prone (hence the 7 life cycle stages),
3. Static,
4. Not trivial to debug.

Now this all sounds very miserable! Honestly, it isn't, it just shows that while JSF is efficient in solving the binding problem, it requires a mindset where you work with it's limitations. That is, Java and JavaScript don't integrate as well as the name would imply.

Now the shiny fancy new HTML5 itself doesn't solve any of the problems (such as binding). You'll need a JavaScript framework to do this for you, preferably something like AngularJS or Ember.js. A framework like the ones mentioned try the binding problem for you in a way that fits with rich web applications. Though something like AngularJS automatically sounds slightly more scary than the settled, well-know, well-supported JSR spec JSF. How then does an AngularJS application get built? Well, it's more work to get started with than a JSF application, that is, you need to do the basic setup of the web pages and you have to offer data through something like a ReST service (I find that ReST just works best, though effectively anything that offers JSON or XML is fine).

By strictly splitting the Server from the Client with a well-defined contract, you can work on both components with less interference from one another, building a rich front-end on a reliably back-end without harming the integrity of either one by mangling it into something it isn't.

This by no means deprecates JSF as a framework, JSF itself is still very relevant and a perfect option for well-defined static applications, providing a shorter turn-around and more "Java-Bonuses" than a HTML5 variant can provide in the same time. Though if I'm given the option to build a rich web application, I'll go for AngularJS.