One of the reasons I like blogging is that writing about a subject forces me to consider it in more depth than I would if I were just mulling over it in my head.
For example, I sat down tonight to write a sanity-check about continuation-based web programming, and in the process of gathering my thoughts on why I'm wary of the idea, I've managed to develop significantly more respect for it than I had before I started writing. As I examined each of my issues with the concept in enough detail to write about them, I discovered they weren't really problems at all.
Except one, at least with the two frameworks I looked at.
In the oft-cited Smalltalk continuation framework Seaside and it's Ruby port Borges, all links are anonymous callbacks, and thus are meaningless, transient strings bunged on the end of the application's base URL. The developer of Seaside has this to say about it:
People often complain about having "meaningless" numbers in the URLs, but they enable a level of abstraction over HTTP that wouldn't otherwise be possible.
To me, that's a deal-breaker. The URL is a Uniform Resource Locator. Making URLs no longer point to resources takes an enormous amount of the web's power away in order to make the programmer's life easier.
As a random example, take web stores. I can copy an Amazon URL from my location bar, paste it to a friend in e-mail or an IM, and that friend will see exactly the same product that I'm looking at1. Whenever I go to a site, find something I want someone else to look at, paste them the URL and discover they've encountered a "This is not your session" message, I make a strong mental note to avoid that site in the future.
Getting rid of bookmarking and deep-linking essentially lobotomizes the web, and to me makes such frameworks useless for most public-facing web applications2.
Even for internal systems: ever implement a login system for a web application? There's a reason that the post-login redirect has to take the user to the deep-linked page they were trying to reach originally, rather than the application's front page: users demand it.
1 If you can do this with Seaside, it would essentially be session hijacking. Even more nastily, the continuation-based approach would mean someone who intercepted a URL (or dredged it out of a recent browser history file) would be able to seamlessly resume some other user's session at an arbitrary point.
2 The most likely exceptions being completely private applications with a shallow interface such as web-mail or banking.
