The potential of object oriented programming for graphical desktop applications was realized over two decades ago in the NeXTSTEP API for Objective-C, and later by BeOS ’s C++ API, Swing for Java, and (finally!) .NET in C#.

Using any of these frameworks, the value of the “object” abstraction in your very own code becomes abundantly clear. OOP is more than myString.lastIndexOf("boring"). It’s more than a glorified categorization of functions. It’s about building up your own little object army, organized in a class hierarchy, that responds to user interaction in intelligent and predictable ways.

When the Internet took over the world in the ’90s, NeXT wasn’t sitting around staring at HTML and taking potshots at it with an inline script pee-shooter. Nooo sir-ee. They built the first stateful, OOP framework for Web applications, WebObjects, and released it in 1996. Like their previous endeavors its success was limited by an obscenely high price. Then the company itself was actually bought for an obscenely high price by Apple Computer, and all hands were called on deck to turn NeXTSTEP into Mac OS X. So WebObjects mostly sat around waiting for enterprising programmers to take notice and copy it.

Ten years later we have stateful, WebObjects-inspired frameworks popping up all over the place. Wicket is the swan of the brood, if you ask me. But the hotshot on the block, Ruby on Rails, has a stateless lineage. What’s up with that?

The last time I touched on stateless vs. stateful, I concluded that the two models were suited for different tasks, and specifically, “For high volume sites with working URLs, you need a stateless framework [i.e. Rails].” I further marginalized Wicket by observing that mainstream Web sites are stateless (and not highly interactive) and wouldn’t benefit from it terribly much.

Six Wicket-months later, I’ve reached a different conclusion: stateless Web programming is goin’ down. Sure, it executes faster, and it’s better for some tasks. So is machine language. Fortunately, we didn’t settle for the once-mainstream text-based interfaces that assembly was capable of producing.

Likewise, now, we shouldn’t ponder how to replicate a scripted site like Slate Magazine just as efficiently in Wicket. We should be aiming much higher: rich, personalized interfaces, and the best tool to make them is a stateful Web framework whose components live beyond one request cycle.

The famous sore thumb of Wicket’s persistent component implementation is that static, permanent links are not the default (or ideal) link. But with URL mounting in Wicket 1.2, it’s a lot more fun putting them in. I don’t mind descending from the ivory tower of long-living components as much if I’m rewarded with a nice /app/mything/34 URL.

Every Web site that hopes to attract users should have both interactive, stateful components and ample static links to its content. But even if that weren’t true, and even if every link in a site had to be static, I’d want to do it in Wicket for its support of real HTML templates.

Like WebObjects and most of its offspring, Wicket gingerly binds markup to server-side components using HTML attributes. Compared to inline scripts that choke (or at least hamper) browser and WYSIWYG editor rendering, templates win hands down.

Some day Rails will probably implement HTML component templating, and maybe even persist components between requests, but really—why wait for them?