Like you (as the reader of my blog) already know I hate JSF. I hate it so much that I've dedicated an entire blog and site to bitch about what a pain in the ass it is to use. Being the enlightened man I am from time to time I like to come back to stuff I hate to make sure they didn't do anything stupid like making the framework usable or so. This time was no different.
So I did it. I've installed NetBeans (I usually use the Far Manager's build-in editor but for this exercise I've decided to go crazy a bit and use the full-blown IDE supported by JSF's creators). I've followed the standard File -> New procedure, selected some JSF JPA CRUD example (because I couldn't find anything simple on the net) and started reviewing the app.
First thing that hit me was the really cruel style of the web UI the application presents. In one word "HORRIBLE". Not that it ain't usable - God forbid - but plain "usable" these days just will not cut it. So the GUI is butt ugly - how about the code?
Now that's the place I like JSF most for: the code was just exemplary bloated :D Let me give you some bottom line figures:
1. It's a pure CRUD application. Absolutely nothing fancy. No Ajax or the like cool features whatsoever.
2. It's an application that manages 7 entities (customer, discount code, manufacturer, micro market, product code, product and purchase order).
3. Everything that was generated is 706068 bytes in 72 files!!!
Now compare this to, let's say, Rails, Grails or Sinatra + Data Mapper is about 8 times bigger. I know it is an enterprise sort of thing and that it's not meant for mare mortals. It's the enterprise kind of solution that you'd use at work and not for fun.
Anyways, JSF still sucks, big time. Lot's of hand-written XML, tons of Java code to implement pretty much every aspect of the application (with parts of it having cyclomatic code complexity at the level of 20+). That's just a no-go for new projects that need to deliver solutions on time, on budget and in scope.
One last thing: For crying out loud the web is stateless! Why would anyone force a solution that inherently introduces state which in turn means no scaling possibilities and stupid ideas like "page life cycle" and "control binding"? Why would you ever want to fear JavaScript programming when there are layers of abstraction like Ext JS or jQuery?
I wonder if the MyFaces implementation still differs from the reference one in the way that component libraries will work on one and not the other. I didn't check it out myself - I'm not that brave...
The conclusion is that if you're still doing JSF these days just drop it. Now. It's horrible!
2 comments:
Hi Matthias!
Thanks for your vision of JSF state! I completely believe you on this although I have not looked at the framework since v1.0. Still I would like to note that there are at least several quite successful web frameworks which are not stateless. Take for example Wicket or Vaadin. I completely agree that they abstract the way how the web works but the fact of abstraction is not always that bad and can have its own merits.
The last time I've checked Wicket is already stateless (or at least that's an option when defining the Page constructor with PageParameters parameter).
To me web development is about creating a client-side application (and that's where the client-side tools come into play) and a server-side backend since it is a client-server application. Once you realize that fact the server-side technology becomes a secondary issue. And scaling such applications becomes as easy as it can be.
Post a Comment