4 ms·

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 y

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.

catpolice 11y ago
Hmm, here's my experience: 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.
- purpleparakeet 11y ago
  FYI, D3 4.0 is just around the corner and breaks the library into different components so you can just import the ones you need.
- jcheng 11y ago
  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. [0] https://github.com/chenglou https://github.com/chenglou
  - snappy173 11y ago
    I just stuck with d3, and used the react lifecycle methods to trigger redraws and such. http://bl.ocks.org/cpapazian/6228888157c39be85e9c http://bl.ocks.org/cpapazian/6228888157c39be85e9c 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.
- rjayatilleka 11y ago
  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.
- andreaferretti 11y ago
  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 https://www.github.com/andreaferretti/paths-js

catpolice 11y ago

Hmm, here's my experience: 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.

purpleparakeet 11y ago
FYI, D3 4.0 is just around the corner and breaks the library into different components so you can just import the ones you need.
jcheng 11y ago
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. [0] https://github.com/chenglou https://github.com/chenglou
- snappy173 11y ago
  I just stuck with d3, and used the react lifecycle methods to trigger redraws and such. http://bl.ocks.org/cpapazian/6228888157c39be85e9c http://bl.ocks.org/cpapazian/6228888157c39be85e9c 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.
rjayatilleka 11y ago
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.
andreaferretti 11y ago
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 https://www.github.com/andreaferretti/paths-js