I understand your perspective but for you and anyone else reading, here’s a more familiar analysis.
Maps apps don’t make much use of scroll APIs at all, they tend to use pointer events (and/or their older mouse equivalents). When they do it’s almost always auto-panning to some item in a more traditional results list, and always a horrible experience. Apart from infinite scroll, the most common uses of scroll-related APIs are:
- deferring load/execution of resources until they’re pertinent; this is almost always a better UX, unless it’s done very poorly (side eye at many news sites)
- removing offscreen elements from long lists to minimize their performance impact; again almost always a UX benefit unless done poorly, though easier to screw up
- restoring scroll position between interactions; generally neutral, about the same level of quality as built in behavior, but better than not doing it when there’s client-side navigation (and I know this is another JS curmudgeon complaint, but it’s almost everywhere and mostly unnoticed)
- scroll-snap, which has eliminated the need for JS for whole classes of presentation (and probably the first unambiguously good thing MS purposefully introduced to web standards)
- offsetting jump in-page anchor/jump links to place content in view where they’d otherwise be obstructed; significantly benefits UX, unfortunately not (yet?) as widely adopted as I’d prefer
- “scrollytelling”, which can be really annoying but also can be incredibly useful if done well; notably a CSS standard is finally getting real world traction and will make the usage much more user controllable and much less awful for users who don’t control it
- shady tracking stuff which is mostly invisible to the user; entirely awful but categorically a whole separate UX topic
- weird event handlers to control things like video volume; I hate these with a burning passion
Overall, IMO, the value is kind of a wash. But the positives generally amplify positives for a lot of other UX problems and newer standards have made them basically mostly harmless.
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.
I mean... a lot of your examples boil down to "With enough JS, we can smooth over the problems created by all the JS we added!"
This approach is why Reddit is extremely janky on mobile, while HN is perfectly smooth. Opening a new page on Reddit takes up to 10 seconds; moving back to the previous page up to 5 seconds. Meanwhile, both are almost instant on HN.
Maps apps don’t make much use of scroll APIs at all, they tend to use pointer events (and/or their older mouse equivalents). When they do it’s almost always auto-panning to some item in a more traditional results list, and always a horrible experience. Apart from infinite scroll, the most common uses of scroll-related APIs are:
- deferring load/execution of resources until they’re pertinent; this is almost always a better UX, unless it’s done very poorly (side eye at many news sites)
- removing offscreen elements from long lists to minimize their performance impact; again almost always a UX benefit unless done poorly, though easier to screw up
- restoring scroll position between interactions; generally neutral, about the same level of quality as built in behavior, but better than not doing it when there’s client-side navigation (and I know this is another JS curmudgeon complaint, but it’s almost everywhere and mostly unnoticed)
- scroll-snap, which has eliminated the need for JS for whole classes of presentation (and probably the first unambiguously good thing MS purposefully introduced to web standards)
- offsetting jump in-page anchor/jump links to place content in view where they’d otherwise be obstructed; significantly benefits UX, unfortunately not (yet?) as widely adopted as I’d prefer
- “scrollytelling”, which can be really annoying but also can be incredibly useful if done well; notably a CSS standard is finally getting real world traction and will make the usage much more user controllable and much less awful for users who don’t control it
- shady tracking stuff which is mostly invisible to the user; entirely awful but categorically a whole separate UX topic
- weird event handlers to control things like video volume; I hate these with a burning passion
Overall, IMO, the value is kind of a wash. But the positives generally amplify positives for a lot of other UX problems and newer standards have made them basically mostly harmless.