I really dislike these simple charting libraries, because I always have some kind of issue that just wastes my time in the end. For example with plottable, there is a hover event function that is extremely expensive that will trigger for every pixel movement with your mouse. With just a few hundred datapoints every chart we rendered ran horribly slow.
With D3.js you have instead full flexibility and the only performance issue is that SVG's are slower than canvas, and that is mostly a problem when you have tens of thousand data points.
> d3 is robust because it's great code that's widely used - not because of it's other design choices.
I disagree very much. On top of the facts you mentioned, the main reason why d3 works where others don't is because it doesn't abstract away as much from the end user. Leaky abstractions will always, always come back and bite you in the you-know-where.
D3 is itself a leaky abstraction, since all frameworks, libraries and languages are ultimately leaky abstractions of some lower level. What matters is choosing the right level of abstraction based on what you're trying to do, and the resources available to do it. In some cases, D3 will be at the right level, and in other cases, something like Plottable will be right.
Whatever. This is a corporate vanity project (easy to spot because the logo is better than the code) with 5-, 6-, and 11-month old PRs hanging around.
Clearly this library is setting the world on fire. Meanwhile if you want slow pointy clicky chartjunk for your PHB you can probably use your company's Tableau license, and if you want to push the envelope you use d3.
I've been using d3 on and off since 2011. It started from a spare, elegant idea and progressed to the point that almost anything I might wish to implement has at least some pieces already written in some obscure blocks.org block.
I find that pretty damned impressive given that many of my interests were research projects abandoned in the 90s and only just now beginning to come back. (yes, there were smart people back then, too; they all seemed to have SGIs)
> all frameworks, libraries and languages are ultimately leaky abstractions
[citation needed]
I seriously doubt the veracity of that claim, and if that's the only justification you can come up with as to why anything is a leaky abstraction, then I refuse to believe you.
Heh, someone was fussing about the price of a hard copy today on Twitter.
No dispute that Wilkinson's ideas deeply influenced all sane graphics frameworks thereafter. In fact SPSS' purchase of SYSTAT was (by far) the best thing they ever did, and that's why people still use that awful piece of garbage.
However, Hadley Wickham spent a lot of time thinking through which parts still made sense, and which didn't, in implementing ggplot2. That book is free online, as are Bostock's notes.
I heartily recommend all three, but if money is an issue you can get the latter two for a lot less than a copy of TGoG.
Funfact: Wilkinson started this by selling SYSTAT to SPSS, got bored, eventually went to Tableau (seems to have worked out nicely for them) and now is at h2o. As much as I despise SPSS from having taught classes that use it, I admire their business sense and wish I'd owned equity in them prior to IBM buying the company.
H2O might not be a bad investment either (I've been wrong plenty of times though).
Thanks for the recommendations! Did you mean something specific when you referred to "Bostock's notes", or did you just mean his various blog posts and papers?
Turns out Bostock explicitly avoided devising Yet Another Grammar of Graphics in favor of selection and transformation operators. Which, as it happens, is a very sparse but expressive grammar anyways (cf dplyr and other corners of the Hadleyverse). Nonetheless, I misrepresented his idea of maximizing expressivity by minimizing grammatical constraints.
The IEEE paper is even better than I remembered. It's just as good today as it was when he first submitted it.
Mostly those, but there are some old conference papers and IEEE transactions (if memory serves) that are more explicit. I'll look them up when I have a block of time free.
Seriously... I was just reading the examples and thinking to myself "why would I use this over vanilla D3"? The syntax isn't more concise and offers less control, and introduces a whole new api to learn. To me this is like writing a DOM manipulation framework on top of jQuery...
It has been around for a long while, has superb connectors to many different languages (we mostly interact with it from Python), and has been recently open-sourced. Free, but they also provide hosting for your charts for a very modest fee. Highly recommended.
Unless this has changed, you need the $9,950/year plan to serve it "behind your own firewall". I.e. otherwise plots on done on their systems by uploading data.
That used to be the case until the end of last year, but it has been open-sourced and you can render a plot entirely on the client side, without a roundtrip to Plot.ly's servers (no rate limits anymore, custom integrations to your existing stuff, etc.), for free.
We looked into it after they open sourced it; AFAIK, it is still designed to connect to their streaming servers with an API key (or run locally in an ipython notebook or similar "offline"). If you want to make your own private dashboards for your own system you still need https://plot.ly/product/enterprise/#plotly-on-premise
I have some very good experiences with dc-js [1]. It's a charting library for the purpose of interactive charts on managable datasets (tenthousands of records).
I use http://recharts.org, and i'm very happy using it since. Integrates well with react, other nice library that works well with react is https://formidable.com/open-source/victory, but less opinated and lower level. For alternative outside the react world, you have many wrapper around d3.js, that are higher level enough like nvd3.js, that let you throw quickly on the screen a chart.
Agreed that it's a framework, but it's not necessarily that much work, it really depends on what you're trying to do. Sometimes its easier just to use a library if it offers what you needs, other times its easier to use D3 directly -- knowing when to make that call is important.
There a good O'Reilly book on D3 by Scott Murray, the ebook version of which is free that's a great primer:
In my use-cases, it doesn't take much work at all. That said, it took me a fair amount of time learning enough about it (D3) for that to be true.
I think we'd probably both agree what if someone just wanted to build one (simple) interactive chart and then be done, D3 is probably not a good first choice.
It has been over a decade since I did any legitimate work in JavaScript. If I wanted to use this to make some pretty data displays, do I really need to install an ecosystem (npm, node, grunt, bower, more?) instead of just pointing a script tag to something.js?
Providing they give you a download to the compiled script, there's no reason you can't just point a script tag at the source file. You would only need node and the rest to modify the source code I assume as they would have setup build tasks with grunt etc.
I wouldn't. While it still works (and I use it in a project of mine), the last commit is two years old and there are more and more open issues. It's a dead project.
On the other hand, using the flavour-of-the month JS shiny thing until the CADTs jump ship is also burdensome. There is a lot to be said for stable libraries, let-alone stable ecosystems.
Totally agree. But there is a difference between stable and dead. Bugfixes matter. Taking care of issues would mean that things like "FF 51 breaks the tooltips" (fictional example) gets discovered and fixed. And one or two improvements a years also don't hurt.
IMHO that's a good thing. It's not changing, works very well, has lots of plugins and is a relatively small library so you can fix it yourself. Plus a large user base, so many problems you run into are already known.
x.connectorsEnabled() on line 24 is a getter, returning the boolean.
x.connectorsEnabled(boolean) on line 31 is a setter, return `this` for the benefit of method chaining.
That then leaves the actual definition which goes through to the JavaScript: it has an optional argument to satisfy both plausible signatures and starts on line 32.
In short, the first two are basically hints for TypeScript (if the signature is such-and-such, its return type is actually more restricted than `any`), while the third has the actual implementation.
For something similar consider how the type of callback in `addEventListener(type, callback)` depends on `type`: it’s always going to be a function taking an Event, but for e.g. type 'mousedown' it’s actually more than that, it’s a MouseEvent. So the TypeScript definitions in dom.d.ts or whatever it is (I haven’t had opportunity to actively use TypeScript for a while) has a whole lot of definitions: `addEventListener('mousedown', (event: MouseEvent) => void)`, `addEventListener('focus', (event: FocusEvent) => void)`, &c. (And because it’s just definitions, not the implementation, there is no actual implementation of `addEventListener(string, (event: Event) => void)`. This connectorsEnabled case does have the actual implementation.) In type system terms, think of it as a very restricted form of dependent typing.
It feels complicated due to not using separate getter and setter functions. By splitting it into two functions the annotations could be reduced as well. I wonder what the reason for not taking that approach was.
It’s common in JavaScript to have method overloading for getters and setters like this. jQuery is probably the best-known example; .css('property') is a getter and .css('property', value) a setter.
My guess is that if you call it with a boolean argument, it returns `this` for chaining purposes. Otherwise it returns the current value of `_connectorsEnabled`. There are two declarations for the different usages, and then the actual implementation can return `any`. It is a bit strange.
public connectorsEnabled(enabled: boolean): this;
public connectorsEnabled(): boolean;
public connectorsEnabled(enabled?: boolean): any {
if (enabled == null) {
return this._connectorsEnabled;
}
this._connectorsEnabled = enabled;
return this;
}
In that way, typescript will use the most specific overload to do type checking, so you'll get an actual boolean when doing connectorsEnabled(); instead of any.
Comparing their Finance demo [1] to the HighStocks equivalent [2]. It comes in at nearly twice the lines of code for significantly less functionality. Obviously there's a difference in approach here - HighStocks comes with lots of sensible default options where as Plottable.js seems to require more explicit configuration. And Highcharts is a commercial product whereas Plottable is free.
For me though Highcharts/Highstocks is still easily worth its license fees. In my experience >90% of charts I require are very simple to implement in Highcharts and the sensible defaults make your life easy. For the other <10% use D3/a custom solution.
Does this library handle multiple scales per series on a single chart? This is a pretty key requirement for me and a lot of the javascript libraries I've found don't handle this user case very cleanly.
Ideally I want to plot common time series data with independent scales for each yaxis variable. This is for plotting thermocouple traces.
I can say why I would use it, I don't know that I can answer why you might. I would this because I love D3. I also don't have time to write a lot of it. D3 can be expensive for basic charts to the point where you'd be foolish to use it. D3 is great for complex data visualizations where the expense is an investment that will pay you back in higher performance and higher flexibility.
For me, I can use plottable and then make the charts my own with raw D3.
Any recommendations for the easiest to drop-in pretty looking charting library that supports dynamic streamed data from a WebSocket.
For instance, let's say I want to show an dynamic CPU usage graph of one of my servers over time. I don't want a ton of dependencies, it should be lightweight, easy to integrate, and quick!
I'm not an HTML guru, so I don't want 100's of files that I have to build with bower/grunt jobs. Just a link to a script and a bit of JavaScript. That I can manage,
Suggestions really appreciated. If this is it, that's fine too.
What is the maximum number of datapoints that plotting library should be excepted to handle at the same time?
I think 10,000 datapoints is the limit in 2d visualization but even 1000-2000 datapoints is often acceptable limit. It's usually reasonable to reasonable to downsample and decimate data before presenting it. If user zooms into data, it should be handled in some other ways than keeping all data.
Displaying up to 1000 datapoints at once seems like a reasonable limit.
But if the library supports zooming, I highly appreciate it if I can just put my 10,000 to 100,000 datapoints into the library, specify a simple filter function (avg, sum, min, max) and let the library pick the points it wants to display at each zoom level.
Beyond ~100,000 datapoints any filtering is likely better done in the database than on the client. For values below that, Javascript is more than capable.
If you are plotting using a canvas - not building a SVG or on the dom - then even 50000 points is fine, no need to filter even on mobile devices.
A 100,000 data point file would be about 500kb transfered to the client. This is still a tiny amount of data to play around with in JS. It is possible to build an array of image tiles, and zoom around like google maps. But keeping the image tiles in memory could be worse than just replotting if the plot function is fast and optimized enough.
I’d like to see more tools and tutorials for generating charts on the server-side, so that the amount of JavaScript is kept at a minimum. You just can’t afford to run hundreds of KB of JavaScript in the browser anymore… unless it runs in a worker, I guess, but I haven’t seen tutorials on that either.
When it comes to plotting stuff with JS HighCharts is the ugly thing that gets the job done. I think at this point I tried at least 10 different libs and always ended up wasting lot of time because some basic feature was missing (eg. tooltips, zoom, some sort of chart, log scale, decent theme support, ...)
With D3.js you have instead full flexibility and the only performance issue is that SVG's are slower than canvas, and that is mostly a problem when you have tens of thousand data points.