3 ms·
Your UITableViewDataSource is a common problem with big JS applications, and has been solved to some extent with the same optimizations you've mentioned. Howeve
by lwansbrough 8y ago
Your UITableViewDataSource is a common problem with big JS applications, and has been solved to some extent with the same optimizations you've mentioned. However because JS and HTML is what it is, it has to be solved on a per-library basis (React Virtualized List, Vue Virtualized List, etc.) The problem remains that the JS renderer does not have access to those low level draw calls to optimize performance further.
As for the DOM, again I think that while it's true that native HTML elements are highly optimized, many applications have much larger performance goals in mind and HTML/DOM has proven to be an ineffective system when trying to do very specific performance optimizations. Check out flipboard.com on your phone for an example of how much smoother a web app can feel when you bypass the DOM and let React take over the draw calls.
- stefanfisk 8y agoAFAIK all virtual lists break native searching in the browser, so sadly the problem is far from solved
- evv 8y agoSounds like browser vendors should start implementing a "find" API which allows long lists to virtualize while still retaining find-ability.
- danpalmer 8y agoWell browsers are probably doing virtual lists themselves, it's just that the JS/DOM API doesn't provide a way to expose that to the application developer, which means the impact will be limited.