Hacker News new | ask | show | jobs
by wvenable 5359 days ago
No, I understand the issue. But you're presupposing a specific implementation here. If you were just designing this in, for example, PHP then you'd just need one piece of state: the page # (for more...) or the parent comment id (for the comment) and so on.

The real issue is that there's a whole bunch of saved state on the server for operations that could be (and should be) completely stateless.

1 comments

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.