Traditional server-side programming is all about constraints. You have to think in terms request-handling instead of event-handling. A session store instead of runtime memory. HTML churning instead of drawing. It’s Lincoln Logs vs. Legos.

And for the most part Java frameworks have not challenged these constraints or tried to abstract them out of the picture. They’ve been too busy building increasingly elaborate partitions. Do this here, do that there, and by all means initialization must never occur in program code!

But Wicket ignores their stagnant assumptions and pedantic rules. Instead it leverages ideas of a much stronger pedigree: the Graphical User Interface. You may have heard of it. You may have programmed for it. But it takes some time to accept that its power is fully available to Web applications.

I was reminded of this when I came across Wicket’s DefaultButtonImageResource class. Do you think you can have a Web image button whose rendered text is arbitrary? Any other Web technology’s answer is, “No, crazy, you do those in Photoshop.” Wicket’s answer is, “Well, sure.”

Of course, ImageMagick could do the same for scripting, and Java can do it internally. But it would be a weird, complicated lump of code in any other framework. With the building blocks already in place, such a class is both straightforward and obvious in Wicket.

And yet it would have never occurred to me to make it. Because I’m still caught up in the request cycle. The tags. The /images directory. There’s seven years of Web dust clouding my thinking. And even now, I’m thinking, “Isn’t this too slow?”

Maybe. But since we’re talking about images, the bandwidth to deliver them is your site’s first concern. And if your server does struggle with the generation load, it would be easy enough to cache things. Wicket’s attitude is, “Just give it a shot. Load-test it, optimize if you need to.”

That beats, “Shut up and point to a static image,” if you’re keeping score.