Rendering to the DOM only what the user can see unfortunately breaks the browser's "find" feature. I hope that this technique does not become more popular than it already is. That way the rest of the web, other than Facebook's news feed, can continue to be searchable.
For the Facebook news feed, I think it's reasonable to expect to be able to search for text you have scrolled past. Some infinite lists, like the Twitter news feed, or the Facebook page page (I don't know, the feed of all posts of a "Facebook page") work like this. They just leave all the text in the DOM.
This cannot be solved by the infinite list itself, because by definition it needs to throw out unneeded content (otherwise it would just grow in memory). A search field on top of the list could talk to the server and retrieve the filtered elements.
Does this thing actually throw out not-in-view items entirely, and then ask the server for them again when the user scrolls up? That would be surprising. The memory overhead of the out-of-view items, after they are removed from the DOM, is probably pretty small.
You are right, the pages data that is fetched from the server is kept in memory for future rendering, which usually does not cause memory problems. It is up to the user how to implement search, either by searching in-memory, or change the query and reload the list.
This kind of component in my mind is usually used in web applications, which then will also supply own search for you, which should be more robust than your browser find feature.
Very High performance infinite list for mobile devices that besides GPU acceleration uses concepts like recycling DOM elements and minimize rendering tasks on low frame rate. All for the purpose of smooth scrolling.
I don't know much about html, what do you do in html for GPU acceleration? Is not it enabled by default? Or there are some things that the programmer should be aware of that highly impacts rendering due to GPU?
This refers to a technique where each item is rendered on a different layer in the page. Because of that, when moving an item to a new position it does not require 'painting' the affected area. There are some style attributes that causes the browser to create new layer for the HTML element like 'translate3d'. Tests proves that browser uses GPU for Compositing these layers which is a lot faster when the CPU does this job. explained here more briefly: https://www.chromium.org/developers/design-documents/gpu-acc...
All the demos items are the same height. A big problem I have seen in the past has been with items with varying height. This makes it difficult to swap in new content because you don't know the height ahead of time. It might make for a a more impressive demo if you include random text in those cards. I haven't looked through the source yet since I am on a mobile device, but if you managed to solve that pain point, great work!
Just this morning I released a Mithril infinite list. It supports flexible heights, list/grid, and handles batches of results (basically "pages"):
https://github.com/ArthurClemens/mithril-infinite
for now yes. If you say you need it for desktop I am willing to add this support, it should be easy. to see the scrolling effect now you can simply drag or flick the list even from desktop.