D3 6.0
github.com
github.com
It seems like the main learning curve for learning D3 is deeply understanding the underlying web technologies (looking at you SVG), so could something D3-like have a more abstracted renderer?
Anyway, once you use Observable - Jupyter notebooks are forever ruined, which is the highest praise I can give. Thanks for all your hard work Mike!
[0] https://observablehq.com/@unkleho/introducing-d3-render-trul...
Front page of the website doesn't seem to work on the latest Chrome (version 85.0.4183.83 (Official Build) (64-bit)) on macOS.
Oops, an unexpected error occurred.
https://github.com/timwis/vizwit/blob/v2/src/components/char...
Then I read some blog post somewhere. I wish I could give that author the credit they deserved. It explained the fundamental building blocks of d3, the selection APIs, etc with such clarity.
Once the light bulb went off, I was able to quickly iterate on some pretty awesome totally custom stuff quickly and have sung d3’s praises ever since (it’s been 5 years).
> I wish I could give that author the credit they deserved.
My overall point is that if you are struggling with d3, take a step back and really try to understand the conceptual building blocks. It'll make a world of difference.
https://bost.ocks.org/mike/join/ https://observablehq.com/@d3/selection-join
There’s also a book I read while ago from Swizec Teller on d3 + react integration[0]. It may be dated by now as it’s been some time since I last read it, but it’s worth looking into!
also, hey :)
Mike Bostock will be doing an AMA at the end if you have burning d3v6 questions (though you can expect some more documentation on upgrading to come very soon!)
I'll also plug our other two speakers, Mike Freeman and Amelia Wattenberger who are amazing d3 educators & authors.
It's exciting that this is the first big online d3 meetup since the pandemic put a stop to in-person events, and as a consequence of being online anyone can participate!
Will the talk be recorded and hosted anywhere?
[1] https://vega.github.io/ [2] https://altair-viz.github.io/ [3] https://vega.github.io/vega/about/vega-and-d3/
With many higher level interfaces, things go great until I eventually run into a situation where I would like to do a tiny tweak that would improve readability a lot, and it turns out the higher level interface does not support that, so I'm out of luck.
That said, I haven't tried Vega. What are your experiences in terms of that problem with Vega?
Mike had such cool and colorful ideas for the web 8 years ago which still wow supporters of any project. But I have had to spend significant time and money updating things to work with Vue or React while simultaneously trying to figure out what changed across versions of D3 while simultaneously trying to figure out what the inherited version of D3 was even doing.
Mike seems to have opted for more practical designs in the latter half of the decade in his exploration of data visualizations. While other contributors lack inspiration of using this as an art form.
We’re still in the process of republishing some of them and were hoping to announce tomorrow but it looks like someone noticed and here we are on HN.
Why ES2015 specifically? Like where are the compatibility issues or is this a necessary upgrade path for older versions and then you’ll phase into es6 or leapfrog that to something even newer?
Or if ES2015 is “good enough”? Javascript can be a hot mess, there isn’t always a need to keep up and the troubles arise when you try to.
This and other compatibility charts shows only Internet Explorer continuing to be the bane of your existence.
Edit: it’s modular but the modules I peeked at have sideEffects set and look pretty clean. I’m excited to see what I can do and keep tiny bundles! (I’m obsessed lately with making neat gadgets that load instantly)
We didn’t get around to it for 6.0 (mostly for fear of breaking backwards-compatibility in Node), but we plan on adopting type: "module" for Node in the nearish future. In the meantime you can consume D3 as an ES module using Skypack if desired. https://cdn.skypack.dev/d3
It's basically impossible to get started with D3 without using the Observable online playground, I find it so frustrating.
Similar frustations are aired in a forum post: "I want to learn D3. I don`t want to learn Observable. Is that ok?" [5].
[1]: https://observablehq.com/@d3/learn-d3 [2]: https://observablehq.com/@d3/gallery [3]: https://d3js.org/ [4]: https://github.com/d3/d3/wiki [5]: https://talk.observablehq.com/t/i-want-to-learn-d3-i-don-t-w...
The fact that they’ve made the effort to add a playground by leveraging a fairly easy to use tech should not be held against the open source maintainers!
Besides, all those examples are trivially reproducible locally, the way you would have to do it for the vast majority of languages which don’t give such fancy interactivity in their tutorials.
Or maybe it is simple but it's not intuitive unless you are familiar with Observable. So perhaps the solution is to have a page that describes how to move the examples from Observable to an HTML page? eg. where to put the scripts and where to put the HTML.
1. There are multiple online/physical books about D3, online tutorials/courses on YouTube/udemy/etc., blog-posts, blockbuilder.org (deprecated but still useful), and the d3 documentation itself, all of which aren’t tied to observable.
2. I do agree that observable is a bit difficult to use when you first try it, but if the issue is porting a d3 example to an index.html, you need only remove a few lines of observable scaffolding to do so. This is a far cry from, “basically impossible.”
I know it's hard to refute your first point as you could point to any example, but if I'm just trying to follow the happy, well-trodden path it's hard.
Eg. I go to D3 website [1], I click "documentation" link [2] in header which takes me to the Github, I click the first link "introduction" and the page is actually hosted on Observable [3].
If I click on the "examples" link on the Github or website...it takes me back to observable.org gallery!! [4]
This forum thread (on Observable) summarised exactly what I was thinking: "I want to learn D3. I don`t want to learn Observable. Is that ok?" [5]
One person asks "Why can we not simply download vanilla code examples without any “Observableness” in them?"
The reply by Mike is dismissive of their viewpoint and basically says learning D3 outside of Observable isn't supported:
> We recognize that this is a change and a disruption: a new thing to learn. And we need to do a better job of helping you learn Observable (and explaining why you should bother).
> Yet despite our shortcomings, we fundamentally believe that Observable is a better way to code 2: easier to understand, easier to tinker, easier to adapt and reuse, easier to collaborate and share.
Maybe basically impossible isn't the right description, but they don't make it easy to get started without using Observable.
On your second point, here is a HN discussion [6] on why Observable isn't JS. Observable has a _whole standard library_ [7]. Porting from Observable to vanilla JS is not just "removing a few lines of observable scaffolding".
[1]: https://d3js.org/ [2]: https://github.com/d3/d3/wiki [3]: https://observablehq.com/@d3/learn-d3 [4]: https://observablehq.com/@d3/gallery [5]: https://talk.observablehq.com/t/i-want-to-learn-d3-i-don-t-w... [6]: https://news.ycombinator.com/item?id=20184181 [7]: https://github.com/observablehq/stdlib/blob/master/README.md
Let’s be clear, D3 is an open-source library. In no way, shape, or form is Mike required to support and produce tutorials for the language. The fact that what he has been kind enough to produce was done so using Observable has no bearing on your issue of “getting started with D3” when non-Observable tutorials abound. If you just google “D3 tutorial” you’ll see that all links but one point to non-Observable resources.[0]
The article in Point 2 is a great one, but I'm not sure why you're linking it here. The implementation details are wholly unrelated to a) our discussion and b) whether or not it’s easy to port example D3 code to vanilla.js. It’s like someone arguing that porting Jupyter notebooks to Python scripts (something fairly chill to do) is difficult because of some unrelated implementation detail in Jupyter’s core code - the detail is irrelevant.
To make sure I’m not just talking out of my ass, I just went through a few of the initial "learn D3 Observable" Google results that came up, and in literally all of them all you need to do is 1. remove any enclosing brackets (if they exist) and remove 2. remove calls to svg.node() and boom - you can paste everything into a script tag.
Is that obvious to someone who doesn’t know D3 or Observable? Honestly, probably not. It can be clearer and I agree it should be spelled out somewhere (if it is, I don’t see it).
Is it obvious to someone who writes JavaScript for a living? Shouldn’t be too hard to figure out in the context of what is a literal tutorial.
Does the Observable environment make learning D3 difficult to learn? They’re fundamentally unrelated to the D3 concepts, so no.
And finally, if you (understandably) find the concepts of D3 to be confusing, especially when presented via Observable, should you complain that it’s basically impossible to learn because the author (the same dude who wrote and continues to update the library for free) chooses to host his examples using unrelated software he also helped author? No, probably not. Unless you want to contribute (get it!?) to the worst bit of open-source: complaining.
I agree that an open source project does not owe anyone detailed tutorials in their preferred format.
I'll consider contributing to a vanilla JS D3 tutorial in future.
It simply is not “tightly coupled”. It is very straightforward to get started without using Observable.
Observable does exist, it is related to D3. It is “loosely coupled” in metaphorical terms because there are no dependencies in the code.
It seems like a useful tool. Is the nature of your complaint that the team provided a learning environment alongside D3? That they recommend their learning & collaboration platform as well as their vis library?
These strike me as good things to do. I’ve certainly thought of other people’s Observables as valuable resources.
The only tutorial that doesn't do this and that "gets" it is one by Amelia Wattenberger: https://wattenberger.com/blog/react-and-d3. I recommend this tutorial to understand how to use D3 in React.
So yeah at the D3 level you would just draw one chart and then draw another chart on top, probably each wrapped in a <g> if you’re using SVG. Maybe they’d share X/Y scales.
You can use that same scale to draw just one set of axis.
Need multiple Y axis? Create two Y scales with the same range, one X scale.
Also I think it's good to understand that "chart" is not really a concept in D3. You just get all the elements of a chart which is why it is so awesome as you get to compose your own chart just the way you like it!
Is there anything in it that is now outdated?
It would be nice to mention the D3 version targeted in the very first paragraph.
Let's share our creations here!
Here's mine: a tech tree using D3.js made many years ago: https://github.com/ldd/tech-tree-js
On a different note, hoping the CORS issued I received when using a v6 version d3-fetch with local files got updated
If you think you’ve found a bug please file an issue on GitHub. (That said, d3-fetch is just a trivial wrapper on the native Fetch API, so any CORS error there is probably expected.)
The biggest pain point I have coming back to it - esp after a release or two - are the scope of the changes!!
Many methods and properties have changed thus most of the examples, blog posts, and stackoverflow assistance are outdated so it generally takes much longer than I had hoped - but the results are always worth it.
Is this impression correct? Is there a way around this? A learning source that covers both?
So why should something happening in another tab be allowed to mess anything up? (Not that there is anything.)
No, sir, I didn't like it.