Skip to content(if available)orjump to list(if available)

Why is D3 so Verbose?

Why is D3 so Verbose?

39 comments

·August 21, 2025

text0404

Note: the example is a misconception and not what's meant by "binding to data." In D3, binding to data refers to using the `.data()` method to supply an object (typically an array) which you can then use in a function callback in the accessors, so like `.attr('x1', d => /* access individual array item here */)`. This allows you to easily bind a dataset to a graphical representation and use its attributes to inform the properties of the visualization.

I'd also argue that D3 is no more verbose than vanilla JS (at least for this example). What's the alternative for creating a line in SVG?

    const line = document.createElementNS('http://www.w3.org/2000/svg', 'line')
    line.setAttribute('x1', ...)
    line.setAttribute('y1', ...)
    line.setAttribute('x2', ...)
    line.setAttribute('y2', ...)
    // etc
    document.querySelector('svg').appendChild(line)

TheHeasman

This is very fair: I went for a metaphorical explanation, rather than a literal one. (For instance, I'd actually have had to write down the code for an SVG, and I was quickly writing this on my lunch break).

The `.selectAll().data().join()` data binding method (or `.enter()` on older versions) is very intuitive once you understand it, but for the layman coming in, it's inaccessible AF. I fudged a little in my explanation to make it more accessible. But hey. That's learning.

text0404

For sure, data joining (and enter/exit) is arguably the learning curve wrt D3. TBH since I've started using FE frameworks which handle the DOM, d3-selection (and having to think about data binding) has almost completely fallen off my radar. Now it's mostly using functions from d3-scale, d3-geo, d3-shape, etc then mapping over that output to manually render DOM nodes.

bapak

> I'd also argue that D3 is no more verbose than vanilla JS

Right? So why load a bunch of JS to do the same thing? One step further, why load any JS at all since you're just generating an SVG? People have forgotten that HTML and SVG are meant to be DATA containers, you don't have to use JSON + JS.

D3 is cool for the advanced visualizations and the interactivity. If you're sticking to static graphs, for the love of god just have the server serve a static SVG.

text0404

I build browser-based apps that stream and visualize realtime data so the JS is a must, personally. For a static chart that never changes and isn't interactive, 100% agree. Idk of anyone who isn't pre-baking and optimizing the hell out of their assets, but I'm sure it happens with folks who are still in the learning phase.

trjordan

Man, my first startup in 2010 used protovis, the charting library Mike Bostock built before deciding d3 was the better approach. It was rough to have an 8 month old startup with a core piece of tech that suddenly stopped improving.

My main takeaway from so much of this is that "just a chart" is one of the biggest sources of hidden complexity in displaying useful information to people. It's right up there with "a simple web form" and "a web page with some simple interactivity."

Everybody has a wildly different idea of what good looks like. Defaults will never be right. Personal and global taste changes annually. We clown react (rightly) for constantly reinventing the same 4 wheels, but customers gleefully use new stuff all the time.

It's kind of amazing that d3 has been so durable in the frontend world. It really is a wrapper over a pretty solid approach. And yeah, that approach is complex, but that's the reality of visualization. It's hard to imagine another one that's that good.

tmcw

All right, I got nerdsniped into writing a "yes and" sort of thing even though I agree with the gist of this article :) https://macwright.com/2025/08/21/why-d3-is-so-verbose-anothe...

TheHeasman

Ahhhhh. Thanks man. And totally nerding out here because YES. ANIMATIONS. Animations is why I fell in love with wanting to learn D3 in 2019. You can do things as you transition between data steps, that honestly, has been such a pain in the behind to try with anything else. I'm not a web developer. I'm a data guy.

fwip

Speaking of animations, I used D3 to build my first web video game, a little match-3 game: https://fwip.github.io/colormatch/ The whole game board is a single SVG.

It clearly has some bugs (like the score sometimes being NaN - no idea how I messed that up), but I haven't touched the code in over a decade, so it's a little time capsule.

lenerdenator

More granular control, more verbosity.

I am still proud of the D3 gadget I made about 8 years back as a green web dev. Couldn't have made it any other way, not sure if I could with any other library today. Wouldn't want to do it again, though, unless I was a dedicated front-end guy.

biowaffeln

recently i've been having a lot of success with working with d3 + solid.js. I use d3 as the data processing layer, and solid for actually rendering svgs from the data. the combination is lovely, you get all the power of d3, while the parts that usually end up verbose are written succinctly in jsx. and it's a lot less pain than doing it in react, because the mental models of solid/d3 feel much more aligned

TheHeasman

I'll check that out. At the moment I'm just building up a bunch of template code which I'll re-use. But might check out solid.js.

esafak

I feel like D3 ought to be the for-computer substrate for libraries that are actually for humans.

I suppose it matters less now in the LLM age.

null

[deleted]

lionkor

If your LLM is the only one that can reasonably maintain your software, you essentially created a new kind of lock-in, similar to what we already solved with open source a long, long time ago.

Once your LLM gets too expensive, goes out of business, and the competitors just don't quite do it the way your favorite LLM does it, you have a problem.

esafak

Speaking for myself, when it comes to D3 the problem is being locked out :)

moron4hire

This is why I've always found it weird that people consider D3 to be a charting tool. Yes, people have used it to build a lot of charts, but it's really just a streaming data processing tool. It doesn't provide anything specific to charting[0]. All of that part, you're still left to figure out on your own.

[0] At least in the core, I'm not too familiar with the full ecosystem and what is considered official in terms of plugins. Everytime I've tried to use it, I've not found the documentation leading me to using anything more specifically oriented towards charting.

joshcartme

At least these days I think Plot, https://observablehq.com/plot/getting-started, which uses D3 under the hood and is from the makers of D3, is probably the closest thing to an official charting tool built on top of D3.

digitalWestie

This is the answer. People need to consider D3 more as a graphics/dom manipulation library than a charting library.

gedy

Yeah I used to pull my hair when a team would start down the D3 path for some non-interactive graphic, and then push back when I'd explain you can just use SVG for this simple case.

null

[deleted]

TheHeasman

Yaaasss. I think of it as being able to use a pencil to draw charts (and do creative stuff like Florence Nightingale's original polar area graph), instead of having a stencil that can draw things for you. It's a way to visually manipulate the DOM in a way if you're comfortable with data.

You can simply just use Tableau or Power BI and take screenshots otherwise.

null

[deleted]

z3ratul163071

the author was inspired by early directx apis

ramesh31

Becasue the alternative is big config files or a declarative DSL. Builder pattern works really well here to keep things simple.

thrown-0825

I love D3, but its a library not a language.

TheHeasman

Agreed. I fudged quite a lot in my post to make it accessible to the layman. Triee to explain to a UX designer I know that "D3 is a library for JavaScript that..." And I saw their brain switch off live in front of me.

Semantics matter more than literals sometimes.

*EDIT: Grammar. I was typing on my phone. Soz.