Ian tried commenting here, but it apparently didn't work - that Javascript form may be more trouble than it's worth. Anyway, to the meat of his new post: he says that I missed his point, by assuming that by "resources" all he meant was memory. Based on his original post, that is how I took it. However, he explains further, and lists resources that GC doesn't typically handle: database connections, sockets, (etc, etc).

Here's why I didn't consider that - because all of that is at issue in any web app that maintains some kind of session state on the server. Whether you use continuations or cached data in some other form, you end up dealing with all of that (unless you re-open everything on each submit - which tends to get expensive). Typically, you use the finalization mechanisms of your language/library of choice to deal with that: the session times out, finalization kicks in, and you clean up. I fail to see how continuations make this more (or less) complex.

As to this on the back button amd continuations:

I'm not claiming that it's impossible to handle the back button this way. I'm just saying it's a bad idea, because you need to be able to write code that can tolerate being wound back and forth at the user's whim.

That's precisely the complexity that continuation based servers remove from your purview. In a "standard" we app, you tend to toss some kind of page key around, so that you can tell where you are (as opposed to where your app thinks it is on the server). How that's simpler, I have no idea. Having written a number of web apps in the standard way, I'm not prepared to call it simple.