Use of Intersection Observer API

[johanneslamers]

The Intersection Observer API provides a way to asynchronously observe changes in the intersection of a target element with an ancestor element or with a top-level document's viewport.

Would be nice if scrollMonitor can use this native browser API for monitoring. And with a fallback for older browsers.

[stutrek]

It's unlikely that this library will ever use the intersection observer. When I last tried intersection observer, it was considerably slower than scrollmonitor. This makes sense because this library makes some tradeoffs for speed with regards to animations and DOM mutations.

When I made scrollmonitor, tracking the scroll position of an element was an elaborate mess that almost always caused severe performance issues. The intersection observer API is simple enough that, if your main concern is not speed, is probably worth using instead of this.

[neilvanlandingham]

While I greatly appreciate and respect your work on this fantastic library, I question your claim that Scrollmonitor is considerably faster than IntersectionObserver. It seems the "tradeoffs" your library makes "with regards to animations and DOM mutations" could also be made with a library based on IntersectionObserver, since IntersectionObserver doesn't do any mutation or animation of DOM elements itself as that would be the job of the callbacks you pass to it. Given the strong interest in this Github issue, would you mind posting the performance test you wrote in order to justify this claim?

[stutrek]

I would be happy to accept a PR that adds an example HTML file that load tests Intersection Observer, it could be a simple copy and paste of the existing load test example. It would be very nice to see since the speed of Intersection Observer is a gradually improving target.

I am very curious to learn how a library based on intersection observer could make the same animation and DOM mutation tradeoffs that I made by caching element locations.