[pg]

It doesn't make sense to call any specific amount of traffic "normal conditions."

What's good about this technique, and about rapid prototyping in general, is that you can write an initial version quickly in very little code, then gradually make it more efficient as the demands on the app increase.

The rate of expired links says more about how busy I personally have been lately than about the desirability of storing state in closures.

[bkmartin]

I'm not referring to any specific amount of traffic. I'm referring to how users expect a website to work. If the user sees a link, especially a More or Login link then the user expects it to do just what it says. When those don't work I would call that a bug. I'm in agreement that this technique can be useful for rapid prototyping, but I also think this site is probably the most active and mass used prototype I've ever seen. ;)

My goal for a web site or web app is to have 0 expired links. Sometimes stuff you link to outside your site will go dead, and it must be fixed or removed or whatnot. But for your own internal stuff... I don't know... something doesn't feel right about an architecture that allows that systematically. How much time could you save if you didn't even have to worry about fixing any expired links? Any idea on what the ROI on your time would be?

Anyway, just thinking out loud. Thanks again for the site though. I do indeed enjoy it very much regardless.