The 3 elements being removed are the tr containing the story options, a literal whitespace node, and a tr used as a spacer.
I agree it is a coupling, and while accurate to describe as fragile or even really fragile, I personally would not have used those words.
I would feel more comfortable daring to make changes in this html and JavaScript than any other front-end code I've worked with in the last 15 years of my career. If for no other reason, the sheer small size of it and lack of external dependencies that you mentioned.
It's terse and effective, I suppose, but it was really interesting measuring pixels to judge comment nesting.
The JS itself is fine. It's the markup that's a mess.
There's also simply no reason to change it, it works.
It works, and it's arguably simpler than the div-soup with extensive styling, which is the "kosher" way of doing this.
As for the redesign, the total amount of code (HTML/CSS/JS) you’d need to touch is still small. Do web designers still exist that only do HTML/CSS but no JS?
I hope so, given that most websites (as opposed to web apps) in existence should not need JS for core functionality.
That is really beside the point. HTML and JS should not be coupled to the extent that adding or removing some whitespace from the HTML will cause the JS to fail. This kind of things turns a trivial improvement into a nightmare, so you end up not daring to change anything.
Right now there's already nested tables-within-tables, just to work around how table columns work in order to handle indentation (and each row's indentation is handled separately with a stretched 1x1 image with a width attribute that's calculated server-side).
But it is simple, and it does get the job done for the most part.
Either way, it's a minor annoyance on an otherwise fantastic site!
If there is such information, there are two possibilities: either we could easily modify the code to express it; or we could not. Each would be interesting, but for different reasons.
for (var i=0; i < 3; i++) { remEl($(id).nextSibling) } // pop following options row, whitespace text node, .spacer
More generally, going a step further, I've been inspired in my commenting style by Jeremy Ashkenas's literate code for the Backbone library. See, for instance, http://backbonejs.org/docs/backbone.html#section-111 . The code itself is as self-explanatory as any other code I've ever seen, but the comments serve to accelerate that browsing process. Backbone, while somewhat dated nowadays, is a great level of abstraction in that the entire library can be grokked in an afternoon - but without comments, I think it would take longer. Reading time does not monotonically increase with number of characters :)
And as a third point, if there's ever something confusing enough, or you're using some infrequently-used feature of the CSS/DOM spec, such that the author or reviewer needed to look up how it worked in documentation or a forum somewhere, I encourage my team to simply add that documentation or forum link into the comments. Extremely helpful for maintainability, particularly when onboarding junior team members, allows code reviews of that line to be asynchronous whereas they would otherwise require synchronous explanation, and it's ideally just as quick to keystroke "select-url/copy/close-documentation-tab/tab-into-codebase/start-comment/paste/enter" as it is to "close-documentation-tab/tab-into-codebase."
This is Hacker News - we're the antithesis of enforced Javadoc-style comments :) But if you consider someone needing to read code without having the live input of the author, minimal comments for especially terse or creative code can quickly start to make sense, certainly in the territory of the rightmost columns of https://xkcd.com/1205/
To be honest the code is not very readable, but it is very simple and self contained. It would be very easy to dive into to fix a bug because there are no external dependencies or frameworks you have to understand.
The list of one-liners at the top seem like a very minimal 'jQuery'-like layer. Perfectly fine except for the l33t identifier names.
But there is also some really fragile coupling to the HTML, e.g.:
I wouldn't dare to modify the HTML when the JavaScript looks like this! What are the three elements which are being removed? Why exactly three? Probably the author and maintainer of the code knows, but this is the kind of coupling where nobody except the original author would dare to change anything. Perhaps this why HN still uses tables for presentation - nobody dares to change it?