Why Is D3 So Verbose?

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

It was a little gauge to help visualize how much money was left in a given stage of a health insurance plan. Not exactly the coolest thing, but... hey. Still happy about it.

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.

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.

Maybe overloadable operators like in C++, where -> usually demotes some kind of deeper access into the object or abstraction? Or, the opposite, and abstracted access.

Probably a reference to Clojure's arrow operator:

https://blog.frankel.ch/learning-clojure/2/

Something like a(b(c(d(e(7)))))) in Javascript could be written (-> 7 e d c b a) in Clojure?

The feature the person you're replying to is talking about is not arrow functions (`=>`), but what are called "threading macros" in other languages. In Clojure[1], the main one is named `->` and used as a way to thread a value through a series of functions that take it as a first argument, using the return value from the first function as the first argument to the second, and so on. It allows you to compose a series of plain functions to transform a value instead of (stateful) method chaining or nesting functions.

JS does not have a straightforward equivalent. The old and deprecated `with` keyword might seem similar but it's only a surface resemblance as it does not perform the return-value threading that makes the above pattern useful, it was meant for methods that mutate object state. There's a TC39 proposal[2] to add a pipe operator that would accomplish a similar thing to threading macros via an infix operator but it's still a draft.

[1]: https://clojure.org/guides/threading_macros

[2]: https://github.com/tc39/proposal-pipeline-operator

And I know more about JavaScript than I'd like to, so don't trust me.

D3 renders using the logic you provide, and while it gives you a lot of helpers to make it easy to write SVG or HTML canvas tags, it's just as easy to tie it into other JS frameworks as well.

D3 provides a bunch of utilities for building visualizations beyond DOM manipulation. Here are some of the modules I use regularly:

- d3-array: data processing

- d3-scale: mapping from data attributes to visualization encodings

- d3-scale-chromatic: color schemes

- d3-shape: defining the shapes of paths, such for a line chart

- d3-color: manipulating colors

- d3-time: manipulating dates

- d3-format: formatting numbers

- d3-time-format: formatting dates

These modules are useful even if you don't use D3 to manage the DOM. For example, you can use these utilities to help calculate all of the attributes for your SVG elements, but then use Svelte/React/Solid/Vue to create and render the SVG.

If I'm building a visualization inside of a web app, I tend to prefer this approach since it leaves the framework in control of the DOM throughout the whole app. It feels simpler, especially if I want interactions in the visualization to modify the app's state.

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.

I don't use D3 but would love to revisit it in the age of LLMs

When Francisco Tolmasky launched Objective J, he wrote a really interesting article that still impacts how I think about this stuff more than a decade later.

Francisco was working on an in-browser slideshow tool like Google Slides, but in the late 00s. To power it, he invented his own language: Objective-J. It had its own toolchain, in the days when most developers were just writing JavaScript inline or maybe in .js files.

Remember, it took React a few years to catch on because it required command line tools to translate JSX to JS. This had the same friction, but years earlier.

This was the thesis behind Objective-J: In the late 1900s, C was the foundation of a good language, but it needed another layer of abstraction on top of it to be more ergonomic. The developers at NeXT/Apple built that layer and called it Objective-C. Objective-J saw the same potential in JavaScript, and ported the ergonomics of Objective-C atop it. It basically tried to do for JavaScript what Objective-C had done for C.

This was the critical part of the argument:

JavaScript (in the era before modules, => functions, and the other current niceties) was the core of a useful language, but it needed a more ergonomic layer on top. Libraries like jQuery were building de-facto DSLs, but calling them libraries. Objective-J was taking conceptual responsibility for being a language on top of JavaScript, instead of being "just" a library. By owning up to being its own language, they could take syntactical liberties that they couldn't under the constraints of being just another JS library.

ok, I'll buy that, definitely feels like it

No fun to have to do a panic migration!

Anyway my latest startup is trying to make AI do migrations, in no small part because of this problem 15 years ago.

I like d3 and echarts. Everything else feels a bit hacky.

I tried for a few years to help Streamlit deployments in production. Never will go that direction again. Litestar + React with echarts or d3 is the way to go. Or use your favorite application backend, but REST is almost certainly the way your use case needs to go.

Trading view charting_library is a nightmare. D3 is a pain to learn, but unmatched.

I know that it is a SVG thing[1], but wouldnt that be a point of sth. like d3 - to be a software that gives me the option to choose my coordinate system origin with one line of code and deals with all the bullshit internally?

[1] and before that, a "every screen is a CRT TV with a photon gun that 'draws' lines, starting in the top left"-thing

> I would say that nearly everything in the real world (outside math) especially computer related uses top left as an origin.

I concede that point, its not want to meant, but I did express my point poorly.

  My point is:
  - A lot of things work like books[1]: top-left to bottom-right
  - However, 99+ % of graphs (anything from revenue numbers to health data) in all mediums (books, newspapers, websites) use a bottom-left origin. Never seen a revenue bar growing from top to bottom. In fact, I dont remember the last time i have seen a graph not using the I. Quadrant. Do you?
  - D3.js (imo) is a lib to create graphs from data, but does not abstract this problem away? Why?

[1] "western/latin"-style books ofc