[anonymoushn]

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.

[wereHamster]

I wonder how you plan to support the browsers 'find' feature on an infinite list.

[anonymoushn]

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.

[cultureulterior]

This is also a problem on mobile wikipedia. I wonder if a feature for this shouldn't be added to browsers

[zachrose]

Finally, a use for the HTTP SEARCH method?

[ArthurClemens]

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.

[anonymoushn]

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.

[roeierez]

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.

[M4v3R]

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.

[anonymoushn]

That would be cool! Right now the Facebook news feed does not provide a search feature.