News for hackers. Stuff that matters.

A comment on Vue Native. Parent comment

Re:Vue Native by lwansbrough on Wednesday June 13, 2018 @04:45AM (#17301372)
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.

[ Parent | on HN ]
Re:Vue Native by stefanfisk on Wednesday June 13, 2018 @10:50AM (#17303593)
AFAIK all virtual lists break native searching in the browser, so sadly the problem is far from solved
[ Parent | on HN ]
Re:Vue Native by danpalmer on Thursday June 14, 2018 @10:56AM (#17312184)
Well 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.
[ Parent | on HN ]
Re:Vue Native by evv on Wednesday June 13, 2018 @01:27PM (#17305203)
Sounds like browser vendors should start implementing a "find" API which allows long lists to virtualize while still retaining find-ability.
[ Parent | on HN ]