Seaside – Developing Sophisticated Web Applications in Smalltalk

But Javascript has come a looong way in the last 15 years, and sophisticated web applications do a lot more client-side processing these days. That leads to different architectures, where continuations aren't as advantageous as they had been.

Hacker News is notable in that it doesn't use much client-side code and sticks to an old-school links-and-forms UI. Closures still make a lot of sense for that architecture.

Writing the code to phase out those handlers was a deep lesson for me, because the new code came out more verbose and harder to follow. One rarely gets to do an apples-to-apples comparison of programming techniques on a production system, and somewhat to my surprise the experience convinced me (I was agnostic to begin with) that the closure approach is superior.

There are at least four reasons: (1) the closure has immediate access to all the state that existed when the request was previously processed; (2) the closure is nested inside the code that creates it, so everything you need to understand a full request cycle is in one place; (3) much boilerplate is eliminated, making the code easier to read and write—it can be explicitly at the problem level; (4) security is less of a worry when the client only has to pass back a token instead of all the original parameters to the request, the latter being safely packed away in the closure. That last advantage, i.e. reduced attack surface, was particularly surprising.

Learning this the hard way, by dismantling those advantages and replacing them with manual code in selected cases, taught me something else about this design: it's more than just a clever device. It's really a triumph of two of the greatest programming ideas: first-class functions—more specifically, what used to be called upward funargs [2] back when people were arguing about whether they were a good idea—and lexical scoping. The combination of those two abstractions is what allows this model to shuffle off most of the gruntwork instead of making you, in pg's memorable phrase, a human compiler.

The fact that the design eventually hit scalability problems at millions of users is also a vindication of it, in the sense that it enabled pg to write HN more quickly and safely in the first place. We could selectively deal with the scalability problems later, and have done so. That has worked fine as an engineering tradeoff, but IMO a better solution will come from new implementation ideas that allow another couple orders of magnitude of closures to be kept without slowing down the rest of the system. If we get there, I will take pleasure in rolling all that manual code back into the original design.

1. They're closures, not continuations, which for HN is fine.

2. Meaning the ability to return a function from a function, and thus keep it around indefinitely, as opposed to passing a function to another function as a parameter (downward funargs).

[1] http://www.nagare.org/trac/wiki/NagareFeatures