
D3 v4.0.0 released - aw3c2
https://github.com/d3/d3/releases/tag/v4.0.0
======
yoavm
D3 has the reputation of being super-complicated because of all the libraries
that are based on it, "simplifying" it so that everyone can use it. In the
past year I wanted to create pretty unique type of data visualisation, so I
dived into D3 and discovered it a makes a lot more sense than I though. Of
course, if you only want a regular bar chart, you'll do better with things
like C3, nvd3 etc'. But if you want anything a bit special, D3 itself is very
powerful and the documentation in pretty good - there's no reason to avoid
using it directly.

Definitely looking forward to try the new release.

~~~
minimaxir
To add to that, if you are a complete newbie to any data visualization, do not
_start_ with d3. If you want to make pretty charts programatically, using
R/ggplot2 or Python/Seaborn is good enough. Even Excel is fine if you tweak
the defaults.

D3 is good if your visualization _benefits_ from interactivity, either with
dynamic data adjustment or rich tooltips. But static visualizations are
important too. (I recently restructured my workflow so I can output static
images _and_ interactive charts with the same code, which makes it the best of
both worlds.)

~~~
nonane
Any recommendations for doing realtime charts that update a few times per
second?

~~~
clickok
I have used Epoch[0] and Rickshaw[1] before for similar purposes, and have
heard that Plotly works well too (especially if the process that is generating
the data is Python-based). For simple line charts, maybe Smoothie[2]?

Currently, I am trying to make a dashboard for visualizing many different data
sources with WebSockets and Chartjs but it's still not quite ideal-- there's a
bit of lag, and sending too much data via JSON really slows things down. If
anyone has solved that this problem I would appreciate it if they told me how
they did it.

0\. [http://epochjs.github.io/epoch/](http://epochjs.github.io/epoch/)

1\.
[http://code.shutterstock.com/rickshaw/](http://code.shutterstock.com/rickshaw/)

2\. [http://smoothiecharts.org/](http://smoothiecharts.org/)

~~~
8note
for a fair bit of interactive data updating every second over websockets, ive
had some success with DCjs.

On ios, the performance wasnt the best though

it was replaced with straight d3 i think, or maybe something rendering on
canvas

------
monfera
Fantastic work! D3 has a large API surface area, due to the functionality it
covers. So even a relatively conservative major upgrade is a TON of work, and
some of it might not have been pure fun only.

1) What's your opinion on the apparent case that the bulk of changes come from
you, as society promotes teamwork so much? Is it a case of 'small team
efficency'? (Btw. I know of others' contributions too, and reliance on Rollup,
ColorBrewer, matplotlib/Viridis etc.)

2) What kept you going? It's probably at least a person-year of work just on
your side that's not paid for by companies, not to mention some kind of
startup bet. Have you alternatively toyed with the idea of starting a value-
added layer, since so many for-profit organizations benefit from your work?

3) While it changes the API, and most everything is rewritten, it's IMO a
conservative upgrade in that it doesn't steer away from familiar concepts and
structure. It still does DOM binding, transitions, layout etc. fairly
similarly. Have you considered much more disruptive departures? As an example,
React's DOM diffing is more radically different from D3 selections than the
change from D3 3.* to 4.* or the Grammar of Graphics as an API concept is more
radically different from D3 than the 3.* -> 4.0 API changes. Or something like
moving away from the 'functional objects' concept in favor of curried, fixed-
argument pure functions, perhaps prefaced with the familiar chaining API would
have been a large change (these are mostly examples rather than wishlist).
What were YOUR ideas, had you wanted more disruptive changes, or 'D4'?

~~~
smrtinsert
IIRC a key point of d3 was to not be declarative, like the gog. That was more
an influence in protoviz, its precursor.

You might be interested in Vega and Vega lite if you want to go declarative.

~~~
monfera
I'm contributing to plotly.js right now, which is also declarative, and I see
the pros and cons of levels of denotative semantics (mostly depends on goals
and library user requirements) but it was just an example for what I mean by
more radical changes. Good you mentioned it anyway, protovis -> D3 also
represented a rather disruptive change. But perhaps I was late with these
questions for this specific AMA.

