If you use a virtual table and only render the content that is visible at any given time, the number of rows ceases to be a bottleneck for rendering. Filtering/sorting becomes the new bottleneck, but you can generally optimize that via specialized indexes/views and other techniques, depending on the shape of your data and your business requirements.
Source: I built a virtual table implementation a decade ago that scaled just fine to tens of thousands of rows, and browsers were a lot slower back then. But my requirements were also relatively simple, so YMMV.
Comments
I remember browsers starting to not love dynamic tables with just some thousands of rows.
If you use a virtual table and only render the content that is visible at any given time, the number of rows ceases to be a bottleneck for rendering. Filtering/sorting becomes the new bottleneck, but you can generally optimize that via specialized indexes/views and other techniques, depending on the shape of your data and your business requirements.
Source: I built a virtual table implementation a decade ago that scaled just fine to tens of thousands of rows, and browsers were a lot slower back then. But my requirements were also relatively simple, so YMMV.