d3 has a good idea. Unlike its many predecessors like HighCharts, that aimed to individually implement every chart type, d3 went a level down: giving users the fundamental tools they need to implement hundreds of unique graphics. This approach was wildly successful: it made d3 hard to outgrow, so professionals could write front-page graphics for newspapers with the same basic elements as beginners use to implement bar graphs.
It’s been a while since I worked on a d3-centric project like iD, geojson.io, or given a talk about d3. In the past year of working on an application based on React and WebGL, I’ve had time to process where d3 & charting libraries fit into the style and form of the web.
To quell the kneejerk: d3 isn’t tied to SVG: it works perfectly well with HTML and fairly well with Canvas - even a little bit with WebGL. And for a specific range of usage, SVG is acceptable, and will continue to be perfectly usable.
Animation on the internet is a failed experiment.
Virtually every attempt to use CSS transitions to do non-frill effects
runs into a bug
or something that should have been in the spec.
You can choose the flakiness of CSS’s transition property,
and robustness don’t come in the same package. And
we can implement the animations we’ve always dreamed of, but for now
it’s a hack, and a bad one.
Animation is a high priority for d3, and the library implements them directly: instead of using CSS transitions or jQuery-style shortcuts, it gives a robust API for tweening properties and styles. The advanced effects this enabled are one of the main whiz-bang features of the library, and are remarkably browser-safe because they put so little trust in browsers.
Unfortunately, this comes at a high cost. The
update separation built into d3’s data joins
is in large part because of animation.
.exit() could simply zap elements
from the page, and
.enter() could automatically append elements to the page.
And instead of 3 ways to change the DOM given the state of each element,
there would be one, and d3’s DOM-related API would be vastly simpler.
For React, transitions are deemphasized: while react-animation
aims to implement them as a third-party library, the core idea is that the
DOM you propose in
is what the page contains, immediately. In my experience, this vastly simplifies
the art of imagining what’s on the page: whatever the
returned is the truth.
But in the meantime, the truth is that d3 is the best game in town: even if transitions are a boondoggle and SVG is stagnant, there’s no other charting library with such a solid conceptual foundation.
The biggest change to d3 in years is going to be Mike’s modularization of the library, which will enable other developers to include chunks of it with browserify, node, or webpack. I can’t imagine it’s long before someone implements a charting library in React-ART using those parts.
Vega has potential: its declarative way of representing charts makes it uniquely cross-language compatible - Python, R, or Julia could easily generate Vega specifications for their output and eventually grow their own renderers as well. The hope is that the UW Interactive Data Lab gives Vega the support it needs to take off.