No, the issue is time, specifically, pg's time; using callbacks takes less programmer time than manually building every URL statelessly. Yes, it could be done another way, but it wouldn't exist at all if he'd had to do that for every link because it'd have taken too much of his time.
What is it about Arc or the architecture of HN that makes callbacks so easy and stateless URLs so hard? I've written a forum in under 3 hours the "traditional" way in PHP. I find the stateless concept a lot simpler in general. None of these links should require any server state at all.
Generated html; callbacks make for rapid prototyping by grabbing necessary state directly from the environment rather than making you specify the state field by field in the URL. Your 3 hour prototype doesn't come close to the features in this forum so it's not comparable. No links ever require sever state if you take the pains to manually specify routing and parameter information for your links, but that's something callbacks eliminate the need for by trading server state for programmer time.
I think you massively over-estimate the functionality of this site. I can actually see the immense value of using closures for maintaining state in an application that actually needs state (any site containing a progression of forms, for example). HN is ridiculously simple for a site. With few requests requiring requiring much in the way of previous state.
I understand why it's designed this way -- he's got a tool meant for more complex tasks than what it's used for on this site. He used that tool because it's what he knows. But I really can't see it saving that much programmer effort in general.
I think you over-estimate what you can do in three hours and underestimate how much non UI stuff there is in trying to keep out garbage and prevent voter rings and score karma and vary behavior based on that karma and probably a dozen other little small things.
I certainly don't think 3 hours is enough for this site but then pg has put in a lot more time in than just his initial prototype as well. But the functionality of closures and server-side state aren't needed for this kind of site at all. Nothing you mentioned above seems related to that functionality either.
It's not relevant whether they're needed or not if you use closures as your default linking mechanism because it's always the easier route. They're not needed for any site ever, they're just damn convenient. You go back through the app replacing closures with more verbose and direct linking as time permits; clearly pg hasn't found the time yet.
You could route URLs for this site with a moderately sized switch statement. The code to route everything would be smaller than the code needed to just route closures before you've setup a single one.
Obviously replacing closures with directly linking is more difficult than just using direct linking in the first place.
Incorrect; routing closures is free, automated by the web framework, something no web framework does for direct linking. Look at Rails, every Rails programmer spends a large amount of time figuring out and managing routing. Look at Seaside which uses callbacks just like this site, you can build the entire app without spending a second on routing URL's because callbacks do it for free as part of the framework, completely automated.
You get crappy URLs with closures; no other web framework provides ugly URLs like that -- but if they did -- they could do it with the same amount of effort. But routing in rails is specifically designed to separate URL presentation from the underlying action.
Hell, you can get routing for free in PHP if you just name your files like: comment.php, topic.php, upvote.php, downvote.php, etc.
Users don't care what the URL looks like, Amazon does quite a bit of business with its crappy URL's and closures allow linking to actions without having to have a resource for every action. This is extraordanaryily useful when building complex applications.
Look, I use both styles daily and I'm telling you it'll be over my dead body before I allow someone to take closure style ugly links away from me. You aren't going to convince me that manually routed URL are always preferrable.
Users who bookmark and search engines care about non-random non-expiring urls. The urls on HN are wrong in every way a url can be wrong.
Closures create a resource for every closure instance which isn't very scalable or efficient -- it is in fact the problem with this very site. It might be useful for building complex applications but it's just a liability and a waste for something as simple and busy as HN.
I'm trying to convince you that manually routed URLs are always preferable but they should be for a site like this.
