Sessions are evil

I recently read this on Slashdot, and it threw me into a tizzy:

"Complex page state is kept on the server, in a session-associated database. If requests are...sending a lot of data every time, which isn't user-entered on that specific page, they're not very well coded."

On the contrary, session-dependent web apps are bankrupt design-wise. They violate the (stateless) page metaphor, breaking the standard UI and confusing the user, simply because some programmer couldn't be bothered to find a good way of maintaining state. Some of my favorite denizens of the Session Hall of Shame are...

• Apps emblazoned with "Don't use the Back button while you're here or the world will come to an end! Oh noes!11!1!oneone" (Concur Solutions, I'm looking at you.) 60% of web users employ the Back button as their primary means of navigation. Usability issues surface when the Back button doesn't work the way they expect. It's an old observation, but I've yet to see it knocked down.
• The ubiquitous session timeout: go to lunch, come back, and you get to re-enter all your data. Is server space really at such a premium that you can't let sessions last a week, if you do insist on using them?
• Breakage of parallel surfing: I have the habit of opening 3 or 4 links from a page in background tabs all at once. In many overly sessiony sites, this causes weird behavior.

In these days of >100KB page loads, it's silly to sweat over 4KB typed into a textarea. If you find it painful to maintain state from request to request programmingwise, you're not using enough framework. Find something nice that'll stow user data client-side without making you think about it. Or, if you're in the mood for something exotic, try a continuation-based framework like Seaside: those let you forget about the statelessness of HTTP altogether, though admittedly at the cost of tokens which feel a bit like session identifiers but aren't quite. (They still don't break the Back button or parallel surfing, and you can set the timeout to a week.)

What I really mourn is the passing of HyperCard for the web. There was a time back in the nineties where it looked like HyperCard was going to get rolled into QuickTime and thus be available in any browser that could run the plugin. Now that would have been sweet. I suppose Flash isn't a much different result, though I hear its roots in linear-chronology animation still poke through when trying to develop apps on it. If the Flash UI were a little better—using native widgets, letting standard text selection and copy and paste work—I'd likely be won over. I suppose the best choice today is session-free AJAX with a good framework to keep the details out of your face, like KSS does in Plone. The result isn't as good as a native app or even a HyperCard stack, but it's as good as anything else on the web: not too bad to code, accessible to the disabled, happy to work with your OS's standard facilities, and still functional if you turn JavaScript off.

Thanks for reading to the bottom of my rant! I feel much better now. :-)