As part of the J2EE project I'm heading up, we're evaluating front end options. Presently, our Oracle applications are developed using Oracle Forms 6i for front end interaction.

Personally, I have never been a fan of Forms for the following reasons:

1) With Forms, you're bound to Oracle - plain and simple. Lack of vendor/tool flexibility is bad for enterprise software development.

2) The UI functionality is restrictive. It does data input/validation pretty well, but interactive/easy to use UI can be a challenge or imposibility depending upon what you want to do with it.

3) I find the client/server model in Forms extremely strange: you get a heavy client (Java applet) and a heavy server process (in-memory representation of the form on the server). Shouldn't at least one side of the connection get a break? (I won't share any numbers, but the scalability hasn't been stellar based upon our user-to-server ratio).

4) The Forms framework seems to thrive on absolutely no abstraction between your view and your data model. The tools for building Forms literally lead you to creating direct bindings between UI elements and database columns, and to a certain degree require business logic code to be embedded in the front end.

As a result, we've been looking elsewhere for front end choices. Oracle is heading toward a JSF-based strategy for their tool and application suite, so that naturally rose as an option. As for myself, I believe very strongly in the future of RIAs (Rich Internet Applications), so I threw Flex in to the mix.

So, why don't I like JSF? A few reasons, backed up by many years of web development experience:

1) Primarily, JSF relies on the following technologies: HTML, CSS, and JavaScript. All of these technologies are controlled 100% by the browser, which I (as an application developer) have no control over. To boot, none of these technologies behave identically in any two browsers, no matter how "standards compliant" they may clain to be. That's just a fact.

2) JSF is supposed to figure out your browsing environment and render the components accordingly. This is a nice goal, in the same way that contestants at beauty pageants wishing for world peace is a nice goal. I say this because I've never seen a tool that actually supported mutiple browsers seamlessly. (I even have it on good authority from a vendor using JSF that he has already discovered that this goal is a fallacy; this vendor only supports two browsers for his app, and had issues with some simple JSF controls that they still haven't figured out - and he used the standard JSF tag set.)

3) You can't build custom components in JSF and expect them to work in every browser. Not only would you have to debug in every environment (read: time consuming and error prone), but you can't implement features like drag and drop (surely one of the best UI features in existence) on browsers that don't support advanced CSS and JavaScript.

The bottom line is, there is no way to guarantee the enforcement of web standards. By basing a framework on such a house of cards, I almost feel like JSF is a lost cause before it even begins. There are some nice documents on the W3C web site describing how browsers should implement web technologies, but no browser actually works the same way. They can't, because even specifications are open to interpretation by the developers implementing them, so I doubt that the situation will ever be resolved. (If you want a great dissertation on this, I suggest that you check out Designing with Web Standards by the great Jeffrey Zeldman.)

With Flex, there is one dependency: the Flash player. It's been around for years, and everybody has it. It works in old browsers. It works in new browsers. It works on every major OS on the planet. It runs in phones. It runs in PDAs. It is developed by one company, to one specification. This means that if I develop Flex applications, with custom UI controls and all the other bells and whistles, they will always work the same way, whether my client is Netscape 4 or IE 8 (due in 2047), running in Slackware on a cellphone or Longhorn on a laptop.

Some of you may be crying foul: "But Max, you just said that vendor reliance is a bad thing! Surely you would be relying on Macromedia if you went with Flex?" And my response would be, you are right. However, Flex has a few things on its side: a very loosely coupled programming model, and an excellent set of capabilities that would serve us well for many years. With the programming model alone, it would be simple to retire Flex in the presentation tier after many years of service (if such a necessity arose), while guaranteeing our development investment at the business tier and beyond. And let's be honest: the business tier is where the money is.

Ultimately, you have to accept the fact that your front end is destined to change as new UI technology emerges; the trick is to get the most mileage out of it before that day comes. With Flex offering J2EE and .NET integration out of the box, plus an incredibly attractive and powerful UI layer, I would bet my bottom dollar that we'll get plenty of use out of Flex before we have to find something else for our users to poke with their mouses.

And why not go with OpenLaszlo (Flex's open source second cousin)? Well, I've been playing with Laszlo for some time, and I like it - but it's not vendor supported, and it lacks the polish that Macromedia has lovingly applied to Flex. Plus, I wouldn't be entirely comfortable building an enterprise around a product that does not have a team of paid support engineers behind it. Not to mention, Flex feels much more mature than OpenLaszlo, has nice development tools (sorry, IBM - Flex Builder knocks the pants off of the Laszlo IDE for Eclipse), and there are even excellent books about Flex.

Oh, and Flex's default component set is much prettier. Sure, you could spend time creating custom look and feels for Laszlo, but why bother when the Halo LAF in Flex looks so darn good?

Have some thoughts on JSF, Flex, Laszlo, or this blog post? Hit me up on the comments, my friend.