Live data from Hacker News

Why is collapsing a Hacker News comment so slow?

github.com

31–40 of 123 posts

Re: Why is collapsing a Hacker News comment so slow?

#31
post #16

I would use the tag to solve this problem. Most people don't know this exists and I have no idea why. You would probably have to rewrite the html so it no longer uses tables but I don't really consider that to be a negative. I would also question why we are saving collapsed comments. I feel like this is something that doesn't need to be persisted forever. If you want this behavior why not use local storage instead?

Persisting it on the server allows users to browse on multiple devices and keep their collapse settings in sync. This is useful in particular for long threads of comments, where collapsing can be used as a tool to keep track of progress through the thread by collapsing comments along the way.

Re: Why is collapsing a Hacker News comment so slow?

#32

> There is also a GET request to https://news.ycombinator.com/collapse?id=1234567 to save the state of the collapsed/expanded comment if the user is logged in, but it's an async request so it doesn't have an impact. Is this a correct place to use 'GET'?

Isn't that vulnerable to CSRF? What if a page linked on the front of HN makes a request collapsing every single comment?

One of the top posts in the history of HN was a link that upvoted itself due to this issue.

Re: Why is collapsing a Hacker News comment so slow?

#33

> There is also a GET request to https://news.ycombinator.com/collapse?id=1234567 to save the state of the collapsed/expanded comment if the user is logged in, but it's an async request so it doesn't have an impact. Is this a correct place to use 'GET'?

It does modify state on the server so I would think it should be a POST or something. even better, they could do what reddit does with upvotes/downvotes, and store that information in the user's cookie, so that it gets sent with the next request to the server.

I never realized Reddit did that. That's a really cool hack; like a poor man's version of Background Sync[1]. I guess the disadvantage of using cookies is that if you just click to vote and then close the tab, your vote might not be recorded for a long time.

[1]: https://developers.google.com/web/updates/2015/12/background...

Re: Why is collapsing a Hacker News comment so slow?

#34

Earlier quoted context omitted.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de... This is awesome! I had no idea! You're right, I don't think most people even realize. There's often times I get upset when using Bootstrap or just doing CSS and look up ways to do specific things and don't find out of the box solutions, this is one time I'm glad I found a decent alternative. One case that comes to mind is collapsible trees and dropdown b…

Note that it's not yet supported by Edge: https://developer.microsoft.com/en-us/microsoft-edge/platfor...

Edge is turning into Chromium soon, so that shouldn't be a problem for much longer.

Re: Why is collapsing a Hacker News comment so slow?

#36
post #16

I would use the tag to solve this problem. Most people don't know this exists and I have no idea why. You would probably have to rewrite the html so it no longer uses tables but I don't really consider that to be a negative. I would also question why we are saving collapsed comments. I feel like this is something that doesn't need to be persisted forever. If you want this behavior why not use local storage instead?

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de... This is awesome! I had no idea! You're right, I don't think most people even realize. There's often times I get upset when using Bootstrap or just doing CSS and look up ways to do specific things and don't find out of the box solutions, this is one time I'm glad I found a decent alternative. One case that comes to mind is collapsible trees and dropdown b…

Hmm, that's cool, I don't know how I've never heard of this before. Probably much better than some more-expensive CSS or Javascript.

Re: Why is collapsing a Hacker News comment so slow?

#37

> There is also a GET request to https://news.ycombinator.com/collapse?id=1234567 to save the state of the collapsed/expanded comment if the user is logged in, but it's an async request so it doesn't have an impact. Is this a correct place to use 'GET'?

Following the rules of REST is very important if you are presenting a public API to the world. If it's your own server you can do whatever you want. For example I used to work on servers for games and often there would be a single endpoint for processing one or more commands, and this would be technically a GET request regardless of what those commands did. Furthermore it's common to send application level error details with a 200 status code; i.e the http level transaction succeeded but the application layer produced an error. Much heated discussion emerges around these design choices :D

Re: Why is collapsing a Hacker News comment so slow?

#38

> There is also a GET request to https://news.ycombinator.com/collapse?id=1234567 to save the state of the collapsed/expanded comment if the user is logged in, but it's an async request so it doesn't have an impact. Is this a correct place to use 'GET'?

It does modify state on the server so I would think it should be a POST or something. even better, they could do what reddit does with upvotes/downvotes, and store that information in the user's cookie, so that it gets sent with the next request to the server.

Should be a PUT as the operation is idempotent.

Re: Why is collapsing a Hacker News comment so slow?

#39

I cannot visually notice any delay. It seems instantaneous in my browser.

It's really only an issue on mobile when you're collapsing larger threads. Try collapsing the first comment in this thread, for example: https://news.ycombinator.com/item?id=14656945

Not terrible, but there's a noticeable (maybe ~1 second on my phone) delay. My desktop is fast enough that it still feels instant.

Re: Why is collapsing a Hacker News comment so slow?

#40
post #34

Earlier quoted context omitted.

Note that it's not yet supported by Edge: https://developer.microsoft.com/en-us/microsoft-edge/platfor...

Edge is turning into Chromium soon, so that shouldn't be a problem for much longer.

Considering there are millions of people still using IE11, I'd say it will continue being a problem for a long time.

18% of my users are on IE11. Some industries (healthcare, for example) don't change if they don't perceive something to be broken.

Post reply on HN