Live data from Hacker News

Why is collapsing a Hacker News comment so slow?

github.com

41–50 of 123 posts

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

#41
post #9

Earlier quoted context omitted.

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.

Clean code is something you should arrive at through iteration rather than a minimum acceptable requirement to put something in production.

In general I would like to achieve the functional goal of the present in the most expedient way possible. If cruft and technical debt from being expedient yesterday is slowing me down, it's time to refactor.

Trying to write perfect code from the start is a fool's enterprise. Often times the full requirements and constraints of a problem will not make themselves known until you're halfway done solving it, or until you're on to the next related problem. Front-loading architecture and software design work often means solving problems you don't really have, or painting yourself into a corner when it turns out the problem is not exactly what you thought it was.

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

#42
post #33

Earlier quoted context omitted.

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...

That's a pretty big downside.

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

#43

> 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.

Man that gave me some ideas regarding some users I have who have crappy internet connections ....

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

#44
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.

FWIW, you can still do this with the `` tag, though. Have the page background-sync collapsed statuses back to the server and have the server remove the appropriate `open` attribute from collapsed `` on subsequent page loads.

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

#45

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...

There's a handy polyfill for that.

https://github.com/rstacruz/details-polyfill

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

#46
post #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…

I thought that the normal way to have this work without JavaScript would be to have a form tag with the submit button styled to look like the collapse button.

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

#49
Fun fact

In a previous company we were building a session replay tool, and as you may know it is pretty complex to evaluate the impact of the single script on a page.

The only way we found to test the impact of the script was to execute it on a page with the most mutations on an event, and try to see how much the event was impacted.

The only place where we found a heavy use of mutations was the hackernews page that had more than 100 comments in a thread. And the first time we tested, we tripled the time to collapse the thread

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

#50

> 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 deta…

As you say it will work just fine as long as your client and server agree, but free-wheeling it with the HTTP spec can come with operational drawbacks.

I've worked with a lot of different internal webservices as a freelancer, and if they're reasonably RESTful and built according to spec, it's easy to just get started with the codebase. Ones like you're describing mean a lot more conversations and reading through code.

Of course it depends on the nature of your team and how often you on-board, but to me the HTTP spec is one of those things like following coding style conventions: sure you don't need to do it, but at the end of the day it's not that much more work once you're in the habit, and it makes it that much easier to work with other people.

Post reply on HN