4 ms·
Yeah, all fair points. Client-side AJAX apps also allow you to keep state from one request to the next, instead of tossing it back and forth over the net. You
by cousin_it 11y ago
Yeah, all fair points.
Client-side AJAX apps also allow you to keep state from one request to the next, instead of tossing it back and forth over the net. You can use closures on buttons and everything. In some ways it's even more natural than keeping state on the server, because the client knows exactly how long the page stays open. And it doesn't break when you have lots of users, because they keep the state instead of you. I guess that's part of the reason why AJAX got so popular :-)
That said, if I were building a site like HN, I wouldn't use any of that stuff. I'd go with a bog standard request-response model. There's just not that much state to be preserved. Except maybe draft comments, but these should go in browser storage anyway.
- dang 11y agoRe Ajax, yes, but there's plenty of state that you can't send to the client. For HN, an example would be the list of known spam sites. > There's just not that much state to be preserved Are you sure? From my perspective there's enough to make the complexity difference in the two models significant.
- cousin_it 11y agoNo, I'm not sure. But from a quick look, it seems like most GET handlers on HN take at most two parameters, except for "flag" which takes three. The POST handlers take more, but that's stuff that needs to be sent to the user anyway, because the user is editing it. Out of the stuff that I did see, the "goto" parameter is the most obvious candidate for the closure treatment. It's also the most obvious candidate for the AJAX treatment, if you add in-place editing like on Reddit, which would be a better UI in my opinion. Sorry if that sounds arrogant! Of course there could be a lot of functionality that I've missed.