the trouble with JSF

At work the last year has been back to the future in development. After a reorg in 2012 the DI team morphed into a disastrous and miserable time with some larger devops team who didn't want us, and we didn't want to be with them. I returned to Java server development in January of this year. In March of this year there was another reorg and devops vanished and the Halifax branch was swept out the door. So I narrowly avoided that fate. devops is not missed.

It's been a good year back in the saddle of development. It's where I belong and I can still produce quality design and code. I've always liked Java and I had some good Java years back at SupportSoft. This past year was a good year.

At this point my plan is pretty much to try stick with Java as the go forward plan. Even if the creation of new Java code suddenly and unexpectedly ceased the existing Java base is massive and there should be enough legacy out there to allow me to run out the remaining years of my development career. We'll see. There's still quite a few years to go on that!

So my dev team has a .java backend with a front end website. Most of the action happens in the backend but the website isn't exactly small. The website has been around for several years with the typical nooks and crannies and special features. It is built using Seam and JSF. I was at the website a bit but mostly I worked in the .java part. It's not an area of interest to me and there were other developers who were more interested in UI.

So after observing and being around the JSF for a year, writing some JSF code and being on code reviews, I can finally articulate some things that had been in the back of my mind about Java web.

The thing about JSF is this: where is the Java? You try to do anything and it's all .xml, .xhtml, .js. .css. etc. You virtually never touch a .java file. Why would Sun/Oracle spend all these years promoting a non-Java technology stack within the Java standards? It doesn't make any sense.

There are so many things wrong with this strategy. Java developers don't really mind doing UI. What they mind is being required to leave behind their years of skill and experience in Java to work with this completely different stack(s) that has nothing to do with Java. So we just don't really want to leave Java and why would we. And it is so painful having to learn all these multiple and large foreign syntaxes and terminologies just to get a basic screen to come up. And don't even start on "this code is correct but it doesn't work on version X of browser Y running on desktop OS or mobile phone Z"

So what happens is the Java development team becomes split. Those who do UI and those who don't. That's what happened at SupportSoft. This should be so avoidable. The strength of Java is that it's generally easy for a Java developer to move into a new area such as database, crypto, XML processing, business logic, etc. With JSF because it's not really Java there's this huge barrier with large up front learning curve and no easy transition.


For a long time this JSP/JSF situation was something that developers were just expected to shrug and passively accept. Kind of like the way it was with EJB back in J2EE. After all it's the "standard" way so too bad. Luckily some others realized before I did that the JSF approach is fundamentally flawed and going in a new direction away from a broken standard is better.

You can see some of that on the GWT overview page. This is basically the first words out of their mouth

... goal is to enable productive development of high-performance web applications without the developer having to be an expert in browser quirks, XMLHttpRequest, and JavaScript

It's like, wow, the anti JSF. productive development. not having to be expert in browser quirks and JS. you also don't have to leave Java. you know, Java, that thing you invested years of your career mastering and promoting. It's so bizarre that Oracle/Google lawsuit over Java. Google has done more than pretty much anyone to preserve, promote and advance Java.