This approach to webdev (continuations) could be so cool. I just wish there was a framework on the level of django/rails so that I could feel comfortable using it for a large product.
The Lift web framework in Scala is somehow similar in that aspect. It has been used on multiple bigger sites like foursquare. I really like the approach compared to MVC.
Racket does stateful and stateless servers, and the continuations are either stored on the server or the client per which type you choose to implement [1].
Not just way back; HN uses continuations. (Not in many user-visible places any more, but every link on the front page used to be one—expired "next page" continuation links were a frequent source of grumbling.)
Note that you don't have to expire continuations, necessarily—you could actually persist them statelessly (i.e. without server-side state), by shipping their encoded representations to the client embedded into HMAC-signed links. You're basically giving the server a raw bytecode-eval endpoint, and then making sure that it only accepts code you yourself wrote. Kind of a crazy strategy compared to the standard predeclared REST API, but interestingly flexible.
Now that you mention it, I can't think of very many languages that define a language-standard persistent encoding of a continuation on a closure. One that I can think of is Erlang.
Said spec is nominally "about" the wire protocol Erlang nodes use to communicate with one another in a distributed system. But the ETF format defined there is much more general, and is used all over the place (e.g. when persisting values in Erlang's DETS tables to disk.) It's what you get when you call Erlang's global term_to_binary/1 function.
Erlang's ETF could probably be most closely compared to Python's "pickle" format. (Though, sadly, you can't pickle a lexical closure in Python.)
Even Erlang's approach is sort of a hack. As can be seen from the format spec, Erlang doesn't actually encode the AST of the closure; instead, they ship a reference to a symbol-table ref in a module. Erlang's closures are all implicitly hoisted out into their own gensym'ed functions and then exported from their module to allow for this. Each node assumes the other nodes in the same distributed system all have access to the same modules (not that they all necessarily have it loaded, but that they can load it Just-In-Time when dereferencing the closure) and so the export-table reference can be turned back into a handle on the closure at the receiving end by looking it up in its module.
What this all means is that, although Erlang nodes can rehydrate closures from other nodes that are running the same code, they can't rehydrate arbitrary closures defined and serialized at your personal REPL running different code. (Which defeats half the purpose; you can't then use dehydrated closures as an arbitrary query/callback/RPC syntax between Erlang-based microservices, unless they all share code.)
On the other hand, there's nothing explicitly stopping the Erlang Run Time System from supporting the full version, where a closure is dehydrated as its AST (plus free vars, as in ETF encoding.) And so this is exactly what Elixir does. Yet another reason Elixir is an interesting language.
So what's encoded are the closed variables along with the gensym'ed name of the closure (effectively a pointer to the code)? If so, that's pretty useful. For some cases it's better than serializing the code, because then you don't have to pass a copy of the code around everywhere, only the state that you don't keep a copy of.
It uses continuations to hide the asynchronous nature of web requests and allows the flow between pages of a web app to be written in an imperative style.
There are a couple of continuation-based web frameworks for Ruby (Borges, Wee), but they're old and abandoned as far as I know.
I suspect it didn't catch on because (1) people are afraid of continuations, and (2) web apps are typically designed in at least a pseudo-REST-like style, so the paradigm of "asking" the user (like "await" in ES6) isn't needed very often.
But it's a cool thing to be able to do, especially for funnel-type flows, and other types of more complex session-based interactions.
I wonder if there are any JavaScript inversion of control things for client side code. I've been working for the past week on a signup funnel with React and Flux, and it's just a big explicit state machine... which kind of works, but is also kind of tedious.
There were client side JavaScript continuation like things. Back in the mid-2000's there was Narrative JavaScript. I used it to implement threads and Alice ML style futures/promises on the client side: https://bluishcoder.co.nz/2006/06/05/more-concurrency-in-nar...
