Hacker News Reader

I think the purpose of 'aeach' is not to rename, but to provide a conversion. 'aeach' converts to an array in order to be able to perform a 'forEach' on the non-array NodeLists.

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.

I did a lot of work on HNES for performance, and most of it was assigning meaning to HN's markup. I don't know if it's intentionally opaque or what, but this is just the way it is. The javascript and the html are bound together.

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.

Perhaps this why HN still uses tables for presentation - nobody dares to change it?

There's also simply no reason to change it, it works.

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

Well using divs would at least make you able to group the elements semantically so you could remove a single node rather than having a for loop which removes exactly three nodes. This would be significantly simpler in my opinion. And it would be less fragile since now you can redesign everything inside this node without the JavaScript breaking.

I expect the layout would also be simpler in another way: Give every "child" div a static indentation, nothing more. They'll nest and the indentation will stack the deeper the comments go.

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

Or better still, use the HTML elements whose sole purpose is to display nested content: <UL> and <LI>

Agreed. But getting divs to do what you want has also gotten considerably easier in the last 10 years. It used to be a lot more work/boilerplate to get a consistent div-based layout across all browsers down to IE 6.

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?

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

> Do web designers still exist that only do HTML/CSS but no JS?

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.

I'd argue it's far from ideal. Mainly because closing a large tree of comments can often hang the UI for a second or so while this JS runs to find and hide all the children that need to be hidden.

But it is simple, and it does get the job done for the most part.

It's true that the code is slow on large threads. That's on our list to fix. The last time I profiled it, it was (surprisingly to me) forEach that showed up as the culprit.

I figured, and to be honest it's not that big of a deal. I swear it used to be much worse when the collapsing comments first came out, but as I made that comment I realized that I actually had trouble triggering it.

Either way, it's a minor annoyance on an otherwise fantastic site!

Guys, it's 2018. Let's not have this conversation.

Sure, don't fix it if it ain't broken. Today there is no reason to use tables for presentation, but that was probably not the case when HN was initially designed many years ago.

When I last looked into it, tables caused issues for screenreaders and the like.

You could reach a happy medium if everything was well commented. Introduce a build step to strip comments if you have to. But you would get maintainability while still having full visibility into all the code that is executing.

It might be interesting to see an example of a comment that you (or anyone) thinks would add to maintainability. What isn't expressed in the code?

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.

It's probable that HN is so feature-frozen it's not worth doing at this point, but if it were not, there are a few good reasons. The parent's example in hideStory() is a good start:

    for (var i=0; i < 3; i++) { remEl($(id).nextSibling) } // pop following options row, whitespace text node, .spacer

This way, if (for instance) someone were to try to modify the layout to use margins rather than spacers, or if someone were to strip whitespace from the rendered HTML, a quick search (or manual skim of the code when something breaks) for "spacer" or "whitespace" would help someone avoid needing to step through what's being removed in Dev Tools. Minimally invasive, would greatly help someone doing code review, and doesn't even increase line count. Documenting the helper methods at the top would help newcomers to the codebase as well.

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/

While I agree that comment would be very helpful given the code, It would be much better to rewrite the code so it didn't have to know about those three nodes at all. For example by collecting them into a single element which could be removed in a single operation. The comment here is just a bandaid for code which is much more complex than it needed to be.