JSF 2.0 - Is it really better?

I know most of you will hate me for the post I'm writing but I have no choice. I really need to stigmatize the framework and make clear to anybody still using it that they have been lost in the woods. Literally...

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!

I still hate JSF - but a little less :D

If you know me you also know this for a fact: I hate JSF with a passion! There are no bad enough words that you could use to express the hatred I feel. What can I say - I'm broken this way...

Today I finally gave JSF2 a spin. This time I already knew that working with Java EE is a pain in the neck so I've decided to use my usual environment (Grails) to do the test.

JSF / JSF2 has some major drawbacks out of the box. It's heavy and it's a misery to introduce changes (again, out of the box). Sure you can use like JRebel and stuff to make your life easier but then JRebel costs money and if you're just playing with the technology with no apparent reason spending any money is just not justified at all.

So back to the topic: JSF2 on Grails. Sounds, scary, right? Yes, I've got the goosebumps too :)

What's in the box? (cited after http://grails.org/plugin/jsf2):

- Bean By convention (no need for faces-config)
- Bean access to controller parameters (session,request,params...)
- Beans dynamic methods for navigation redirect(action?,bean?,view?,uri?,url?) and - render(action?,view?,bean?),
- Automatic bean and service properties resolution
- - 'void init()' called at bean initialization if present
- 'void dispose()' called at bean destruction if present
- JSF Extended request scope ('view')
- Access to web.xml configuration via Jsf2Config.groovy
- Access to faces-config generated in web-app/faces-config.xml
- Converters for Locale, Closure, Currency, Timezone
- i18n ready, fast access with #{m['key']}
- create-bean script
- Hibernate session managed from view rendering to view response
- Execute groovy code in EL expression ( #{gtag.groov[' def i = 2; 3.times{ i++ }; i; ']} )
- Support JSF2 Components - @ManagedBean ...

And so my test went like this. I've installed the plugin the usual way, I've create a class called StatusBean (in a .groovy file!), a little bit of copy-paste from the plugin's page to figure out the signature of an event listener did the heavy lifting for me, I've checked the FAQ section to see where should I put my xhtml files and it all worked right out of the box!

Well, I'd definitely NOT go as far as saying that I actually like JSF2. Hell no! I despise it just as much as I did before. I do however recognize that there's world outside of GSPs and SiteMesh and the alternatives are good for some things.

Why JSF is the most used framework

Today I've stumbled upon an article supposedly written by one of the developers of JSF standards.

http://www.zeroturnaround.com/blog/ed-burns-on-why-jsf-is-the-most-popular-framework/

Before I'll go any further I need to make it clear: I hate JSF! Yes, this is my personal opinion, my personal choice. I don't encourage you to do so as well - maybe it's good for you and saves you tons of hours of work - it didn't do so for me.

I'd like to point out that JSF is in my opinion a failed attempt to reproduce ASP.NET WebForms technology. Where WebForms succeeded (component market, easy design, easy event-driven programming model) JSF has failed miserably...

JSF is neither easy nor standard (if you look from a broader point of view and not keep your head in the Java box). I think JSF has the one and only advantage that allows inexperienced web application developers to stay inexperienced and not use core web technologies (HTML, CSS and EcmaScript). This is the reason why JSF is so damn popular - and so damn evil. Once you step into it there's no going back. You're stuck with it!

Like it or not the browser is a viewer that uses all 3 domain specific languages to achieve what it does so what you can do is either learn yet another DSL (the facelets DSL in this case) to do the job or you can simply go through the effort of learning the core ones which will pay off in the next and next and next web application projects no matter what technology you'll use (besides JSF of course)
To my liking it is unbearably sad that people dismiss the simple ideas and take a shot at frameworks like JSF. I wonder when the era will come with something else will replace JSF like WebServices are being replaced with REST.

Funny thing is that Ed draws a hard line between client-side-only frameworks (jQuery, Flex...) because they don't fit into his agenda but at the same time asks if "Wicket, Grails? Play? Echo2? Tapestry? Stripes?" will fulfill the goals that JSF is supposed to. It's funny because there's for example no Grails application that wouldn't use either Prototype or jQuery (or anything else for client-side programming). Funny :)

One final note: "jQuery+REST"? If you know what the author meant with it please leave a comment and explain it to me.

Grails vs JSF - 6 months summary

Hi there folks!

I's been exactly 6 months since I left my previous team where I've had to endure JSF programming for more than a year. Starting July 6 this year I moved to another team where I was finally able to choose the technology I want to work with.

Here are some facts you might find interesting when choosing the web framework:

1. JSF.

- previous project status: in progress...
- team size: 4 developers, 1 architect (doing nothing but breaking the code and managing people since he is the official manager for the team), 2 QAs (doing nothing because of how JSF works)
- project size: too big; needs refactoring into smaller pieces.
- project complexity: waaaaay to high; needs refactoring into smaller pieces.
- code coverage: less than 20%; needs improvement.
- current project status: STILL NOT COMPLETED, 6 developers, 1 and the same architect, don't know about the QAs, but one of them loudly complains he doesn't want to have anything to do with this app :D
- overall experience: I hate my job and I want to die

