Clusterize.js – Tiny plugin to display large data sets easily | Hacker News Reader

Clusterize.js – Tiny plugin to display large data sets easily

nexts.github.io

143 pointscharlieirish50 comments

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

Maybe not in Fx, but on Safari on an iPhone 5C it's completely unusable.

I had the same experience. However, it became laggy on FF40 after clusterize.js kicked in. I'm sure the benefits are better at 500k rows versus.

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.

http://nexts.github.io/Clusterize.js/#playground

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.

That will be enabled in stable soon I believe.

This is very well executed, kudos!

At the same time it puts the browser makers to shame.

If it's so relatively easy to make large tables fast with a small javascript hack then why isn't this optimization baked into browsers already?

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.

I've worked on this problem before (unfortunately in closed source corporate america).

You can just stop the scroll event from propagating in the case that there's more rows to scroll through.

Yeah seems that this problem appears only at OSX 10. I don't have a Mac but I'll fix it once I get one.

I see the same behavior on windows 8.1 by keeping the up/down key pressed down.

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.

Kudos for that!

I agree, the step-exercise explains the plugin functionality perfectly. Really well done.

Feels comparable to SlickGrid's 500k rows example http://mleibman.github.io/SlickGrid/examples/example-optimiz...

This is pretty much the same thing that Ember ListView does. http://emberjs.com/list-view/

The difference is obvious, scrolling is much less laggy. However, it does completely break the smooth scrolling on OS X (Safari).

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.

1: https://github.com/NeXTs/Clusterize.js/blob/master/clusteriz...

2: https://github.com/emberjs/list-view/blob/master/addon/list-...

Thank you :)

It's not laggy at all using Mac OSX Chrome with a trackpad.

It's laggy using a Mac OSX Chrome with a trackpad.

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.

Look pretty cool. A while back I wrote something similar with the difference that it still allows you to use a scrollbar:

https://github.com/jakubroztocil/cloudtunes/blob/master/clou...

For my React peeps looking for something similar, check out http://devblog.orgsync.com/react-list. Repo at https://github.com/orgsync/react-list

This page keeps crashing chrome on nexus 7, even if I get to step 4 when the js plugin is supposed to be initialized.

Much better on iPad and demo works pretty well.

Reminds me of Enyo's list implementation[0], that's how they got it to work rather well on webOS devices.

[0]: http://enyojs.com/sampler/latest/ (Layout -> List -> Basic List)

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.

Doesn't lag at all, in fact if anything it lags more with it on.

Will it work with <ol> with the `start` attribute?

Wow! Good idea! I totally forgot about OL's start attribute. Give me a moment, I'll impelement this too.

Now it is.

I wrote this as well in React once. Easy to add live-sorting and fulltext-filtering. Good job!

did you publish it anywhere?

No, I figured it was too unpolished and you can write it in one day.

Step 8 Works smoothly as well, isn't it? :) ➜

'Doesn't it?'

Excellent work BTW.

Thank you

Absolutely stellar, and dead simple. Will be using this!!

Look very great and seems pretty efficient :o

+1 for interactive demo

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?

Pinterest? Spreadsheets? Business apps?

Not applicable everywhere, but for certain applications (near-) infinite scrolling is extremely popular with the target users.

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.

But it should be an option if you can't be sure that the application won't fail to provide the answer a better way.

And what if the user wants to find something in this almost endless list, by pressing ctrl+F?

Then the linked solution doesn't work, since it removes not visible content from the DOM.

Reply on news.ycombinator.com