4 ms·

He is wrong. It is not “quite bad”. I appreciate your generosity to him but I am sad to see that is the top comment.

by netfl0 7y ago

Deimorz 7y ago
How could it possibly be considered a good thing? I've seen dang say before that they've been running into performance issues, and I bet that they'd see a significant drop in resource usage solely by not generating entire comments pages just to throw them away every time anyone votes on a comment. The response is literally not used at all, they're doing that work and sending that data for no reason. There are multiple downsides and not a single benefit to the current method.
- samtheprogram 7y ago
  It's implemented this way for balance of a simple implementation and how lightweight it is. Not to mention, there is at least one benefit: the voting mechanism doesn't depend on JavaScript. And if you are not authenticated, you are instead taken to a login page. Logging in then gives you the redirect and the upvote is registered.
  - 171243 7y ago
    So just to clarify, this behavior seems to be by design. In that case it does seem the original comment is objectively wrong if the code is readable and maintainable and accomplishes the desired behavior.
    - csande17 7y ago
      As parent comments mention, sending back the whole-page response when you vote on a comment is a great idea if you have JavaScript disabled or aren't logged in. But it'd be a quick performance win if it didn't do that when you were logged in with JavaScript enabled. The actual JavaScript part of this is actually already implemented -- that's why the page doesn't refresh when you upvote my comment -- so you'd just need one if-statement on the server side to send a blank response instead of a redirect. Sure, 10 KB of download and the server CPU time needed to re-generate the listing page is probably pretty negligible, but multiply that by the number of votes casted on Hacker News every day and it starts to add up.
      - Deimorz 7y ago
        Exactly, and it even adds up quickly for a single user in common cases like voting on a bunch of comments while reading a thread. If someone loads this thread right now, the initial page load is 61KB (gzipped). If they read down the thread and vote on 30 comments while they're doing it, they transfer an additional 480KB (16KB/vote [1]). There's no reason that they should be receiving 8x more data by voting on a relatively low number of comments (~10% of the thread) than they did when loading the entire page originally. It also has to re-generate the page an extra 30 times unnecessarily - a repeatedly voting user becomes like a heavy multiplier to your traffic. [1]: Also, I just noticed that the responses back from voting actually aren't the full page, they're truncated. It seems like maybe the response size is capped at 16KB gzipped? That implies that there's already some kind of special handling for the voting responses.
        southerntofu 7y ago
        From what i can see, the response only contains the comment you upvoted and its children. It's important for people like me who don't have Javascript, but the JS voting system could probably do with a simple HEAD request.
      - TeMPOraL 7y ago
        Seconding. Sending back the whole page on AJAX upvote seems unnecessarily wasteful, and sounds like something trivially fixable. Taking data from 2.5 years ago[0], HN has ~300k daily uniques. Assuming 10% of that are users, each upvoting one story, that's 30k unnecessary page renders per day. That's ~2% of the total views (though the more expensive views - AFAIK when you're logged out, you get cached pages?), so on the one hand it's not much, but on the other hand the fix should be trivial and have minimal impact on code readability. -- [0] - https://news.ycombinator.com/item?id=9220098 https://news.ycombinator.com/item?id=9220098
  - jbverschoor 7y ago
    You can return NO_CONTENT on a successful request, and the browser will do nothing.
  - zzo38computer 7y ago
    It is possible to do both. Such as, have the link like it is now, but add a JavaScript code which replaces the link with one that executes the JavaScript code to make a request that returns nothing (if you are logged in). If JavaScript is disabled or unimplemented, it will still work.
- roenxi 7y ago
  > How could it possibly be considered a good thing? It will work with any possible browser under any reasonably foreseeable condition with no maintenance on the part of the HN crew. > I bet that they'd see a significant drop in resource usage solely by not generating entire comments pages just to throw them away every time anyone votes on a comment. If there is a serious performance problem they will presumably do some analysis and make changes related to the most serious bottleneck. > There are multiple downsides There are multiple irrelevant hypotheticals. If anyone cares about the heavy-weight HN, I hope they don't accidentally click the link to the article and discover the wider internet with images and whatnot.

He is wrong. It is not “quite bad”. I appreciate your generosity to him but I am sad to see that is the top comment.

by netfl0 7y ago

He is wrong. It is not “quite bad”. I appreciate your generosity to him but I am sad to see that is the top comment.

How could it possibly be considered a good thing? I've seen dang say before that they've been running into performance issues, and I bet that they'd see a significant drop in resource usage solely by not generating entire comments pages just to throw them away every time anyone votes on a comment. The response is literally not used at all, they're doing that work and sending that data for no reason. There are multiple downsides and not a single benefit to the current method.

samtheprogram 7y ago
It's implemented this way for balance of a simple implementation and how lightweight it is. Not to mention, there is at least one benefit: the voting mechanism doesn't depend on JavaScript. And if you are not authenticated, you are instead taken to a login page. Logging in then gives you the redirect and the upvote is registered.
- 171243 7y ago
  So just to clarify, this behavior seems to be by design. In that case it does seem the original comment is objectively wrong if the code is readable and maintainable and accomplishes the desired behavior.
  - csande17 7y ago
    As parent comments mention, sending back the whole-page response when you vote on a comment is a great idea if you have JavaScript disabled or aren't logged in. But it'd be a quick performance win if it didn't do that when you were logged in with JavaScript enabled. The actual JavaScript part of this is actually already implemented -- that's why the page doesn't refresh when you upvote my comment -- so you'd just need one if-statement on the server side to send a blank response instead of a redirect. Sure, 10 KB of download and the server CPU time needed to re-generate the listing page is probably pretty negligible, but multiply that by the number of votes casted on Hacker News every day and it starts to add up.
    - Deimorz 7y ago
      Exactly, and it even adds up quickly for a single user in common cases like voting on a bunch of comments while reading a thread. If someone loads this thread right now, the initial page load is 61KB (gzipped). If they read down the thread and vote on 30 comments while they're doing it, they transfer an additional 480KB (16KB/vote [1]). There's no reason that they should be receiving 8x more data by voting on a relatively low number of comments (~10% of the thread) than they did when loading the entire page originally. It also has to re-generate the page an extra 30 times unnecessarily - a repeatedly voting user becomes like a heavy multiplier to your traffic. [1]: Also, I just noticed that the responses back from voting actually aren't the full page, they're truncated. It seems like maybe the response size is capped at 16KB gzipped? That implies that there's already some kind of special handling for the voting responses.
      - southerntofu 7y ago
        From what i can see, the response only contains the comment you upvoted and its children. It's important for people like me who don't have Javascript, but the JS voting system could probably do with a simple HEAD request.
    - TeMPOraL 7y ago
      Seconding. Sending back the whole page on AJAX upvote seems unnecessarily wasteful, and sounds like something trivially fixable. Taking data from 2.5 years ago[0], HN has ~300k daily uniques. Assuming 10% of that are users, each upvoting one story, that's 30k unnecessary page renders per day. That's ~2% of the total views (though the more expensive views - AFAIK when you're logged out, you get cached pages?), so on the one hand it's not much, but on the other hand the fix should be trivial and have minimal impact on code readability. -- [0] - https://news.ycombinator.com/item?id=9220098 https://news.ycombinator.com/item?id=9220098
- jbverschoor 7y ago
  You can return NO_CONTENT on a successful request, and the browser will do nothing.
- zzo38computer 7y ago
  It is possible to do both. Such as, have the link like it is now, but add a JavaScript code which replaces the link with one that executes the JavaScript code to make a request that returns nothing (if you are logged in). If JavaScript is disabled or unimplemented, it will still work.
roenxi 7y ago
> How could it possibly be considered a good thing? It will work with any possible browser under any reasonably foreseeable condition with no maintenance on the part of the HN crew. > I bet that they'd see a significant drop in resource usage solely by not generating entire comments pages just to throw them away every time anyone votes on a comment. If there is a serious performance problem they will presumably do some analysis and make changes related to the most serious bottleneck. > There are multiple downsides There are multiple irrelevant hypotheticals. If anyone cares about the heavy-weight HN, I hope they don't accidentally click the link to the article and discover the wider internet with images and whatnot.