tekHedd – the blog

“Contrary to popular belief, it’s possible to write Javaâ„¢Server Faces (JSF) applications without knowing every little detail of how the technology works.”

This quote from Richard Hightower, in a series of articles explaining every little detail of how the technology works, which I am reading because, contrary to popular belief, it is not possible to write JSF applications without knowing every little detail of how the technology works.

*sigh*

[Updated] OK, to be fair to JSF, once I figure out how to use a component, it’s generally very logical and well planned. For example, the dropdown control “value changed” event passes the new and previous values in its event handler. And, unlike ASP.NET, the checkbox-changed event handler actually gets called. Heh.

So here I am, about a month into my foray into the world of Java web programming. For this project I am using Java Server Faces (JSF) with the new “standard” (ahem) toolkit of “visual design” web controls called Woodstock.

Yes, Woodstock. Let’s just forget for a second that what they’ve done here is take the worst part of Microsoft’s web technology, ASP.NET, and copied it. Let’s forget that they’ve done this in a tool that, in order to launch a simple editor, requires about 2 gigabytes of memory, plus swap, to run. Forget all that. Forget that it requires more or less coding blind and “hoping that things work”. It’s called Woodstock. If you search (say, in Google) for Woodstock components, by the time you hit the second page you’re about half buried in furniture and unrelated stuff. And it sounds totally hippie-esque. It’s hard to search on, and the name makes me think of people hanging around in a muddy field tripping. Actually, that doesn’t seem totally out of line when compared to understanding data binding to the Table component, so maybe the name isn’t so far off base, after all.

It’s just that the Beans framework with the JSF layers feel so huge and clunky. It’s like driving a rental truck with a manual transmission. If this is enterprise software, why do I have to double-clutch every time I shift? Why do I have to restart Glassfish every hour to clear out memory? Why does it require two gigs of RAM to run the most minimal CRUD application possible?

Next time I start a project, I’m going to spec it in pure Javascript and PHP. (Yeah, right.)

There are layers on layers. Blah blah pattern blah blah nother pattern built on blah library blah blah enterprise session container blah blah blah. This makes it difficult to learn and understand, and slow. There are a lot of layers. It’s not just an Onion, it’s a Great Big Onion. JSF, the GBO.

I guess it’s time for my cool signature generator script to stop looking at XFire, because I don’t run it any more. The audio quality is so-so, the volume levels are always off for voice chat, it causes game crashing… well when it comes right down to it the only good thing about it is that it works in-game.

Now I’ve discovered that I can use the Steam community in-game. It has better voice support and a very slick interface. Granted, it only supports a few games at the moment, but I’m hoping that will improve with time. (Correction: I’m wrong about that, it supports a lot of games. All you have to do is launch them from the Steam interface.)

I remember that when Steam first came out, everybody hated it for being oppressive DRM. Including me. Since then, I’ve come to really like it, because while it prevents me from running multiple copies of software, it also makes it very *easy* to run the number of copies that I’ve actually purchased. I like that.

Enough ranting about Steam. Back to Java JPA. Whee.