As you might surmise, Bear is not a JSF fan.
JSF is best when you want to conduct interactive sessions with forms, preferably with relatively few online users. ReST is best when you want to initiate server actions and having the UI maintained for you is a secondary concern. It's also preferable when you want to be able to shotgun requests to a bank of interchangeable servers (large-scale load balancing), because unlike technologies like JSF, you don't end tied up to one specific server in the cluster (which might become overloaded).
There is no "silver bullet" one-size-fits-all solution. I run both kinds of systems. And despite Bear's pessimism, JSF is, if anything, still on the rise locally. Although locally, they're still trying to figure out how to live without punched-cards, so take that as you wish.
JSF is an extendable framework. The core tagsets are basic functions and thin wrappers for traditional HTML. Commonly people will extend these by adopting one of the third-party enhancements that Mr. Tsang has mentioned. I owe him a
cow for that recommendation. Not only is JSF extendable, but unlike older, more cumbersome frameworks, it is a non-greedy framework. It doesn't demand to be totally involved in every HTTP transaction. In fact, there are times when I despair of convincing people
not to attempt to force JSF to do non-form things like produce spreadsheets and PDFs and just employ simple
servlets. I have one app that's primarily ReST, but JSF handles the admin screens.
Ignore what Oracle and IBM recommend. They've recommended lots of things, only to discard them later. Often one reason they recommend stuff is because they want to inflict legions of over-priced "experts" on you.
