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 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.