Hacker News Reader

Comment by leeoniya | Hacker News Reader

this works well when you have a few sparklines with a dozen datapoints each, but less well when you have many sparklines with hundreds of datapoints.

View on HN

I'd bet an SVG <path> can easily handle hundreds, if not thousands, of datapoints.

Then you have to deal with scaling, responsiveness, data decimation, etc. It's not really a good idea to just have a multi thousand point line chat rendered real tiny

If you know what size you're dealing with it's not a huge deal. You can quantize the data and for (small) sparklines that's probably fine because most people view them as miniature glimpses at data rather than granular and accurate.

+1, the whole point of a sparkline is to compactly show a trend. Packing a gazillion data points is not the right use

Totally. I just mean that logic has to live somewhere, whether in client-side JS or a server. It's not a great practice to just blindly render SVGs out of raw data.

Aha, I misunderstood — I'd thought you were thinking of rendering multiple small SVGs.

Good point, although decimation for sparklines shouldn't be that difficult: I've done completely stupid decimation (recursively split stopping whenever linear fit is close enough) for live GPS traces and (because people are only using them qualitatively) no one ever complained.

it can for sure "handle" it. the question is "how well"?

a sparkline with 100 datapoints is very realistic. and having a couple columns in a table with 100 rows filled with these svg sparklines will have ui lag that you'll definitely feel.

sadly, svg is not a great performer in these 1k+ datapoints cases and you gotta switch to canvas.

You're populating a tiny template with a tiny list of numbers to produce a tiny plaintext document that will cache like Scrooge McDuck.

Why do you think this is going to be a problem?

Reply on news.ycombinator.com