What would be your use case? Apart from this being a nice feat of technology and the possibility of loading the data asynchronously, in what scenario would it be practical to present 1K+ rows of data to a user? It's infeasible or at least very impractical to examine them by hand - some sorting/filtering possibility is necessary for large datasets and if your filters still return 1K+ rows you could have filtered on something more specific.
Most users don't use on-page find though. Facebook use this "lazy-load, eager-unload" for their news feed. It's a bit annoying, but obviously the alternative is your browser screeching to a halt.
If you are working with unfamiliar data it is very useful to be able to view a huge number of rows in one go. It is the kind of tool that coders all have and use but is unavailable to the general public. Of course excel should be able to quickly scroll through millions of rows if that is what the user wants. Filtering maybe the next step but you need to feel out the data first to know what to filter.
Also, it makes a certain sense to over-engineer this kind of technology to give other elements of the stack some leeway. Lazy loading is great but so is pre-emptively loading data in case latency rises.
Maybe in the case of logging or where the web page is constantly showing new data.
An example I can think is a web based interface for controlling a drone. This could be used on the page to store the timestamped output of various sensors.
It would allow for the data to be displayed while also maintaining a history of the data in the browser. Could add in filters and searches as well as a pause functionality to review the historical data.
Sort of like a dmesg for the web page. I'm thinking practical uses are sensor monitoring and server monitoring.
There was just a post on django.reddit.com asking how to display over 18k rows. Of course the developer knew this was not practical but business demanded it.
This seems nice enough, and is certainly performant, but it strikes me that the majority of the things you'd often want to do with a data table like this (filtering and sorting, selecting rows, to name a few) would all be quite a pain to handle with this implementation.
I've used Facebook's FixedDataTable too, which is also performant and relatively minimal, and it was also moderately painful to achieve even quite simple things.
I have used similar techniques to achieve this in both dimensions, ie x+y.
The basic premise was ala google maps, a view port div, a massive div (map) within the view port for the scrollbar support, the concept of a virtual buffer area around the viewport and then a collection of tiles (tables) that would have data rendered into them and then be appropriately positioned into the buffer area around the viewport as one scrolls. Works well, have tested up to 40mm rows and columns and works in ie8 up to 4mm rows. Also supports random column and row sizes littered throughout the sheet. This solution does also break native in browser search though as mentioned in other comments.
One thing a lot of fixed header plugins dont do well is make sure that the header cells properly line up with body cells. Things usually break down as soon as you start resizing the window, adding your own custom styles, hiding columns... etc.
How well does this plugin handle that? I noticed you didnt use a table, so perhaps you dont really care about styling it like one either.
Here's another implementation of a table that can handle a large amount of rows: http://jarwol.com/aTable. I created it a few years ago as a need for another side project I was doing.
Yep, table views, collection views, stack views, etc under both iOS and OS X have been doing this for ages now. A bonus of this setup is that it forces you to separate your data source from your view, doing sorts and filters and whatnot independent of the table view. It keeps things neat and clean.
I’m not a web guy but most sorting table implementations on the web I’ve seen do the opposite, instead treating the table contents as the data to be manipulated. While this works it’ll cause you trouble in the long run and if nothing else will negatively impact performance. With the cell reuse model, you instead perform your transformations on the original data (free of markup gunk) and ask the table view to update itself to match the data source. Under iOS, this is done through UITableView’s reloadData method. You never directly interact with the table view’s recycling functions.