Hacker News Reader

Comment by nitwit005 | Hacker News Reader

Unfortunately, in my current app, the actual issuing of DOM updates seems to be what's blocking things. Inserting large tables takes some time.

View on HN

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.

There'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.

Don'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.

That 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.

Are you recommending an app imposed rendering timer (say 15ms) or is there an in built API for Opportunistic scheduling of Dom updates?

You 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

[1]: https://github.com/GoogleChromeLabs/idlize

Reply on news.ycombinator.com