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.
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
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.
1. This is what the DOM is, to some extent. All those components on the page are “native” components, we have declarative markup for them (HTML) and we can script them. They are “rendered” by native code in browsers which are some of the most highly optimised codebases around.
2. The API design for JS and for higher performance systems is quite different. Take UITableViewDataSource for example, it does view prefetching, caching, object reuse, etc. As of iOS 12, this also feeds into the CPU throttling control to ensure enough compute is available on a cell fetch that it will meet the 8-16ms deadline so that no frames are dropped. This is just a totally different way of thinking about APIs and performance that the JS ecosystem is not designed to work with.
It’s possible that a total rewrite of that stack could provide significant benefits, but I think that would be more from removing legacy cruft in the DOM, than from it being a paradigm shift.