How to think about web programming with continuations

When learning web programming with the official Racket tutorials, you get steered into the topic of continuations fairly quickly. Although web programming without continuations in Racket is most definitely possible (that’s what Server: Racket is all about), you might be wondering what in the world the Racket guys are thinking when they bring up continuations so early in the discussion. Why would they do that? What do continuations have to do with web programming?

For a bit of context: Continuations, as Racket understands and implements them, are an important part—if not the most important part—of what makes the Racket web server special. Continuations for the web is the subject of a number of research papers written by core members of the Racket community. Some references to these papers can be found in the documentation, but they’re not tooting their horn, repeatedly pointing out how they’re documenting an important contribution to computer science. From this point of view, ordinary web programming without continuations is, well, ordinary systems programming. Which, of course, Racket also supports. It’s great. But the magic and glow is not as strong as it is with continuations.

With that understanding, the key insight is that there’s a natural analogy between what continuations are and how the web works. If you’ve got a dynamic web site, there’s some interaction between the user of the site and the web application. Think of a web application as a kind of interactive calculation, where the user provides some initial inputs, the server responds by taking this input and replying with some HTML that allows the user to, again, provide more input.

To better appreciate this way of thinking, it may be useful to expand the idea of input. In this way of understanding input, simply clicking on a link counts as providing input to the server. Input should be understood more broadly than filling out a form or typing in some text, choosing a value or clicking a radio button. Inputs are, generally, whatever data you submit to the server to continue to the next page. Clicking a link is just as much input as filling out a form and submitting it.

If we think of a user’s session with a web application as an interactive calculation, then continuations start to make a bit more sense. Continuations contain the information needed for the HTTP server to reconstruct where it was just a moment ago. After having reconstituted the continuation (based on the URL supplied in the request), the server jumps to exactly where it previously was, processes your newest input(s), and hit the ping-pong ball back to you, storing its latest state in yet another continuation (encoded, again, in URLs).

I’ve found that thinking this way helps to make the idea of continuations for the web more approachable, perhaps even natural. There are, of course, a number of technical details that need to be mastered, and some gotchas to be avoided. But I hope that this perspective helps to motivate the idea and make it more palatable.