Why is collapsing a Hacker News comment so slow?
1–10 of 123 posts
Re: Why is collapsing a Hacker News comment so slow?
#2That is really ugly code.
Re: Why is collapsing a Hacker News comment so slow?
#3> 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'?
Re: Why is collapsing a Hacker News comment so slow?
#4> 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.
Re: Why is collapsing a Hacker News comment so slow?
#5> 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'?
>Is this a correct place to use 'GET'?
Not at all; GET requests are specified [0] to not cause any modifications to the resources (aside of meta-data like logging etc.). It should also be 100% safe for web spiders to issue any GET at any time [1], server overload aside.
I presume it's an artifact of earlier implementation -or just an idea- to have the collapse work without JavaScript. It would be doable with a normal A HREF with the current link format of https://news.ycombinator.com/collapse?id=20336970
--
[0] "In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval." - https://tools.ietf.org/html/rfc2616#section-9.1.1
[1] in the early day of the internet, a friend lost most of his CRM's content because he had record deletes implemented as A HREF issuing GET requests. Having learned the lesson, he instead turned to JavaScript code issuing GETs...
Re: Why is collapsing a Hacker News comment so slow?
#6That is really ugly code.
For me HN is a great reminder that done is better than perfect.
Re: Why is collapsing a Hacker News comment so slow?
#7> 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'?
>Is this a correct place to use 'GET'? Not at all; GET requests are specified [0] to not cause any modifications to the resources (aside of meta-data like logging etc.). It should also be 100% safe for web spiders to issue any GET at any time [1], server overload aside. I presume it's an artifact of earlier implementation -or just an idea- to have the collapse work without JavaScript. It would be doable with a normal…
The weight of a well used ellipsis...
Re: Why is collapsing a Hacker News comment so slow?
#8Re: Why is collapsing a Hacker News comment so slow?
#9That is really ugly code.
For me HN is a great reminder that done is better than perfect.
Solving a real problem with clarity and simplicity of use by knowing your target users is far more important than clean code. However, in the long run, you need good code in order to keep doing this.