My other issue was with async/await. It seems like when I used async await on a locally hosted csv file, it could take between 1 and 2 seconds to load. For my colleague sometimes minutes. When I switched to d3 v4.0 and the old callback approach, it loaded instantly, even for my colleague. What gives?
Yes. Note that you need to use
Here is my Makefile in case you'd like to look at the arguments I pass to Closure compiler: https://github.com/ctsrc/Infinite-Tower-Run/blob/191a4035fd1...
Babel (transpiler) is super easy to setup if you have any problems with compatibility.
The difference between 1s & 1m lag in D3 has got to be a D3 bug.
Nowadays if I need to do interactive visualisations I typically end up using Mobx + SVG.js. It works really well and I rarely get other developers asking me to explain how it works so that's a HUGE plus.
It let's you modularize your d3 code into components. Very handy!
I played with D3 every now and then for maybe the past 6 years to scratch some data visualization itch, but I never really understood it. I always wound up trying a code snippet from a random blog and got frustrated when I couldn't get it to bend to my needs.
It finally clicked for me a after I read the first few introductory tutorials on the D3 Github wiki. It made me realize that, while it was probably built for data visualizations, D3 at its core is a browser DOM manipulation library with a (data-driven) declarative API. It's a slightly higher level of abstraction compared to the DOM manipulation part of jQuery (though, many frontend developers these days consider jQuery to be a low-level library).
Of course, it also helped that I learned a lot over 6 years. I was a university student back then, and now I'm a professional software engineer who has spent the last year or so doing frontend development. D3 makes a lot of sense within the context of my current understanding of how browser DOM APIs work.
I am disinclined by temperament to use low level tools for tasks that really should have a sensible generic abstraction. I know some people's brains err in the other direction - each to their own.
(I'm pretty sure tools exist. I used https://bokeh.pydata.org a few years ago when I needed something along these lines. I looked at d3 and had a similar reaction to the grandfather comment)
In practice, handling dynamic updates requires so many hooks into the data that you can't really define a sensible abstraction layer and have it work well for both simple cases and complex cases. D3 is the successor to Protovis, itself the successor to Flare, itself the successor to Prefuse. And having used all of them save Flare (since I've never had the ability to write Flash code nor the desire to do so), d3 is the only one that I've actually enjoyed using.
If I ever have to make a chart with another language, I cry because I can't use d3. I have reimplemented portions of d3's api in other environments like native Android before. Digging through the docs to find whatever configuration variable I'm supposed to set reminds me of the days of jquery plugins.
The d3 specific parts are the idea of mapping data to DOM elements (which is the part I think is beautiful), how it uses the data join to do so, and how you use the scale functions to map from data space to pixel space to set the element positions and other attributes.
Feel free to email me if you like -- it's on my profile.
I was under the impression that a lot of higher level libraries were built on it.
If you want to do dynamic visualisation with something like Python or R in a browser you need need a server, and that incurs significant latency.
D3 also allows much more fine grained control over visualisations than any visualisation library or package I’ve worked with in any language, because you have total control of every line, point, every fill.
No matter what crazy design the design team comes up with for your website, D3 will let you bind data to it and turn it into a workable chart.
It was written by an editor at the New York Times, and it is designed for producing bespoke visualisations on public facing showcase pages where appearances and speed have to be state of the art.
Not true. Bokeh (http://bokeh.pydata.org) lets you build interactive web graphics that run purely embedded in a static HTML file. No server needed.
(Of course, it also has a server-based mode that lets you build interactive analytical viz apps, with browser interactions automagically driving Python callbacks)
It's not so much for people wanting to make new 'instances' of a visualisation. It's more for people wanting to make new 'classes' of visualisations.
It is oriented around the lifecycles of instances of data - eg entry and exit hooks to run as data appears and disappears, and it has a lot of powerful lower level functionality.
d3 is for interactive charts
Write Python, make interactive web plots.
everyone has a web browser...
This is a limitation that may make no difference in some cases, but in others it is important for code to execute in the client.
A good example of this is making a visualization that seamlessly responds to the user's mouse pointer.