[brundolf]

I say this as a front-end dev who has worked on, among other things, several SPAs

Downsides of infinite scroll:

- Requires JavaScript (adds complexity, especially when site doesn't already require dynamic rendering)

- Loose/unpredictable UX behavior can be discomforting (loads when you don't want it to load, doesn't load when you want it to, scroll bar suddenly changes size, etc)

- Reloading the page/clicking the back button loses your position

- Monotonically-growing DOM slows things down eventually, unless you start de-rendering previous "pages", which adds even more complexity and unpredictability (Ctrl+F doesn't behave as expected, for example)

I think it can make sense for some things, but not for a simple and stable website like HN. Even for something like Twitter I wish they hadn't added it.

[yakubin]

> - Monotonically-growing DOM slows things down eventually, unless you start de-rendering previous "pages", which adds even more complexity and unpredictability (Ctrl+F doesn't behave as expected, for example)

Is this what Twitter is doing? Is this why Ctrl+F almost never works there?

[brundolf]

Yeah, I believe so. They pull some additional tricks to keep the scroll bar from going crazy, probably by (I'm guessing) measuring the height of the segments being removed from the DOM and then explicitly padding things to match that size dynamically.

There's a more general principle here where, once you start trying to override core browser behaviors, you usually end up with a never-ending rabbit hole of corner cases that you now have to cover yourself that used to be handled for free (and probably with better performance, and stability, and accessibility...), and an ensuing complexity-explosion in your code. I won't say it's never worth it, but it's something you should really really put a lot of thought into before you go down that road. All other options should be exhausted first.

[mooreds]

+1 for letting the browser do what it's good at. So many people try to re-invent the browser in HTML/the DOM and end up doing it poorly.

[brundolf]

Sometimes there is no choice. For example, want tooltips for each option in your dropdowns? Well, that's simply impossible in the native HTML version.

So if you want them, you're going to have to implement your own dropdown from scratch. Complete with keeping things from going off-screen, overflow behavior, type-in behavior, some sort of mobile-friendly UX for touch devices, etc etc. Oh, and screen readers/accessibility browsers will almost certainly not understand it.

So then the question you have to ask yourself (or your PM) is: how badly do we really need those tooltips? Sometimes the answer is, "our product will be a complete failure without those dropdown-tooltips". Oftentimes, it isn't.

[jfoster]

Perhaps web standards & browsers should support it. Most of the reasons why it can be bad are due to it breaking things in certain ways, but that hasn't stopped it from being used. So, add some proper support for it?

Some say it's a dark pattern, but I don't think so. Wouldn't it feel silly if Twitter made you paginate through your feed?

[bobthepanda]

It is also pretty easy to make infinite scroll an accessibility disaster.