Remember the hoo-ha some years back about "network stations"? The risks were to be few, and the rewards were to be great. Most of our trusted gurus told us that network stations were the future. Everyone would have a network station. Life would be great. You'd have to be crazy to keep your PC!

But somewhere between the promise and the delivery, the concept fizzled. Or did it? I rarely talk to a System i shop that has any network stations deployed. So, at the very least, the model as promised did fail. But conceptually, some of its primary tenets caught on. The ability to deliver business applications with a browser quickly became a powerful business model. Although the rewards of the mid-90s thin-client initiative didn't come to fruition, those fighting for the value of network stations made the right argument. They just came to the wrong conclusion.

You'll Have to Pry My PC from My Cold Dead Hands

It turned out that PC dependencies were so deeply rooted in our corporate cultures that to simply throw the frustrating things out would disrupt our workflow. Too many users needed office products that specialized in words, numbers, and presentations (do I need to mention names here?) to ever go without their fat, heavy, Windows PCs. Whatever grief those PCs caused, the trade-offs were worth it.

However, those Windows PCs were also good stand-ins for the universal, browser-based application delivery that the "network station" prototype had pledged. With just a taste of the grace and convenience of deploying an enterprise application to a browser (eliminating lots of user hand-holding, service packs, client updating, and ultimately, embarrassment for the IT department), the world didn't look back. We all caught mad browser disease and wanted our enterprise apps in browsers immediately!

The User Suffers

The convenience the browser offered for application delivery came at the cost of a clunky, block-mode user interface (UI). From a programming perspective, this exchange was well worth it. Users, though, had to tolerate screen flicker, HTML's substantial limitations (HTML, on its own, doesn't even know about a cursor!), and the sluggish performance of excessive postbacks. What the world needed was a way to create rich user experiences in browsers.

Enter Ajax. "AJAX" was originally an acronym for Asynchronous JavaScript and XML; however, today "Ajax" has simply become a name that casts a net over all the technologies needed to invoke server-side processes from a browser client. Let that soak in: With Ajax you can, for example, call a web service — from the client side with JavaScript — and, while still on the client side, parse the results to "inject" them into the page (all without a browser round-trip to the server). It's powerful stuff that dramatically enhances the user experience in a browser-based application. (For a good, albeit slightly whimsical, look at Ajax, see Bret McLaughlin's book Head Rush Ajax (O'Reilly Media, 2006).

Although Ajax is powerful, it is also complex, brittle, and exposes itself rather shamelessly to security breaches. Toolkits are rapidly evolving to tackle these issues. But even the best of the toolkits, thanks to each browser vendor implementing JavaScript and HTML standards differently, makes Ajax a tricky thing to deploy with assurance across enough browsers to matter (usually, but not limited to, Internet Explorer 6/7, Firefox, Opera, and perhaps the Mac's Safari).

However, Ajax is gaining mind share and tool support. By focusing on just Internet Explorer 6/7 and Firefox , you can use Ajax to deliver great browser-based user interfaces. Still, though, the IT world needs what the concept of the network station originally proposed: simple but highly usable application delivery for your most critical enterprise applications.

Whither Ajax?

If you're confused about Ajax at this point, rejoice. There is even more to be confused about! Microsoft is heading into release 2.0 territory already with Silverlight (microsoft.com/silverlight), Sun is making press-release noise with JavaFX (sun.com/javafx), and Adobe is trying to get somewhere with Flex (adobe.com/products/flex). All these tools work to deliver rich, cross-browser user interfaces without the constraints imposed by HTML. Think of all three as being "Flash for applications." That is, you'll be able to craft a UI in a development environment with drag-and-drop UI elements (i.e., check boxes, text boxes, and lists), hook that UI up to a data provider (often implemented with web services), and have the client perform a one-time download of your presentation "component." These applications run in browsers a little like Flash movies or ActiveX controls from days past — but they promise (and we all believe everything we're promised, right?) superb cross-browser support.

Microsoft's Silverlight has so far been good only for multimedia UI creation and not for enterprise application. The company promises that this will change with upcoming versions of Silverlight. Maybe it's just me, but it seems that Microsoft is dragging its feet a bit on Ajax and perhaps putting its big chips on Silverlight. Furthermore, JavaFX is still in the incubation stage and needs design tools to even be ready to build a proof of concept. Also, Flex is too overpriced (even after price cuts) to really be considered a broad-based player at this point by anyone but the truly loyal Adobe/MacroMedia customer.

So, as an IT decision maker, you're left, once again, riding the whitecaps and headed for the rapids. Will Ajax mature quickly enough to be the tool you need to deliver rich, cross-browser applications, or will one of the next cross-generation, rich UI tools keep Ajax from ever reaching its third act?

Most of the shops I work with are using good Ajax toolkits with limited browser expectations (again, usually Internet Explorer 6/7 and Firefox). That approach generally works well for narrow, vertical applications, but it's probably a bit too constraining for the delivery of a worldwide, general-purpose site. As time goes on, make your decisions carefully. Don't bet the farm on any one thing right now and pay close attention to how the tools are evolving. You can't afford to ignore how these technologies are going to play out.

Stay aware — 10 to 1 says it's a waterfall, not a still pool, coming up after the rapids!

Roger Pence is the education director for ASNA, an application development tools company, where he focuses on helping customers build browser- and Internet-based line-of-business System i applications. Roger has spent many years writing and speaking about the System i.