Am I misunderstanding, or would this require the server to hold state for every client that has been delivered a form, but not yet received a form submission?
That seems like a bad architecture for a web app.
A long time ago I wrote web apps in WebObjects (originally NeXT, then Apple). While it didn't use continuations, it did rely on maintaining server state for every client, in order to try to make writing a web app transparently as much like writing a 'native' (we didn't call them native then) app as possible. That aspect of architecture -- persistent client-specific state on the server meant to be tracking what the client was doing -- was a fundamental mismatch for the web, and led to lots of complexity and problems. While it seems like it can/should be transparent/automatic (and that was the intent of the WebObjects archiecture), it ends up an abstraction with significant leaks, just because it's such a poor match for the mostly stateless web client-server architecture.
That was my first take too. There was a lot of awful middleware in the 1993-2007 or so period that were heavy in back-end state. Something close to the continuation style is binding a process or thread to the session id. For instance, the library management system Voyager had a telnet interface that they hacked a front end onto.
One trouble with that kind of system is each session requires a lot of memory so you have to implement a timeout and no matter how long you make the timeout, users are going to be mad if they got through 15 pages of forms, had to wait on hold on the phone to get the information for page 16 and then they lost it. People expect to be able to walk away from Microsoft Word on Friday and still be able to use it on Monday, etc.
Continuations are much more memory efficient but still have challenges. I am having a lot of fun with python asyncio, but you can't pickle tasks out of the box so you can't migrate tasks between servers on a cluster, reload them after a crash, flush them out of memory if memory is tight, etc.
That is one option, but you can also architect the system such that the client holds most of the state either in the URL or in a hidden field (signed by the server to prevent tampering, and optionally encrypted). You'll still need the server to track some aspects of the session, for example to prevent accidentally submitting the same order multiple times.
Just the other day someone posted something here about defunctionalizing continuations. That's the way to go: whatever amount of state the server has to hold, you have to hold anyway, and clever defunctionalization will let you just hold that amount even with a continuation-based approach.
The concept of continuations is well-established and they have their uses. They have been part of the landscape for years. They can be confusing, and that's impossible to separate from their power.
The inversion of control that this paper is talking about is the way an application running on a webserver typically gets called by the browser rather than the other way around. Continuation-based webservers reverse this inversion and create an illusion of continuity of control flow on the server side. The application is suspended when a page is sent to the browser and resumed (via a continuation) when the response arrives. So this is about permitting server-side applications to be written in a nicer style as far as control flow is concerned.
I think you are getting downvoted because your comment more or less says that you don't know much about the background, and haven't read and understood the paper, but are inclined to dismiss it anyway.
Same here. when I read/see IoC my immediate thought was Java/Spring. And yes, for the most part IoC as a concept is dying. More and more developers want to hold a function that returns hammers. They don't want a hammer factory factory factory anymore.
That seems like a bad architecture for a web app.
A long time ago I wrote web apps in WebObjects (originally NeXT, then Apple). While it didn't use continuations, it did rely on maintaining server state for every client, in order to try to make writing a web app transparently as much like writing a 'native' (we didn't call them native then) app as possible. That aspect of architecture -- persistent client-specific state on the server meant to be tracking what the client was doing -- was a fundamental mismatch for the web, and led to lots of complexity and problems. While it seems like it can/should be transparent/automatic (and that was the intent of the WebObjects archiecture), it ends up an abstraction with significant leaks, just because it's such a poor match for the mostly stateless web client-server architecture.