Why is collapsing a Hacker News comment so slow?
github.com
github.com
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?
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 boxes where you can type / search on them, and anything with dropdown boxes like checkmarks gets a wee bit hacky.
18% of my users are on IE11. Some industries (healthcare, for example) don't change if they don't perceive something to be broken.
source: did support for a doctor some years ago
Is this the expected behavior when you collapse or show a thread? I would suggest that it is not, as most minor interactions on a page are only stored locally.
How many people actually use this feature? In order get a benefit from this feature you have to be logged into hacker news on multiple devices, collapse a thread on one device, come back to that thread later on the second device and then continue reading from where you left off. Alternatively you can just scroll past the stuff you've already read, which has a minimal cost to the user.
The benefits seem negligible for the amount of developer time that likely went into making this feature.
Both vote count and age influence the order of comments, which means that the stuff you've already read may appear below stuff you haven't read yet.
If you use the feature at all, I'm not sure why you wouldn't want collapsed comments to be in sync across devices.
I do.
> In order get a benefit from this feature you have to be logged into hacker news on multiple devices, collapse a thread on one device, come back to that thread later on the second device and then continue reading from where you left off.
I actually do exactly this. I read on my phone/laptop and later come back to the same thread (when more people have commented) on my home computer, usually at the end of the day. Having threads of conversation that you are not interested in already collapsed on multiple devices is very useful.
> Alternatively you can just scroll past the stuff you've already read, which has a minimal cost to the user.
Scrolling and quickly scanning over multiple threads is more time consuming and becomes actually annoying if you just want to passively follow a thread. If you want to follow multiple threads under the same topic, you either have to remember unique words/usernames/dates of that thread or resort to scroll & scan method mentioned above. One is annoying, the other is simply non viable for N amount of threads.
Until there is a way to subscribe to a thread, this feature is super helpful. Its actually just as good or better than a subscribe mechanism because atleast you can avoid getting multiple notifications for every single comment that get posted in the interesting thread. In the current scheme, all the irrelevant ones are already out of your way.
I don't want to scroll over all the replies just to find the next post or i want to see all replies to one post. Therefore collapsing is convenient, but the slowth is annoying.
My guess would be that the decision was made before a standardized, widely available cross-browser implementation of localstorage was a thing.
It was a long time ago now so I can't remember much specifically any more, but I think that the styling and behavior for <details> were both too limited and too inconsistent across browsers.
I do use it in some other places though, like collapsing/expanding the text of text topics from the listing pages, and it works really well for that (other than the current lack of support in Edge).
This reminds me: What happened to the markup rewrite that was announced almost 5 years ago together with the Firebase API? https://blog.ycombinator.com/hacker-news-api/
As far as I can see the markup never changed after all.
I can't be the only one who had no idea it did this? And if so, I'd could argue that there isn't really a need for it.
Now that everyone knows about it people will start using it and people will start noticing the slowdown.
Somethings are best not mentioned
Its also missing a group name, so I can expand only one details of a group.
Why is it useful?
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
Is this a correct place to use 'GET'?
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.
[1]: https://developers.google.com/web/updates/2015/12/background...
The cookie isn't the only way the vote gets there.
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...
What is relevant here is whether the cookies are SameSite and/or whether a token is required.
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.
This is not at all true. For example, say I'm a user in a dorm that uses a proxy that I have no control over. If you make your GET request modify things, that proxy may cache the request, or worse, may repeat the request later to maintain its cache.
My point is, you don't know what is between your server and their client, and even well behaved infrastructure will sometimes make or modify GET requests on your behalf, but won't do that with POSTs.
On Chrome any comment section with more than about 100 comments grinds to a halt. If I try to type in a comment there's a three second delay waiting for every letter to appear.
For whatever it's worth, I use Firefox on Windows. But I just fired up Chrome and gave it a test, and I see the same thing there. But I don't do a whole lot of HN comment browsing on my mobile device, so I suppose that's the difference.
Not terrible, but there's a noticeable (maybe ~1 second on my phone) delay. My desktop is fast enough that it still feels instant.
Also, I suspect but don't know that the table based layout makes showing and hiding elements a lot slower than it would be with, say, divs or an unordered list. If this is the case, it would probably only be exacerbated on mobile.
I see an upvote triangle, a down vote [-] and nothing else. Is this a mobile only thing ? I can't see a way to collapse comments under Chrome or Safari on a desktop.
I am out of the loop what's the secret ?
For anyone else out of the loop like me: Where's the downvote button? https://news.ycombinator.com/item?id=17731487
Here's my collapse code if interested
https://github.com/a13o/disengaged/blob/master/src/hacker-ne...
think about all the other things perfectionist coders and product managers could be working on
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.
My favorite example is probably how the "AJAX" voting works: when you vote, the Javascript creates a new <img> tag with the src= attribute set to the vote endpoint, so when the browser tries to load that "image" it does a background request.
It's the kind of dirty hack that hasn't been necessary for an extremely long time and could be replaced with a proper method in minutes, but nobody even notices that's how it works.
You can still often have better than done, though. The first working implementation is rarely the best possible one.
According to the comments here, maybe I would be better off implementing my own collapsing scheme.
1. It's not your website, why spend so much time and effort on dissecting the issue? If one did this for every webpage they visited it'd be a more than a full time job.
2. Does it really look like Hacker News has had any serious development effort poured into it anytime recently? What incentive does YC have to put time and money into a forum that generates zero revenue?
3. Do we really expect web browsing to be pleasant on a 3 year old budget smartphone with a Qualcomm 617?
The Moto G4 Plus is solidly in the bottom 25% of phones listed here:
2. No. Probably none.
3. Are you saying that you are willing to sacrifice the user experience of the bottom 25% of the users of a website?
1) This is a community with a lot of web developers and programmers, and people who have a professional or hobby interest in these problems, and are hanging out here anyway clearly with nothing better to do.
2) We have to do it here because they don't take issues and pull requests.