Many years ago I used to work on the Cappuccino project which was an open source implementation of the Mac Cocoa frameworks in Javascript (technically Objective-J, but that's not important).
In fact I was one of the main people responsible for implementing the TableView component. We modeled the rendering on the iOS version, which was aggressively optimized to be incredibly performant when rendering large data sets.
There are a handful of strategies we used including view reuse (only rows/columns not clipped by the scroll view around it would be rendered. Cells themselves were reused (when possible) when the user scrolled, which saves a lot of time allocating and garbage collecting memory (and in our case DOM nodes).
But beyond that we were very careful about documenting the algorithmic performance of the whole component. Most operations can be done in constant time, some were O(n) but n in our case was the number of items currently being shown, not the whole table which wasn't even in view.
If you're building a UI framework with the expectation that it scale for your users, it's not that hard to write it in such a way that it handles thousands of records. It just requires that the implementor make performance a consideration from the beginning.
In fact I was one of the main people responsible for implementing the TableView component. We modeled the rendering on the iOS version, which was aggressively optimized to be incredibly performant when rendering large data sets.
There are a handful of strategies we used including view reuse (only rows/columns not clipped by the scroll view around it would be rendered. Cells themselves were reused (when possible) when the user scrolled, which saves a lot of time allocating and garbage collecting memory (and in our case DOM nodes).
But beyond that we were very careful about documenting the algorithmic performance of the whole component. Most operations can be done in constant time, some were O(n) but n in our case was the number of items currently being shown, not the whole table which wasn't even in view.
If you're building a UI framework with the expectation that it scale for your users, it's not that hard to write it in such a way that it handles thousands of records. It just requires that the implementor make performance a consideration from the beginning.