Monday, January 19, 2009

JSF compared with CGI-like development for small web sites

I have been developing small side web sites in PHP, Python and Java. With my primary job working with Java / JSF, I found that it was not my favorite development environment. I thought I would share some of my experiences.

JSF

JSF is a great framework, with a lot of promising ideas, but the more I have tried to work with it, the more I find that it may not be the best solution for writing web pages nor small web applications.

Pros:

  • Many open source libraries to leverage
  • Large company backing
  • Complex components with 3rd party libraries
  • Code and view are separated
  • Java has good refactoring tools
  • Fail-over, clustering and other robust business features
  • Part of J2EE
  • Built-in validation and conversion
  • 3rd party libraries can make AJAX fairly easy

Cons:

  • Must be compiled and deployed
  • Too much XML configuration
  • Components are good for 90% of use cases, but severely handicap the other 10%
  • AJAX geared for PPR only, hard to use AJAX for web-service like functionality
  • State saving methodology is abysmal and kills performance and scalability
  • Multi-phased processing on server is confusing to many users
  • Poor CSS support as components and HTML are loosely tied
  • Poor JavaScript library integration
  • Very few web hosting choices

Comparison with CGI

CGI and similar programming usually involves Perl, PHP, Ruby or Python. I have not written Perl in a while as I prefer python and hove not written and Ruby, but I have written full sites in PHP. CGI, or Apache module based languages do not have the framework idea that Java has. Java seeks to give you factories, factories for your factories, paradigms, many standard and rigid APIs, where these other libraries do not. This is a pro. and a con. in my opinion. I love jQuery as it makes client side development terrific, I could do a whole set of blogs on it (maybe I will), but it is more easily used from these other languages compared to Java.

What I find is that even though I love the cool frameworks of Java, the many nice APIs, it is very hard to make a web site with JSF that looks even remotely appealing. From my experience, I can create about a third of a website with jQuery, PHP or Python and PosgreSQL before I have written one page in JSF. This is mostly because of the problem that JSF is too high-level. It does not let me do what I want. In PHP I can loop over a data set and create a table and then easily use jQuery and AJAX to add & remove rows from that table. JSF this is extremely hard, you get validation errors from current rows, the 3rd party render kits never have add & remove rows, their AJAX is almost always built in and you can't customize it.

What it comes down to is that I do not need help with the GUI and HTML, I just want some help with tedious tasks. JavaScript libraries like jQuery make rapid web development easy as there are a ton of plug-ins written for it, many of which are more customizable than the ones offered for JSF. Since I can design my own site and get low level, I do not have to fight a render kit from JSF, or the phases of JSF, I just write it the way I want. Now for users that may not be the best with HTML and JavaScript, maybe a framework is great.

Even though this is important, the other thing I love about developing on Apache and not in a JSF server, is that to make a change, I save a file. In Java, I run mvn (Maven 2) to build, then restart Jetty to test. Working with Tomcat, JBoss or another application server is even worse. It just takes too long to work on. I can make a couple of changes and test with PHP when I am still waiting for my Java application server to start up. Not too mention that Java servers tend to be a major RAM hog.

JSF and Component Trees

Another thing that keeps bothering me in JSF is the notion of a web application and the component tree. In JSF, the pages are designed to be shown once, but this is not how web applications work. Web applications, should be mostly one web page that changes as I interact with it (like gmail for example). I should not have to wait for full page refreshes all the time. JSF's components can do this, but not the view layer. JSP is horrendous with dynamic includes and Facelets has issues too (mostly tag / tag handler to component ID matching issues). Without dynamic includes, it is very hard to author wizards, or pages that change (not reload).

I wonder if Google was smart to avoid Java's JSRs and avoid JSF and develop GWT, a web application development framework made for robust clients.

Final thoughts

This is truly a blog post, in that I am just sharing some thoughts as they stream from my head to my keyboard. I could say more on the subject, but don't have the time at the moment. Perhaps JSF2 will improve JSF development, but from what I have seen it only goes so far and will have many of the same flaws, although it does have a lot of cool new functionality.

It will be interesting to see where the space goes in 5 years, but I will be surprised if JSF lasts that long with its current design. I think that high-level frameworks are just too hard to work with. I really see why most web sites are still written using interpreted languages like Perl, PHP and Python. I still love Java and JSF, but for small web sites on the side, I really don't think JSF can compete at all with its light-weight competitors.

No comments: