Feels like less than a year ago that we had D3 v6!
D3 v6 was released on 27th Aug 2020, so your feeling is right. We seem to get a major release about every year now, compared to every two years before v5.
D3 7.0
21–30 of 65 posts
Re: D3 7.0
#22So, is d3 tree-shakeable yet? If I import { scaleLinear } from 'd3' in a webpack-built project, will I get only the scaleLinear code? As far as I remember, in v6 this will import a lot of (or perhaps the rest of) d3 as well.
Re: D3 7.0
#23Earlier quoted context omitted.
The difference is that examples in Codepen are easily reproducable in another environment. d3, on the other hand, has converted most of their examples to Observable, which requires extensive research to convert back to JS (in the best case) and in the worst case requires reverse engineering the runtime. I'm not the only one with this opinion, there are plenty of others who have struggled through similar issues and di…
I work with both D3 and Observable full time. The claim that one has to "reverse engineer the runtime" is simply absurd. The people that complain about D3 on observable always turn out to have taken neither the time to understand Observable nor D3 and are looking for a way to just copy paste something into their codebase, without understanding it, and without any willingness to really learn the tools they are using.…
> taken neither the time to understand Observable nor D3 and are looking for a way to just copy paste something into their codebase, without understanding it, and without any willingness to really learn the tools they are using.
That's how many of us learn, by dipping our toes into a new SDK by copying and pasting into our bare HTML/JS page and tweaking things to see what happens. Eventually we will get around to reading the full documentation.
I have made d3 examples and played around with the toolkit since back when it was in its infancy (called protovis or something). It has definitely become more and more difficult over the years for a beginner to jump into.
(Background: I have met Mike since I got my PhD from the hci/graphics lab at Stanford, but we did not overlap.)
Re: D3 7.0
#24Earlier quoted context omitted.
I work with both D3 and Observable full time. The claim that one has to "reverse engineer the runtime" is simply absurd. The people that complain about D3 on observable always turn out to have taken neither the time to understand Observable nor D3 and are looking for a way to just copy paste something into their codebase, without understanding it, and without any willingness to really learn the tools they are using.…
> taken neither the time to understand Observable nor D3 and are looking for a way to just copy paste something into their codebase, without understanding it, and without any willingness to really learn the tools they are using. That's how many of us learn, by dipping our toes into a new SDK by copying and pasting into our bare HTML/JS page and tweaking things to see what happens. Eventually we will get around to rea…
You make my point.
What better environment to learn and twiddle, than a reactive, constantly reevaluating interactive notebook?
Re: D3 7.0
#25Used this in a data viz class and I’d say it’s overkill for most visualizations. Also very difficult to learn and frustrating to implement with all the “enter, exit” stuff. Excel, Tableau, etc so much easier and most of what you need to do visualizations in the corporate setting. Obviously it’s excellent for very specialized unusual visualizations but it’s rare those are really needed.
All the "enter, exit" stuff is what makes d3 beautiful. From a core handful of ideas, Mike is able to express a vast world of visualizations. I think it is the most amazing framework I have had the pleasure of using in my 30+yrs of software development. Ya, you could grab bar chart library and just give it data and get a graph out, or, you could spend a little time with d3 and actually learn something so powerful you can make bar charts - or virtually any other kind of visualization you will ever need. Well worth working past the frustration, imo.
Re: D3 7.0
#26Earlier quoted context omitted.
> taken neither the time to understand Observable nor D3 and are looking for a way to just copy paste something into their codebase, without understanding it, and without any willingness to really learn the tools they are using. That's how many of us learn, by dipping our toes into a new SDK by copying and pasting into our bare HTML/JS page and tweaking things to see what happens. Eventually we will get around to rea…
You make my point. What better environment to learn and twiddle, than a reactive, constantly reevaluating interactive notebook?
Whatever environment each user prefers.
Being softlocked into Observable is not a pro.
That's like trying to force every vim user into Jetbrain IDEs (both are great, not trying to start a flamewar here).
Sure an IDE will have more features (like Observable vs simple HTML file), but it's important to understand different people have different ways of doing things.
Re: D3 7.0
#27Used this in a data viz class and I’d say it’s overkill for most visualizations. Also very difficult to learn and frustrating to implement with all the “enter, exit” stuff. Excel, Tableau, etc so much easier and most of what you need to do visualizations in the corporate setting. Obviously it’s excellent for very specialized unusual visualizations but it’s rare those are really needed.
If you want the polish of d3 and some of its power without all the complexity, try Vega Lite and related tooling: https://vega.github.io/vega-lite/
Re: D3 7.0
#28The one critique I have of D3 is that it is becoming increasingly closely paired with Observable, such that when I'm searching for examples of how to make something in d3, I can only find Observable examples that require the Observable runtime in order to function properly. I think the examples should have a JS native version in addition to the Observable implementation.
It's a real pain. I work with lots of "data science" types who are often trying to concurrently learn JavaScript and d3 - often with JS as their first or second programming language. It's difficult enough for an experienced programmer coming back to d3 after a few versions to pick out what's d3 vs. what's Observable - and very difficult to help a relative newbie through the process of turning what's shown in an Obser…
Even more difficult to deal with that and conforming it to Vue/React SPAs
Re: D3 7.0
#29Earlier quoted context omitted.
I work with both D3 and Observable full time. The claim that one has to "reverse engineer the runtime" is simply absurd. The people that complain about D3 on observable always turn out to have taken neither the time to understand Observable nor D3 and are looking for a way to just copy paste something into their codebase, without understanding it, and without any willingness to really learn the tools they are using.…
> taken neither the time to understand Observable nor D3 and are looking for a way to just copy paste something into their codebase, without understanding it, and without any willingness to really learn the tools they are using. That's how many of us learn, by dipping our toes into a new SDK by copying and pasting into our bare HTML/JS page and tweaking things to see what happens. Eventually we will get around to rea…
This is my experience as well - when deciding whether to use a certain library or framework, I don't start reading the reference manual. Rather, I highly prefer looking at and tweaking existing examples, mostly to understand what the typical usage looks like and most importantly where the limitations lie.
I feel like the last point is often overlooked by documentation authors: When evaluating whether to use a library, I'm not just interested in what it can do, but also what it can't do! That's why I really enjoy the "you should use X if you want to do Y"/"you shouldn't use X if you want to do Z" sections present in some manuals.
Re: D3 7.0
#30Earlier quoted context omitted.
> taken neither the time to understand Observable nor D3 and are looking for a way to just copy paste something into their codebase, without understanding it, and without any willingness to really learn the tools they are using. That's how many of us learn, by dipping our toes into a new SDK by copying and pasting into our bare HTML/JS page and tweaking things to see what happens. Eventually we will get around to rea…
You make my point. What better environment to learn and twiddle, than a reactive, constantly reevaluating interactive notebook?
I guess it depends on your goal. If your goal is to learn how to code a nice reactive environment like a notebook is great. If your goal is to learn how to take a library and use it in a piece of software to release to the world, the notebook is next to useless.