Hacker News Reader

Comment by javajosh | Hacker News Reader

I find D3 to be frustrating because it promises so much and yet it's less of a library and more of a "way to write JavaScript". There really isn't an abstraction so much as a convention for calculating the 3 subsets of an intersection and associating each subset with DOM elements, and then 'doing something' with those DOM elements, possibly as a function of the associated data item. Mike has created some amazing visualizations with D3, but for each viz the code is fairly long and hairy. The worst thing though is that it's not composable - or rather, the unit of composability is very low level. D3 doesn't have any helpers for data that changes over time, for example.

View on HN

As a programmer I'm a hacker--in the golf sense of "someone who spends a lot of time at something but still sucks." But d3 has allowed me to build several useful data visualizations. The code may not be short and sweet, but it is pretty easy to write and pretty easy to understand. Perfect for someone looking for just the right amount of abstraction.

Here's something I wrote a while ago using d3 for my own use. It's entirely client-side js. http://neuvc.com/labs/vcbar/ It charts the investment activity of VCs by pulling Crunhbase data. I would not have written this if I didn't have d3 to use as a crutch for the bar charts.

> but it is pretty easy to write and pretty easy to understand

I wish I was as smart as you because D3 makes almost zero sense to me. I think there's something I'm missing that, once it clicks, will change things. <fingers crossed/>

It's not a question of smartness. Take a working example of code and make it do something else. I'm sure I took some bar chart code from one of Bostock's examples and used that as a base. After a few hours of struggling with it (and with freakin' Javascript) and trial and error debugging, it became clear to me what d3 wanted me to do. Then it was easy.

In my experience D3 is very much like that. Before you wrap your head around the way its data binding model works it seems totally arcane (esp. if you are like me coming from using other visualization tools, like matplotlib, where the hello world example is just "plot(x,y)"). Keep banging your head against the wall, it will eventually crumble and all will become clear.

The fact that it's like a functional set of transformations, using closures?

Perhaps you're thinking to imperatively. Read a simple D3 tutorial and things will click.

I run into A LOT of problems trying to make my own charts, but it also serves to show in many cases that you can't abstract charting to account for all the use cases, because there are so many distinct characteristics in every graphic and dataset.

If you want a higher level of abstraction for d3, try Chartbuilder, which I find doesn't cover anywhere near my use cases: https://github.com/Quartz/Chartbuilder.

Another tool is Bret Victor's proof-of-content editor: http://worrydream.com/#!/DrawingDynamicVisualizationsTalk.

By the by: Magic Maps is unbelievably awesome to get your map nerd on. (Or playing around with any shapefile, really.)

Check it out at http://magicmaps.evanmiller.org/gallery.html.

Did he release a tool or source for what he uses in the video?

    I expect to write a full research report at some point 
    (at which I'll make the research prototype available as
    well).

http://worrydream.com/DrawingDynamicVisualizationsTalkAddend...

Bret Victor is famous for tantalizing people with the future but not releasing code :)

Yeah, I'm not holding my breath either. I think his prototypes are usually just conceptual and not meant for use cases, which makes his talks a bit too unfair and utopian for my taste.

I think the secret to d3 is that before you can get much out of it, you basically have to be comfortable with hand-writing static visualizations in SVG. Once you can do that, d3 can give them life.

I've found D3 to be tremendously powerful for some types of visualization. For more-traditional types of plots, I usually use Flot instead. http://www.flotcharts.org/

http://www.highcharts.com/ is worth mentioning also, really awesome high quality charting library.

>Mike has created some amazing visualizations with D3, but for each viz the code is fairly long and hairy.

Huh? I find D3 code to create a visualisation be much much smaller when comparing with competing implementation of the same visualization.

But then, my metric of comparison is creating visualisations from scratch with imperative drawing APIs (on Canvas/SVG).

Perhaps you want a one-line function invocation to draw the whole thing?

D3 is not for that, it's a plotting HELPER library, not an ready-made collection of plots.

That said, it's not difficult to adapt individual plots made with it.

I'm comparing D3 with two of it's progenitors, Prefuse and Flare. All of this is coming out of Prof. Jeff Heer's viz group at Berkeley.

Thank you for posting this. I had a lot of issues with D3 where it seemed like it wanted to be a domain specific language, but at some point decided to be a reimplementation of JS around some arbitrary starting point of thinking in R-like or HDF-like data frames or something, and then just got out of hand.

There are a ton of cool interpolation and features and such, and you can use them probably here and there without everything else from D3, and I have managed to do that on occasion. If someone were to make a debugger specifically for D3 or just generally say "forget JavaScript and drink the coolaid and just copy our awesomeness and forget about making your own" I think that would be in line with how D3 is presented. The composable part is spot on. I think OpenFrameworks also suffers from this. They demo their awesome thing and eventually make a library in OF, but as far as using OF itself to make that original awesomeness, that's when one would just say "well, I guess OF is cool for doing exactly what you see people doing with OF but anything more is just C++" ... anyway. So it isn't a framework or an abstraction per se, but a series of just previously developed functions that let you repeat what the author did.

Personally I feel the reach is too broad to be considered a library. It's becoming some of an Ext for visualizations.

D3 is definitely a library, though not a framework. There are conventions, but there are also magical abstractions that work together like selections, data-binding and transitions. I would not call the eight lines of code you need to write for a basic visualization and transition "low-level".

Composability is achieved with configurable functions. Is there an alternate solution you propose? What helper would be useful for data that changes over time?

svg.js is a library. d3 is definitely a framework.

This is an interesting comment to me because I came to D3 having written zero Javascript and picked it up as I learned D3. D3 does feel like both a library plus a set of conventions. That being said, I find it to be very powerful once you grasp the basics. I've also used some higher level libraries like NVD3.js when I didn't feel like starting from scratch.

Reply on news.ycombinator.com