Lots of good points here! This article (and the implementation) were born out of the frustration with the lacking performance of most infinite scrollers. We were aware of some of the issues you list (I’m not going to claim we thought of
everything ;) ), which is also the reason why we are not providing a library for people to use. Too much left to do right.
> Navigation controls
Definitely something that needs thinking and that we intentionally didn’t address here.
> Ctrl+F
We were think on how to solve this, but we weren’t able to come up with anything using the tools the platform provides currently. Maybe a future API will help here.
> Scrollbars
I thought we did a pretty good job on the scrollbar. You can still click the scrollbar indicator and drag it around to quickly jump from position to the other. It’s not AS accurate, but still useful and doesn’t diminish UX imo.
> Jumping scrollbar
Should barely happen! We are using a sentinel element to define the length of the runway, not the elements themselves to minimize jumping. I think it can only happen if elements grow drastically in height when going from tombstone to actual content.
> “Adaptive DOM pool”
This is definitely an improvement that could be made. Currently we just maintain N elements and N tombstones in memory. N could dynamically adapt to the capabilities of the device.
> Caching
How much caching is utilized is very much up to you. If the API doesn’t provide good caching headers you could implement that yourself in the data source. I think this falls outside of the technical scope of the scroller itself.