5000 rows isn't laggy in Firefox on a current genetration MBP, so I've nothing to compare to. It would be good to have an additional step with 500,000 rows without clusterize (or increase the number of rows in the first step).
Firefox added a new scrolling feature in Aurora. layers.async-pan-zoom.enabled;true
With this enabled scrolling is calculated in its own thread which makes Firefox insanely smooth now, so I doubt I'd notice a difference even if it were 50000. I recommend everyone gives it a try, it's a big deal.
By default I set 10000 rows as it was good amount for compare at PC's, but mobile users complained to crashing pages so I was forced to decrease to 5000 rows.
You may test it at playground. By default there are 1000 rows, you could even increase it by hitting "Append" button, then click destroy method "Insert all rows to the table" button. After that you will be able to init plugin again. It'll allow you to compare the difference.
This is a great tool and the effort was worth while. I don't want to sound like I'm badgering it. But how useful is scrolling down 5,000+ rows of data? Are you going to scroll through all 5,000 data points in 10 seconds and find what you are looking for along the way? I think a 10 row table with a search bar is far more useful
Doesn't it depend on the dataset? This may not be as useful if the result is sorted by "importance" (aka Google search query). But if the data is ordered categorically, an enormous list is a great way to scan through a lot of items quickly (think iTunes song library).
There's a small bug if scrolling with a trackpad very quickly. Instead of continuing to scroll the inner div (or whatever container element you're using), it will stop scrolling partway through, and scroll the entire page instead. Usually this only happens when you've reached the end of the scrollable div, but not with this plugin.
I'm using Chrome 42.0.2311.135 (64-bit) on a MacBook Pro with OS X 10.9.5.
So this is like a Carousel for sets of <tr>'s in a table? Seems like a neat idea but on Chrome 42 (64-bit) OSX 10 scrolling fast with the trackpad causes the entire page to scroll. I assume it's because scrolling has reached the last <tr> in the table and the next set of <tr>'s has not yet been appended to the table.
One of the best and most concise plugin pages I've seen. It's very considerate having a "how does it work" as one of the first things explained on the page.
Really nice library. It is refreshing to see such neatly coded JavaScript with so few dependencies! (just the browser API :-).
Compare Clusterize.js [1], whose complete implementation fits in less than 250 LOC, to Ember List View [2], mentioned by someone here: ~800 LOC Just for a Mixin (whatever the hell that is).
Now, try to estimate how long would it take you to understand and fix a bug or add a feature to Clusterize, and how long would it take to do the same thing with list-view.
One downside is that it breaks searching using the browsers in-site search function, which I probably would try to use in many situations where this might be used.
I remember seeing a javascript app on HN a long time ago that someone made to list all possible tweets (i.e. generated all combinations of 140 characters). It utilized a similar technique to simulate scrolling through the entire dataset. Very cool.
All nice and good, but this sidesteps the real problem - having a list with say more than one hundred items to begin with. Which sane developer would force his user to deal with lists with thousands of items? And which sane user would look at more than twenty or fifty of them? When was the last time that you clicked all the way to page five of your Google search result? Page 10? 100?
I don't know Pinterest but it looks like it is made for random browsing through content like scrolling through social network content. There it makes indeed sense because by the very nature of the activity you are not trying to solve a specific task. But event there I doubt that people go through thousands and thousands of items.
Spreadsheets? At least I hate scrolling through them. I would rather prefer seeing the thing I am interested in at the very top instead of manually searching for it. That is of course a tough problem, designing a good spreadsheet as well as offering good tools to do this or ease navigating. The same for business application. No one likes scrolling through endless lists to find the relevant things but business applications almost universally suck at it is often your only option.
> I would rather prefer seeing the thing I am interested in at the very top
You've hit on the exact point. If you've ever watched a heavy pinterest user browse pinterest or other pinterest-styled shopping sites -- they look at EVERYTHING. Just infinitely scrolling for hours after hours, skimming every single item until they hit the end of a collection. Occasionally opening items in a new background tab.
Probably that's where this UI works best, for apps where the person is going to look at many thousands of items, and no ranking exists that can do a decent job, for the particular user's needs other than at a rough level. Women's fashion shopping (e.g. pinterest and shopping clones of pinterest) seem to be an ideal example of that.
By the way, fashion is an interesting example of being anti-ranking. If something gets too popular, it suddenly becomes unfasionable again by the rules of fashion.
You certainly should offer filters or other ways of getting where the user wants to go. But scrolling is better than most alternatives to get through the raw data.
Besides in cases where the user does not want to solve a specific task, e.g. randomly browsing news sites, social network content or image boards, going through endless lists is never what the user wants. He is looking for some specific information and that he has to go through long lists only means that the application failed to provide means to directly answer the users's question.
