JSF, an RIA retrofit

by jacob on 1/20/2010

I’ve built three or four JSF applications over the last couple years. I’ve used JSF with Seam and Spring. I’ve used both RichFaces and ICEfaces JSF component libs. After all that what do I have to say about the technology? I’m not going to go so far as to say JSF sucks (but if I were, I’d certainly try to do it with as fine a collection of resources on the topic as that fellow). I’d say that JSF is powerful and flexible. I’d also say that it’s complex. Ultimately, in the context of an AJAX laden rich client application, I’d say it’s too complex.

I dabbled only a bit in JSF 2. Not enough to know how well it has addressed the AJAX issues with JSF. Take a look here if you want a taste of how those rich component libraries synchronize view state with the server through all those AJAX requests. As an architect and developer, I shudder to consider the implications of managing “customized partial processing and partial rendering on the server.” It’s no wonder that the complexity of JSF proved too difficult for some of the developers I’ve worked with, especially those who did a lot of Servlet development or Struts development and never managed to get their heads wrapped around the JSF lifecycle.

In the end, it’s not the complexity of JSF that turns me off of it. From an architecture standpoint, if I’m building a rich client application, I don’t really want to resort to a server managed view component/interface technology. That’s what JSF is and that’s not the right approach to RIA. It’s been retrofitted to operate with rich clients. Yes, RichFaces and ICEfaces do an admirable job implementing client components despite the complexity. But, if I’m going to build a rich client, then the client should be managing view components. Yes, the server still needs to do some view related processing (namely validation). But view components should be managed by the client. Flex does that. So does EXT JS and other Javascript component libs (I’m going to refrain from mentioning GWT and save that for another post. Preview: I’m not super excited to write Javascript UI components in Java).

I’m sure I’ll work with JSF again and I’ll try to keep an open mind to the changes in the 2.* specs. But given the choice, I’m going to turn to technologies that are built right to fit RIA, not retrofitted to do so.

jacob [@] jacobheric.com

There are 3 comments in this article:

  1. 20/01/2010Mukul Gupta says:

    I do relate to what you are saying. As far as encoding simple HTML tags and retaining the page view model (the UI component tree)- JSF was fine. As soon as you mix in Javascript; which is what is needed for any decent behavior (let alone ‘rich’ interaction), JSF and component centric frameworks loose their appeal IMO, especially with the browser becoming a more productive programming platform with Firefox, Safari and Chrome.

    Obviously you need a productive Javascript programming paradigm; GWT is working for us. I do admit that we had a lot of experience and scars (IE, memory leaks for no apparent reasons) doing a lot of Javascript programming and so understand the generated Javascript structure and patterns.

  2. 20/01/2010jacob says:

    Thanks for your report of GWT success (along with some of the bumps on the road to getting there). It’s good to hear. As I hinted in my post, the idea of wrangling generated javascript more than gives me pause. My architectural instinct definitely leaves me wanting build RIA type UI components in Javascript (e.g. using the higher level APIs of EXT JS for instance) over writing them in Java. But in light of your testimonial, I’ll keep my mind open.

    More interesting is the decision between Javascript/HTML/CSS RIA frameworks (EXT JS, EXT GWT, GWT, SproutCore, etc.) and the browser plugin RIA frameworks (Flex, Sliverligt et al.). Having done a lot of XHTML/Javascript/CSS development, and having experienced the great time suck and heartbreak of cross-browser compatibility issues, I tend to think that Flex and Silverlight, with their IDE tools for UI development are the way to go (despite my open source tendencies). RIA apps are really a return to client server apps after all, so why can’t we just acknowledge that and divorce ourselves of the romantic notion of browser only, pure XHTML/Javascript/CSS UI.

    But, I’m also really cognizant of the cautions Tim Bray issues on RIA on his blog and in this good talk. (Note that here in 2010 we’re still nowhere near resolving his prediction on the direction or RIAs). The point that he makes, and that we need to bear in mind as we return to client server application development using Flex or Silverlight, is that client server UIs have historically sucked and the whole reason we’re having this debate is because the simple HTML/CSS UIs of pre-RIA web applications exposed and addressed these UI shortcomings (apologies in advance to Mr. Bray for mangling his argument). He warns that developers want RIAs, not users.

    So, I guess the lesson I’ll carry into whatever frameworks I use to do RIAs going forward is that good UI design determines app success. And, that’s a matter of knowing how the user works and what what makes his or her life easier, not so much how the developer works and what makes my life easier.

  3. 9/02/2010Jacob Heric » Blog Archive » Spring Flex integration with BlazeDS says:

    [...] I mentioned in an earlier post, I have some architectural reservations about using JSF as a platform for Rich Internet Applications. Flex, on the other hand, has some features which make it an attractive alternative platform for [...]

Write a comment: