Show HN: Show descendant count on Hacker News 'more' links
gist.github.com
gist.github.com
This Tampermonkey script modifies your HN so that you see how many comments are waiting for you at each 'more' link.
I find it much easier to browse HN now. It's immediately clear whether I'm missing a large subtree.
It's nice for distinguishing 'more' vs 'reply', too. (I originally didn't notice it was a new feature, and rushed off to report a new "hidden comment bug," ha.)
If you don't want to install a Tampermonkey script, or you want to preview how it looks, you can open your browser console and run the JS directly.
[...byTag(document.body, 'a')].filter(x => x.innerText == 'more').map(x => { x.innerText = `${byClass($(x.href.split('item?id=')[1]), 'togg')[0].attributes['n'].value - 1} more`;
Enjoy.
I'm going to revert it now. Sorry for the inconvenience—I didn't mean to leave things in a state that people needed to write code to compensate for.
Some similar feature is likely to appear sometime soon because we badly need to do something about top-heavy pages. But if we use the 'more' links, they'll show number of descendants. It will either be 'more' links or starting off the sub-subthreads as collapsed. The disadvantage of the latter is that if there are 10 replies that need collapsing then you'd need to show 10 collapses, which is a pain.
This was just me being excited about having something small to do related to HN. I'm sorry I presented it badly.
(It's not like I was like, "ughh, I have to write codeee..."; that's the best part for me. I just wish I could help you with the performance issues or the Common Lisp port, but I don't know if you're keen on that, and I doubt the codebase is modular enough to share it sans the sensitive bits anyway.)
Some similar feature is likely to appear sometime soon because we badly need to do something about top-heavy pages. But if we use the 'more' links, they'll show number of descendants. It will either be 'more' links or starting off the sub-subthreads as collapsed. The disadvantage of the latter is that if there are 10 replies that need collapsing then you'd need to show 10 collapses, which is a pain.
For what it's worth, having that number made all the difference. Seeing "9 more" vs "2 more" was a huge signal. If you haven't tested out HN in that form, I encourage you to try; it felt incredibly natural. I'm serious when I say it didn't feel like much of an inconvenience.
But... if you start subthreads collapsed, it means it's loading all the comments, so I don't see why it would help with performance. So this seems like a social design issue. In that context, are you sure top-heavy pages are a problem? If so, alright, but for what it's worth the [-] button worked wonderfully for me. Maybe others feel differently.
Anyway, just happy to see you trying new things once in awhile. Have a good evening.
If we went with the collapse UI for this, we'd have to lazyload the comments on uncollapse. That would be a pain, which is another argument for using 'more' links rather than collapses to solve this particular problem.
On the other hand, it breaks the UI paradigm to have to go to a different page to continue reading a subthread, and there would be strange consequences (e.g. if you click 'parent' to go to the parent subthread, then the 'more' links will switch to a different set of comments).
For what it's worth, I ran across this situation, and it felt very natural -- but only after adding the descendant count. I'd get curious about a subtree, click into "9 more", read it, see "2 more" on the last comment, and click again. It felt a bit like Numen in that sense.
The flip side of that is, I'm not sure anyone's going to bother writing a long, thoughtful reply after maxnest* depth. They'd have to really love writing for the sake of writing, since orders of magnitude fewer people will see their more'd reply.
But maybe that's a good thing. I don't have the experience to know. If you feel it's fine to change HN's social dynamics like that, you're probably right.
> If we went with the collapse UI for this, we'd have to lazyload the comments on uncollapse.
If this is all a performance concern, please, let me try to fix it somehow. I can work independently on it, and simulate the same number of page views that HN currently gets. I bet you a dollar that I can find a simple, overlooked solution.
I understand that's probably not an option, but email me at shawnpresser@gmail.com if you see a way.
(The reason I'm being persistent about this is, I hate accepting that Lisp can't scale. There must be a way. If there is, I'll find it; as someone whose replies will end up more'd or collapsed, I'm quite motivated to find you a third option.)
Note that my original bug report to you was correct, but initially you weren't sure what I was talking about. (I realized later that you were probably referring to the "more" links at the bottom of the page vs how many toplevel comments show up per page.) I suspect a lot of my past awkwardness with you was due to such miscommunications. I'm not sure why those happen. But all I can do is try to be clear and precise, and only say something when there is something worth saying.
Maybe someday when things settle down, you'll be able to release your HN browser extension. I'm really looking forward to it, whichever year it comes.
Good luck battling the performance beast.
I'm just a bit concerned because this is always something I've disliked about e.g. Reddit. It cuts off conversations and arbitrary points, and jumping back and forth between replies and the main thread breaks the flow. On HN I can simply collapse the top reply whenever I've personally become bored of a thread and want to move on.