5 ms·
I dislike forums which indent successive replies. I hate forums which indent replies and don’t support collapsing sub-threads. The proper way of handling repl
by ftth_finland 4y ago
I dislike forums which indent successive replies.
I hate forums which indent replies and don’t support collapsing sub-threads.
The proper way of handling replies is to post them under each other and support quoting.
- demindiro 4y ago> I hate forums which indent replies and don’t support collapsing sub-threads. [-] should collapse subthreads. Caveat is that the browser doesn't remember which subthreads were collapsed due to no-JS.
- have_faith 4y agoNot if each "collapse" link reloads the page and at the same time stores the preference in the backend against your username so that subsequent page loads know what to hide (:
- veidr 4y agoLOL you are so right... so much was lost when we started accepting that page reloads are expensive (T_T)
- com2kid 4y agoFor 20 years page reloads were expensive. In 1999 I had a cable modem connection that could pull down 2 megabytes per second and ping up and down the west cost well under 50ms. But forum servers were slow. Like, really really slow. When Sites like Reddit finally came to, 15 or so years later, with inline replies, they were a breath of fresh air. Back in 99 Slashdot had massive resources put into making it responsive, lots of servers thrown at it, and it was still laggy and slow compared to Reddit now days. Everyone arguing about "time to first draw being under 100ms" forgets that just a short time ago, web servers took more than 100ms to respond to a connection.
- veidr 4y agoYeah you’re not wrong. But I wouldn’t consider that 100ms, or even 500ms, “expensive”. In 1999 I would have been jealous of your internet connection — I still had a 256kbps ISDN line, and there were fast forums even then (but mostly not). I think it mainly depended on whether the sites rendered HTML on the fly (with like maybe Perl? to render database content) or... just served static HTML. Page reloads only got expensive when we decided that they would do a bunch of other shit besides that.
- com2kid 4y ago> Yeah you’re not wrong. But I wouldn’t consider that 100ms, or even 500ms, “expensive”. 100ms is noticeable, 500ms is bad. The old dial up BBSs may have been slow enough that you could watch character appear, but they were responsive! Those characters started printing right after your keypress happened. Of course it helped that it was likely a local phone call. I imagine HN ever had a 500ms response rate, the engineers behind it would consider it a failure! (Even reddit is under 500ms for many operations, and it is super heavyweight) > I think it mainly depended on whether the sites rendered HTML on the fly (with like maybe Perl? to render database content) or... just served static HTML. Yeah Perl didn't help the 90s web at all. It made stuff possible, but wow, the performance was bad. Then again web server software design back then was also a long ways away from what we know to do now.
- Nextgrid 4y ago> just a short time ago, web servers took more than 100ms to respond to a connection And yet, once you wait that 100ms or however long it takes for the server to respond, your page is fully loaded and interactive. During the loading process, your browser remains responsive and your CPU is not loaded. Nowadays, we still wait the same amount of time for the initial load, but now your CPU is at 100% parsing megabytes of shitty Javascript, and once the initial load completes, you're still not guaranteed the page won't slow down/overload your CPU again because some stuff can be asynchronously loaded (supposedly for performance reasons, even though doing it on the backend as part of the initial load would be faster in the vast majority of cases).
- have_faith 4y agoIt was a tongue-in-cheek suggestion but page reloads are pretty fast these days with http/2. Maybe there's ways of submitting a form in the background for the same effect, no reload needed! now we're surfing.
- XCSme 4y agoCan't you redirect/store the information in the URL and then somehow read the URL data in CSS?
- ftth_finland 4y agoI stand corrected. I did not recognize the [-] as it looks like some weird emoji on my mobile browser due to the too small and uncentered background.
- MetaWhirledPeas 4y agoThat's just, like, your opinion man. I prefer HN's indented approach to a typical forum listing where it's just a firehose with quotes. But the best approach is to allow the view to be switched as desired.
- eterm 4y agoHN's model is bad for high volume. Sometimes on HN you only get one top level reply on the whole page because once it puts the top top-level reply it then puts all the replies to that above the next top-level reply. So you get a vast amount of low quality replies above the next high-quality reply. For low volume it works okay because you can manually collapse but for high volume once it starts paging it breaks down and you just get further into the top level comment without properly being able to escape. Reddit's model of auto-collapsing so you get a mix of threads and top-level replies is much better for picking out the better responses.
- httpete 4y agoI made a reddit-like comment system for HN if you are curious: https://www.hackernewz.com/item/33153152 https://www.hackernewz.com/item/33153152 (link to your comment: https://www.hackernewz.com/item/33153152?commentId=33155112 https://www.hackernewz.com/item/33153152?commentId=33155112)
- rakoo 4y agoThe style is very neat. Mind sharing the source ?
- httpete 4y agoYes, I will post it on HN and Github as soon as it's finished!
- aabbcc1241 4y agoIt seems you only show top 3 levels by default, then allow manual toggle to show/hide nested replies? Also for long list of replies, you also only show first few. This design may helps "smaller comments" to surface when the conversation is relatively "mature".
- deleted 4y ago[deleted]