------
a_humean
Changelog (weekend reading):
[https://github.com/d3/d3/blob/master/CHANGES.md](https://github.com/d3/d3/blob/master/CHANGES.md)

Really excited about this release. It seems like nothing has been left
untouched with major changes to everything from selections to layout
generations and the modularisation of the entire lib (think lodash).

There are major namespace changes with basically everything being flattened (
d3.geom.voronoi -> d3.voronoi) and many of the typical patterns will have to
be relearned (major changes to selections), so I don't see upgrading any
existing projects and I may have to hold off on using 4.0 in new projects
until I actually understand what has happened.

Favourite thing so far has to be the changes to selections, which I think will
make things a lot clearer to newer users:
[https://github.com/d3/d3/blob/master/CHANGES.md#selections-d...](https://github.com/d3/d3/blob/master/CHANGES.md#selections-d3-selection)

~~~
mbostock
Aye, a lot has changed! I know change in itself is a pain; despite the
quantity of changes I did try to avoid unnecessary change, and batch the
changes into a rare major release. I believe such change is worthwhile, and
that it’s better in the long run to keep improving the API than to be tied
down to past mistakes.

The renames (like d3.voronoi instead of d3.geom.voronoi) are superficial
changes, so although it might seem disruptive, it should be pretty easy to
update your code and habits. At least, I haven’t found it difficult… The more
design-y changes, like the new d3.stack and d3.treemap, require thought to
migrate existing code. But the new designs are much better, so I hope you find
the effort worthwhile.

~~~
zellyn
I know Perl6 and Python3 have shown the dangers of changing things in
disruptive ways. But I still appreciate your willingness to change things
carefully to make them better. The length of time your software will be used
in the future almost certainly outweighs the length of time it was used in the
past :-)

~~~
mbostock
I thought about the Python 2/3 debacle a lot this past year, and yes, I hope
this isn’t a repeat. The Python migration was especially hard because of
dependencies between libraries (you could only migrate your library or
application to Python 3 after your dependencies migrated), and because Python
is used for many large, long-term projects. Certainly D3, too, has its own
plugin ecosystem and long-term projects, but it’s also commonly used as a
standalone library in short-term work, such as in news graphics—where
migration should be much easier. So hopefully that pain is lessened.

------
jonahx
Just want to say how much I appreciate the refactoring into smaller libraries.
d3 has enough traction that it's not something they had to do, but it's the
right thing to do, and probably took a good deal of effort and thinking.

~~~
mbostock
Thanks. It’s definitely more fun to work on the pieces of D3 individually,
rather than feeling the weight of a massive monolith. Hopefully it will
encourage others to develop more reusable libraries that depend on (the
relevant parts of) D3, too.

~~~
cprayingmantis
Just wanted to say that your work is very much appreciated. I've been using D3
since it was Protovis and I love it. Excited to dig into the changes and try
it out.

------
iyn
What's the best way to integrate D3 and react? Or there's a better approach to
charts/visualization in react than using D3?

~~~
Androider
I've recently been experimenting with pure SVG and React, which seems like a
really good fit. Just draw SVG in your render function as naively as possible,
and let React figure out the DOM transitions. Super easy to debug and reason
about.

Not being too familiar with D3, what would I get by adopting it? I would hope
for higher level primitives, but the API seems imperative and stateful, which
doesn't seem like a good fit with React. Would I end up duplicating and
syncing my existing app model state into D3 state?

~~~
danjc
We built a workflow design ui with svg under react and for the most part it is
an absolute pleasure. Also pretty neat that you can treat the svg as an
image/thumbnail. If you need the svg to be interactive, overlaying html works
well too.

Example at [http://flowgear.me/s/1Ae7Pso](http://flowgear.me/s/1Ae7Pso) if
you're interested.

One thing to watch out for is that there are some svg object attributes (and
some objects) that aren't declared in react.

~~~
monfera
You can generally use them with 'is', for example: <marker id={'bar'} is
markerHeight={viewModel.height} refX={viewModel.xCenter}
markerWidth={viewModel.width}>

------
blaze33
Does anyone know if there is a good way to do server-side rendering (svg
files) of D3 charts while being able to reuse the same code in a browser?

We do a lot of charts at work to visualize electricity consumption and are
currently thinking about how to rewrite the js we've accumulated over the
years. I've found some attempts at doing server-side rendering but nothing
really compelling for now...

D3 is a well thought out library to do interactive visualizations in the
browser and having an easy way to do svg exports (for things like automated
emails) would be a big plus. Doing screenshots through selenium ain't always
so pleasant ;)

~~~
m0j0l
Not sure if it fits your use case, but; for one project I needed to have
charts that the user could modify in their browser, and once they were happy
they could hit 'download PDF' to get a PDF version.

Achieved this by (admittedly slightly clunky way) of sucking the SVG out of
the chart and sending it to the server via ajax. Server intercepts SVG and
passes it to inkscape which does pretty good command line svg -> pdf... then,
sends back completed PDF.

One gotcha is that you won't get any CSS this way, so all styling has to be
done via SVG props.

~~~
e1g
That's exactly what we are doing but running the SVG code through Apache Batik
Rasterizer to turn it into png. I like this approach because the user can
customise the chart in the front end and then the same resulting svg code is
rendered by the backend. The only issue is styling as you mentioned.

------
con_ssc
1\. Are there any plans to have a TypeScript version of the lib?

2\. Would it be possible to add jsdoc comments for autocompletion?

3\. Are the polyfills for Map and Set still necessary now that we have that in
es2015?

4\. Why is the lib so heavy on argument overloads?

5\. Are there any code style restrictions? I often saw loops and conditions
without curly brackets and alike.

6\. Are there any fields you'd need support in for maintaining or reworking
the library?

I really like D3.js although I haven't found an application for me yet. I find
it hard to get/update the date from a none standard REST endpoint and display
them, especially if they are kind of multichanneled, like working times of
multiple users unordered.

------
betageek
Looks like quite a lot to take in, where should we start? - are there updated
tutorials, upgrade guide etc?

~~~
mbostock
The place to start is the release notes:
[https://github.com/d3/d3/releases/tag/v4.0.0](https://github.com/d3/d3/releases/tag/v4.0.0)

And the detailed change list:
[https://github.com/d3/d3/blob/master/CHANGES.md](https://github.com/d3/d3/blob/master/CHANGES.md)

I will update my tutorials and examples (and probably write new tutorials) in
the near future, and I expect others will, too. But as I now have thousands of
examples, I didn’t want to hold the release on updating all of them. My newer
examples use 4.0 already, and I’ll be going through the others in the coming
weeks.

~~~
enjalot
Does this mean you intend to update your existing examples in place? It might
be nice if you forked them with v4 instead to create a defacto upgrade guide.

I know many tutorials reference your examples and it might create more
confusion if they are updated in place.

I suppose it depends on how much you want to keep supporting v3, but I'd argue
its worth keeping the old knowledge base intact for a while.

~~~
mbostock
Yep, I’m going to update my examples in-place. Consider it my heavy-handed
encouragement to upgrade to 4.0. (For one thing, there are lot of 3.x bugs
fixed in 4.0, and I have limited resources to provide free support to old
versions.) My examples are backed by git repos, so you’ll still be able to
find the 3.x versions if you need them.

~~~
enjalot
fair enough!

------
rusosnith
Is it possible to have V3 and V4 coexisting in a project? Like, adding some of
the awesome v4 new things to an already working v3 project without having to
rework all the v3 code to v4 compliance?

I've tried doing this with v4 beta, with strange behaviours :)

~~~
mbostock
Hmm. It might be possible, though it doesn’t sound like a great idea to have
both D3 3.x and the D3 4.0 default bundle loaded simultaneously, since there
will be a lot of overlap. A better strategy might be to load just the new
modules you want to use. Like if you just want the new force layout, then load
d3-force: [https://github.com/d3/d3-force](https://github.com/d3/d3-force)

But it might be best to just migrate to 4.0. I know the changelist is long,
but it might not be as hard as you think to migrate. And you can always send
your questions to the d3-js Google group or d3.js on Stack Overflow and I’ll
try to help.

~~~
chrisprice
On a project I work on* we've found that this technique has worked well so
far. We're slowly moving from v3 to v4 by splitting out groups of components
into their own packages and upgrading them as we go. We've been heavily
inspired by d3's approach e.g. with the use of rollup for bundling.

We're probably at about 60% of the library upgraded/split-out but we've yet to
tackle the more tricky changes like d3-selection.

* [https://github.com/d3fc](https://github.com/d3fc)

------
gkst
Exciting release! I played with the force layout on canvas to graph reddit
conversations
[http://ramiro.org/tool/graphit/](http://ramiro.org/tool/graphit/)

It's harder to get interaction done with canvas compared to SVG, but for large
graphs the performance gains are huge. Curious to dive into the other new
features.

Thanks for this incredible piece of software mbostock!

------
dnprock
For those interested making d3.js reusable for data analysis, check out
[https://vida.io](https://vida.io). We create templates out of d3.js
visualizations with dynamic properties. You can create dashboards from custom
d3.js components. For more examples, see
[https://vida.io/explore](https://vida.io/explore).

------
dswalter
Modularization aside (and it's terrific to have in the library), what
additional functionality are you most excited about with this release?

~~~
mbostock
Let’s see, in no particular order…

* New pretty continuous color schemes (viridis, rainbow, ColorBrewer)

* New axes that are easier to use.

* Vastly improved circle-packing layout.

* More stable, extensible force layout.

* Cleaner implementation of immutable selections & transitions.

And a ton of other stuff. Taken overall, it feels like a big step forward in
robustness and cleanliness. And I’m hopeful that it’ll be easier for folks to
develop more D3 modules.

------
sntran
For simpler need such as rendering a SVG map from Topojson or GeoJSON data, is
there an alternative than D3 that can utilize React.js' rendering of SVG? With
no animation, no charts, just map with zoom in and out and drag around, is
there a benefit of using D3?

------
th0ma5
Did they remove the emphasis n the .enter() pattern yet? This is the weirdest
thing compared to how just about every other library works, and it can totally
be avoided by just using the data() stuff directly.

------
dmix
Any 4.0 tutorials available yet to dive in and try it out for a first-timer?

~~~
gkst
Many of mbostock's recent "blocks" use D3 v4
[http://bl.ocks.org/mbostock](http://bl.ocks.org/mbostock)

These are not tutorials, but working examples with some introductory texts.
They are very helpful for diving into D3.

------
toothrot
Why didn't they name it D4

~~~
colejohnson66
Because D3 is the actual name of the library. The full name is "Data-Driven
Documents v4.0.0". Shorten that and you get "D3 v4.0.0".

~~~
8note
and there's a derivatived library called D4 as well

~~~
mrits
Derivatived Data Driven Documents?

------
dasdas1111
dsadsds

------
nthitz
More comments here
[https://news.ycombinator.com/item?id=11994410](https://news.ycombinator.com/item?id=11994410)
including from @mbostock. Not sure why it didn't stay on FP.

~~~
sctb
Thanks, we've merged that thread with this one.

