3 ms·
That's where stuff like batch inserting the elements (split your table up into groups of 100 elements, and add one every so often to keep the UI smooth), and vi
by Klathmon 8y ago
That's where stuff like batch inserting the elements (split your table up into groups of 100 elements, and add one every so often to keep the UI smooth), and virtual-rendering (only show the part of the list that is actually visible) are going to be the only real solution.
Oh, and making your DOM simpler if possible, but normally there's not a ton of gains to be had there in my experience.
- nitwit005 8y agoThere's a lot of tricks you can try, but even rendering the first set of visible rows can take more than a 60fps time window will allow.
- Shog9 8y agoDon't pick a fixed value for the batch size; render until your time is exhausted and then wait for the next batch. Yes, this'll be slower overall, but you ensure that the app stays responsive regardless of device or CPU availability.
- writepub 8y agoAre you recommending an app imposed rendering timer (say 15ms) or is there an in built API for Opportunistic scheduling of Dom updates?
- ergl 8y agoYou might want to check out this thread from last week[0] about scheduling tasks when the event loop is idle. The author also published a library for it[1] [0]: https://news.ycombinator.com/item?id=18030848 https://news.ycombinator.com/item?id=18030848 [1]: https://github.com/GoogleChromeLabs/idlize https://github.com/GoogleChromeLabs/idlize
- nitwit005 8y agoThat seems like it would cause a lot of shifting content as the table gets repeatedly resized due to adding rows. The only way I see that working out nicely is if you can know the height of the table in advance, which is generally not the case.