I swear many people would be better off just manually generating paths on their own. It's not difficult.
D3 is pretty awesome and all but it is NOT a charting library. It's a data binding framework. It adds several layers of incredibly hard to follow abstraction.
It's super duper cool when it does exactly what you want and all you desire is to drop your in your data. A+++ would recommend. But if you want to do something slightly different it's a huge pain in the ass. At the end of the day it's just a handful of SVG primitives. Draw them yourself and move on with your day. I promise you it's easier.
Wha? Yes, D3 is definitely not a charting library - because it's a data-focused, thin wrapper over the DOM & SVG APIs. It's designed from the group up to "let you do something slightly different": that's the point. It's the low-level primitives you'd otherwise reinvent.
Your experience is totally different from everyone on every team I've used D3 with, and all the people I've taught D3. I can understand "D3 does too little", but "D3 does too much" is just weird.
What I've needed from D3 is the math-y bits: calculating layouts, paths, etc. What I don't need (or want) is for it to ever touch the DOM.
But that's what it wants to do most. D3 is sort of the best of the jQuery-inspired "select and mutate" generation - it does data binding in a way that really makes sense as long as you let it handle DOM operations.
But following React, there's been a pretty big movement away from procedural DOM manipulation and toward the declarative re-rendery "DOM as a pure function of state" approach. In that case, letting D3 mess with the DOM (especially in the way that it does, where complex links between DOM and data are maintained in the background) is bad news.
If you already have a way of getting elements in and out of the DOM and keeping their state aligned with the data that you like better than the select-and-mutate model, a lot of what D3 does seems unnecessary or introduces problematic interference. React and D3, for instance, tend to not play very nice without a lot of effort.
I've had projects where programmers lean on D3 because that's the way they've learned to get SVG elements into the DOM - they'll take an example they've found somewhere that mostly only uses simple shapes, modify it a little bit to do what they want and ask me for help adding that visualization into another project. Sometimes in these cases, D3 isn't getting used for much except for "insert an svg element with these attributes for every node in this data structure", in which case it's total overkill, and I end up stripping it out entirely. I sometimes end up keeping it around for things (I'm probably not going to write my own Reingold-Tilford tree layout algorithm), but often in these cases I have to do extra work to keep it from conflicting with other things.
I had come to the same conclusion as I'm very sympathetic to the React mindset, and thought that combining the d3 "math-y bits" with React as a rendering engine might be the very best of both worlds.
But the one thing that I couldn't find a good solution to, was transitions/animations as data changes. Support for transitions in d3 is quite impressive (often just calling .transition() on your selection) and I couldn't find nearly as nice a solution with React, though chenglou[0] seems to be making continuous progress.
The D3Component wrapper lets you put a d3-style reusable component inside of a react dom tree, using react props to pass parameters and event handlers to the d3 chart.
That's a very fair judgement, but it's also something the d3 team knows about. D3 4.0 is breaking d3 into a bunch of reusable components. The exact use case you mentioned, getting the path/layout data so React or anoth DOM manipulation library can be used, is supported by d3-shape, which just can out recently. Tree diagrams are still in progress, but various curves and pie charts are already implemented.
This is exactly the use case I ran into most often, and I have designed a small library precisely to do these computations without touching the DOM. If you want to have a look, it is on https://www.github.com/andreaferretti/paths-js
Just to say, D3 is entirely the 're-rendery "DOM as a pure function of state"' approach. `el.__data__` is just optimisation (if you're only using d3). You should be able to `setInterval(yourD3Code, 16)` if you're writing idiomatic d3.
I wondered if I was the only one who thought that way — apparently not. I also found D3 to be very inflexible, with abstractions doing strange things behind your back. In general, a lot of "magic" was happening behind the scenes.
I mostly write in ClojureScript, so the data binding wasn't that attractive — I can do all of that work better anyway.
I guess what I'm looking for is a library with graphics/charting primitives written in ClojureScript, possibly using React. Hmm.
The next version of D3 will be modular, with the different parts broken out into separate packages (i.e. shape utils separate from databinding utils). Currently I'm using D3 piecemeal with React with a good deal of success.
Disagree. Like any framework or medium-to-big library, D3 does take some time to learn, but totally pays off once you learn it. If you're just doing a single viz, then sure, rolling your own is ok. But if you're doing lots, and especially if they need to be interactive, I'd strongly advise against reinventing the wheel.
I also have not found it too hard to step outside of/modify the online examples, though I guess it depends on the particular viz you're trying to create.
I've had the complete opposite experience with D3. It adds one layer of abstraction (data binding) that is a little hard to understand, but pays off reams once you "get" it.
It doesn't do anything if you just desire to drop in your data - you need to build everything from scratch. On the other hand, if you start with good code or a good example and want to do something slightly different, it's very easy to modify to do what you want.
The amount of code it would take to "do everything yourself" that D3 does would be an order of magnitude more.
The end result is an <svg> element with a bunch of with a bunch of <path> <line> <rect> children. Sometimes you can wrangle D3 to generate the <path>s you want. Sometimes it's easier to more directly make them yourself.
Plottable.js (http://plottablejs.org/examples/) is another library that takes a similar approach: reusable components written in D3, and a table-based composable layout system.
I've been using Plottable recently and it's great. Hope it gets more widely used so there's more material out there about it - it's SUPER powerful but the documentation is hard to understand if you're really trying to extend it.
How come error-bars are so unusual in these sorts of libraries? I'm a scientist and NEVER make charts without error-bars on it, but they're rarely included in charting libraries and when they are it feels like an afterthought.
Most of the data visualized by these types of libraries don't have any sort of variance or confidence interval behind the data. You're looking at things like sales forecasts, server latency, number of employee hours, or other precisely measurable quantities. The whole context around those numbers never talks about the notion of variability or reproducibility, so the idea of putting error bars on there doesn't help communicate anything.
Why don't scientists use these libraries, making error bars an appealing thing to add? In my experience, D3 isn't a great too for interactive analysis: plot, stare, tweak, re-plot. I get bogged down in the details of the visualization, vs something like Matlab that almost always throws up a reasonable plot with interactive controls. Since D3 doesn't encourage the type of workflow that results in a graph with error bars, you get a self-reinforcing dynamic where nobody who works with D3 is interested in making it easy to create graphs with error bars.
(author here) Here's a quick implementation of error bars for d3.compose [1]. The general goal of d3.compose was to provide the foundation for creating reusable charts and components while keeping the standard library of charts/components relatively small and focused. With that said, there are plenty of charts/components in the pipeline (scatter, area, and callout to name a few) and I'll make sure error bars are added as well.
Hopefully HTML custom elements is the future here, where you can just define new SVG tags like you can HTML tags, and then build up a graphics from reusable components.
There are still a few kinks to work out, like making sure <template> is supported in SVG documents, but once that's working something like SVG + Polymer data binding will be better than D3.
The key functionality of D3 is the ability to join a data series against a dom tree, adding, transforming and removing content as needed. Even with polymer and rich components there's still a place for D3.
dc.js is one of those libraries that completely blows client's minds. The hard thing to do as a developer is not to try and filter the data too much. dc.js lets the end-user filter the data interactively and create their own stories, you just have to work out the questions each chart lets the user ask. http://dc-js.github.io/dc.js/
We've really enjoyed c3.js (http://c3js.org/). It has a wide offering of visualizations types and come with nice on-hover tooltips, which is something that I've had trouble finding anywhere else. Unfortunately it's difficult to customize their offerings, but they've covered 90% of our usecases.
I hear this often but I'm not sure I agree. With almost all of these charting libraries you quickly run into the law of leaky abstractions. Most of the examples of things you'd want to do are written pretty clearly by Mike himself. They are easy to adapt by changing a few things around, instead of sticking with an inflexible abstraction.
D3 always looks really interesting to me, but I still just use Highcharts for generating charts (easy to use, great documentation). Any reason to try out D3 for basic charting, or is it best suited for more custom scenarios?
Definitely more suited for custom scenarios. That said, once you've got the basics in D3 it's really easy to start adding pieces of knowledge and customize. Highcharts is a lot more abstracted away.
The Atlantic's Quartz website has open-sourced a simple D3-based charting program called Chartbuilder. It's not as full-featured as Highcharts, but it's free at any usage level and customizable.
It gives you a declarative means of specifying the visualization and comes from the the same lab that created d3