2. Grails

- team size: 1 developer in the role of architect, QA and programmer and 1 database master, separate manager that does what she(!) is supposed to do which is to help people and not to kill their productivity!
- project size: a lot smaller
- project complexity:
UI: 4/10
server side: 2/10
- project releases from ground zero: 3 (this was a green field project)
- code coverage: constantly between 88% and 98%
- overall experience: I love my job again!

So if you think you're one of the great software architects and you don't need to code because there are others to do that: QUIT YOUR JOB AND STOP DOING ANY MORE DAMAGE!!!
And if you still consider JSF to be a viable option: change your profession! You're probably better of in politics :)

Man, I needed to get that out of my chest :D I'm feeling lucky!

ICEfaces 1.8 - Next Generation Enterprise Web Development

Hi,

because of the integration of ICEfaces and Grails I started looking at books describing ICEfaces as a framework. Unfortunately I found only one, the "ICEfaces 1.8 - Next Generation Enterprise Web Development".

I was pretty excited at first when I saw the integration itself. Many things are done by convention (so more/less the Grails way), views use Facelts for templating... And in many places ICEfaces is mentioned as the best JSF-based framework out there.

So back to me reading the book...

Well,... hm,... what can I say...

60 pages of blah blah blah about how difficult it was to create web applications in the past with pure servlets and JSP, then the magical discovery that was made that web apps could actually mimic the experience of desktop apps... All nice and dandy but... BOOOORING!!!

I finally came to the page where code started to shine through the misery we've been at for the past decade or so. The thing that killed me at first was the statement that layouts should be done using tables!

I mean come on, guys! Where's the distinction between content and presentation? Where's the semantic web stuff??? Should we abandon CSS completely because IE is so damn cruel in this regard?

They even say that they took this road because of "pragmatism":

You may wonder why we use a <table> for the layout, and even the align attribute, when there is a <div> tag and CSS. The answer is pragmatism.

Whatta heck is that?

Honestly, around page 64 I have decided to stop reading the 290+ pages miserable poem and figure out the way to deal with ICEfaces myself using examples from their website.

The conclusion is that some books could just be better. Nonetheless it's fascinating how things get boring when you step back into the "official enterprise" sort of things having your brain already set on the nature of the web (the request/response kind of thing) by all those MVC-based frameworks like Grails, RoR and ASP.NET MVC...

Have fun!

Colose encounters with J2EE/JSF

Hi,

One of the projects I work on involves heavy JSF usage. Along with other tools to make our life "easier" (Facelets for example) the project runs quite smoothly. Right up to the point where a little bit more "custom" solution is required...

Here's the problem: I need to call a method that will return some JSON that will be evaluated by the client and according to the result of this operation some action must be taken.

As long as I wanted to use the rather limited XMLHttpRequest capabilities provided by Ajax4JSF I was fine. Now I need a little bit more control and flexibility over the actual flow and I am screwed. I'm not really interested in the whole life-cycle of a JSF page and all that statefull crap JSF provides - all I need is a simple call to a method and return a little bit of text - that's all.'

As it turns out there's no such thing in JSF directly. There's however a big honky machine to actually hide the inner-workings of JavaScript from an evil developer like me. I can almost hear the creators of Ajax4JSF saying "no no.. that's not allowed here, nigther is that, and oh that's because of X and that's because of Y and that's because it is like that, period". I'm sick and tired of this miserable framework.

So far I've not found a single thing that I like about JSF (MyFaces and RichFaces in particular). To start a project it's a configuration nightmare (if you want to have more than one JSF component library like RichFaces and Tomahawk), some things are simply incompatible. RichFaces force me to use stone-age version of jQuery (my favorite and better with each release), mix things that don't really come together (like server-side code being "executed" by so called "client actions" for example). The whole beautiful stateless nature of the web is gone with the wind in the worst possible style. And last but definitely not least: there's no control whatsoever over the generated markup, nada, zipp, null... And let me tell you, it's huge!

Apparently the designers of RichFaces (and other JSF-related frameworks) didn't follow the news and in their urge to "define" every damn thing they have forgotten that it actually matters in what way you define the layouts. Doing it with multi-level tables is probably the worst thing ever about the generated HTML, but it's definitely not the only horror you'll see. Constant 'styles' and 'script' blocks, intrusive JavaScript and the like are just standard. How can something so bad have become so popular? Oh I get it: scriptlets are the source of all evil in the enterprise application world... How could I forget that mantra. Apparently URLs are also evil as they have no damn meaning in JSF. Posting a form (or however its called in the JSF world) reveals the concept of ghost-urls: you're seeing the next page but the URL didn't get the memo yet. Whatta heck???

No wonder that MVC-based solutions (Spring MVC, ASP.NET MVC, Rails, Django) are getting more and more popular. Those are actually non-hammer tools to get the job done without 100-line exception messages getting in a way.

And don't get me wrong: I'm sure JSF is good for something - it just so happens it's not the creation of highly interactive, flexible and customizable Web 2.0-enabled enterprise applications.

"Close encounters my a..." - John Criton / Farscape.