For almost all the uses you've listed, I can readily think of examples where I've seen it done badly. Thinking of good examples is considerably harder. Can you provide some?
In my experience, deferred loading merely guarantees that there's visible latency multiple times when interacting with a page even after it has "finished" loading. And since lazy image loading can now be accomplished without JavaScript, I'm not sure what still needs to be lazily loaded via scripts watching scroll behavior.
Removing elements after you scroll past them sounds like the kind of optimization only necessary on infinite scroll pages, unless the page in question has a multitude of auto-playing videos.
Restoring scroll position between interactions: I'm not sure what kind of interactions make this necessary, so an example would help.
Scroll-snap: The examples on MDN don't even behave properly.
Offsetting jump in-page anchor/jump links: Stop obscuring 20+ % of the vertical space with "position:fixed" dickbars. Then you have a much smaller problem which I'm not sure requires JS scrollhacking to solve.
I'm not sure scroll hijacking is completely bad, but it's overwhelmingly more bad than good. Breaking fundamental interaction mechanisms should only be done where it's absolutely necessary, or in a context where all the normal expectations for interaction can be abandoned. These capabilities go beyond merely "ripe for abuse" and are perhaps better described as UX footguns that are mysteriously attractive to web designers.
> Thinking of good examples is considerably harder.
It would be, if they’re done well they’re indistinguishable from not being there at all. It’s unfortunately biased against good implementations. As far as examples, the best by far are HTML-only (img with loading=lazy, which behaves as expected almost universally). After that, I’m on mobile right now so limited in my reference capacity, but they tend to use IntersectionObserver and usually with simple abstractions around that.
> In my experience, deferred loading merely guarantees that there's visible latency multiple times when interacting with a page even after it has "finished" loading
Yep that was my side eye.
> And since lazy image loading can now be accomplished without JavaScript, I'm not sure what still needs to be lazily loaded via scripts watching scroll behavior.
Lazy image loading in HTML was controversial too, because it can be used for said shady tracking. But other deferred loading/execution is extremely helpful (for users!) for below the fold interactive content which doesn’t ever need to load if the user doesn’t scroll and doesn’t need to run until it’s nearby, even if the user wants to interact with it. Large JS payloads are a huge part of why sites feel unresponsive when they load. Even if they’re ultimately what the user wanted, it’s valuable to deprioritize the code they don’t need yet.
> Restoring scroll position between interactions: I'm not sure what kind of interactions make this necessary, so an example would help.
The most common is client-side routing (even turbolinks which are popular as an alternative to SPAs), but also any interactive content without stable heights.
> Scroll-snap: The examples on MDN don't even behave properly
I haven’t found that to be the case, what improper behavior did you see? (I’m asking because I’ll file an issue if it’s actually wrong and if you don’t feel inclined to file it yourself)
> Offsetting jump in-page anchor/jump links: Stop obscuring 20+ % of the vertical space with "position:fixed" dickbars. Then you have a much smaller problem which I'm not sure requires JS scrollhacking to solve.
That’s all fine and good, but there are cases where the offset is useful and small and users benefit from both.
> These capabilities go beyond merely "ripe for abuse" and are perhaps better described as UX footguns that are mysteriously attractive to web designers
The fact that the most benign uses of them is so opaque is a testament to how well the newer APIs are designed, they’re so close to invisible that you’d need to be paying close attention to their usage and limitations to even know how they benefit users and how widely they’re used. I didn’t know about most of them and how they’re used either until I was on a MDN hyperfocus just learning what had been introduced while I was fully backend. Since then I’ve seen incredible UX improvements specifically leveraging IntersectionObserver to make sites a lot more usable, often at the library/framework level where most devs have a happy path to just do the right thing. I know that sounds antithetical to the common anti-JS rhetoric, but it’s been so effective it’s almost invisible.
Unfortunately the worst cases are still terrible so I can’t blame you for your reaction at all.
> I haven’t found that to be the case, what improper behavior did you see? (I’m asking because I’ll file an issue if it’s actually wrong and if you don’t feel inclined to file it yourself)
When scrolling through a long document with a touchpad, it's natural to make several swipes in rapid succession, with the second swipe starting before the momentum scrolling or snap animation triggered at the end of the first swipe has finished. On my Mac, in Chrome it appears that starting the second swipe interrupts the snap animation (good) and doesn't start a new one when the second swipe ends (bad), even for a mandatory snap container—leaving the container in what should be an impossible steady-state.
In Safari, things seem to work as expected, except for the more general usability problem that making multiple swipes like this can cause the scrolling to be amplified far beyond what the user would expect for a non-snapping container.
In Firefox, things mostly work, but I'm occasionally seeing instances where the container below the one I'm scrolling also scrolls a bit. Not easily reproduceable, but since I was playing with the horizontal scroll container examples it seems unlikely that I accidentally made the right combination of one and two finger gestures to get the cursor to stray down to the lower container, scroll it a bit, move the cursor back up, and continue scrolling that one. Ordinarily, no amount of frantic two-finger swiping results in that much one-finger cursor movement, and it appeared the spurious scrolling of the second container was more correlated with rubber-band animation when scrolling past the end.
And that's from about two minutes of playing with literally the first example I could find.
Good detail, albeit somewhat revealing of a chaotic testing approach ;)
I’ve also experienced some weird edge cases behaviors with scroll-snap in desktop browsing environments, though seldom as pronounced as what you describe for Firefox (admittedly I don’t test in FF as much as I ought to, but I also don’t do much work that could even be browser-specific at this point).
It sounds like there are a couple potential bugs maybe worth filing here, given precise repro steps. Would you like the honor or shall I? I won’t be back at my desk til mid day tomorrow probably but I’m happy to see what I can repro and file what I can.
In my experience, deferred loading merely guarantees that there's visible latency multiple times when interacting with a page even after it has "finished" loading. And since lazy image loading can now be accomplished without JavaScript, I'm not sure what still needs to be lazily loaded via scripts watching scroll behavior.
Removing elements after you scroll past them sounds like the kind of optimization only necessary on infinite scroll pages, unless the page in question has a multitude of auto-playing videos.
Restoring scroll position between interactions: I'm not sure what kind of interactions make this necessary, so an example would help.
Scroll-snap: The examples on MDN don't even behave properly.
Offsetting jump in-page anchor/jump links: Stop obscuring 20+ % of the vertical space with "position:fixed" dickbars. Then you have a much smaller problem which I'm not sure requires JS scrollhacking to solve.
I'm not sure scroll hijacking is completely bad, but it's overwhelmingly more bad than good. Breaking fundamental interaction mechanisms should only be done where it's absolutely necessary, or in a context where all the normal expectations for interaction can be abandoned. These capabilities go beyond merely "ripe for abuse" and are perhaps better described as UX footguns that are mysteriously attractive to web designers.