I just wish all the cool animated examples of D3 were updated to use the latest version of the library.
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.
Good to see you here today, and glad to know that.
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.
Collections (Map and Set) and iterables; the latter practically requires for-of syntax and so can’t be supported in older browsers. d3.group and d3.rollup are much more enjoyable to use than d3.nest.
IE11 is still widely supported across a lot of the industry. It's use is declining, but I suspect it'll be a a good while yet before it disappears because there are still so many IE-only internal apps.
Does the full adoption of ES6 modules result in trivial tree shaking? I’ve found that’s one of my favourite effects of libraries adopting the newer module styles
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)
D3 has been written in ES modules since the beginning of 2016 when we adopted Rollup for bundling. The difference now is that we’re adopting ES2015 language features that can’t be transpiled (namely for-of).
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
Conversely, I just use a code editor, a web browser, and the refresh button. I've never felt the need to use something like ObservableHQ, before and after it came into being.
Both the introduction link [1] and examples link [2] on the D3 homepage [3] and Github [4] only shows sketches on Observable - is there any official D3 getting started documentation not on Observable?
Similar frustations are aired in a forum post: "I want to learn D3. I don`t want to learn Observable. Is that ok?" [5].
The vast majority of library documentation of even major libraries is simply text with no playground.
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.
I am a fan of D3 and Mike but I also agree with the point - it's not at all simple to take the examples from Observable and implement them in a non-Observable page.
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".
You admitted your original, “learning D3 without observable is basically impossible” was overblown, but follow up with, “Mike is dismissive... and learning D3 outside of Observable isn’t supported”.
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.
D3 was around for years before Observable, there’s plenty of books and tutorials around that don’t use Observable, it’s an open source library that doesn’t need Observable, and there must be plenty of people like me using D3 in production code today that didn’t learn it using Observable.
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.
Thanks. Philippe Rivière has been helping substantially and making amazing contributions!
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 changes between v4 and v5 are tiny (adopting promises in d3-fetch instead of callbacks). The changes between v5 and v6 are also largely backwards-compatible, so hopefully your upgrade will be painless. A migration guide is here: https://observablehq.com/d/f91cccf0cad5e9cb
Official docs and examples with an objective of simple visualization you want to build. You can get through simple timeseries and bar charts with it in 4h. Worked for me, N=1
I've always been curious on what Mike would do if he could completely rewrite D3. I saw some experiments with a declarative API [0] which seems really interesting.
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!
While learning D3 I was stuck on a simple bar chart problem. Just could not figure it out. Asked on the D3 slack. None other than Mike himself took the time to look at my code and point out the error. Then he gave me some general tips that he noticed. The guy is so generous with his time and expertise and I admire him a great deal.
Actually you can use d3's maths functions standalone and then use react or vue's declarative templating to render. It's not too dissimilar from what you'd have to know using d3 DSL directly. Here's an example:
As a former Protovis user whose mouth hit the floor the day he discovered D3, I never cease to be amazed at the quality of work Mike does. Thanks, Mike!
Sankey diagrams are still blowing enterprise minds in 2020. I don't know what award it would be, but it should be important, and the author should get it.
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!
The first few days I used d3, I really struggled. And I got very frustrated. I simply couldn’t understand why the library was so popular. But I powered through because people whose thought patterns I respected, swore by it.
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).
yes, i gathered as much. they showed enough desire to give credit and enough interest and skill in the matter that i find it hopeful they could find it again if they sought it out.
Sorry I don't even remember what it looked like. But the guide from @wattenberger is in the same vain. It might have been it :-)
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.
The data join thing is interesting. I'd be curious about other future opportunities for d3 to sync up more with react. Posts like this [0] show that d3 can "just generate the path" and then at that point you can use different renderers like React e.g. return <path d={line(data)}/>. It is more limited doing it this way but more ties into the react model would be wonderful
I don’t have any public codebase examples at hand, but what we’ve done at work also works quite well: basically we implement our D3 charts as a class with methods corresponding to desired lifecycle events. We then create a Component wrapper around said class and call the methods during their corresponding lifecycle events. (Idk how confusing or not that was but I wish I had a repo to share to make it clearer).
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!
i can confirm that i dreadfully wished for something like this when i muddled through the freecodecamp d3 curriculum in 2017! it was especially confusing as everyone was switching from v3 to v4 right then.
I use d3 in my map generator app. I’ll look into this update to add and rewrite some of the features. Labels have been an issue lingering around for too long.
It seems like a very versatile framework, but nowhere I can find any recipe or guide of a very simple case - how to combine different types of charts in one? Like simple line chart overlaying the bar chart. It seems to be only possible by rendering them as completely separate charts and then overlaying one on top of each other in DOM? Which seems hacky.
Can’t you just add both the bars and the path to the SVG you’re rendering to? (I assume it’s the same for a canvas context, although I’ve never used one with d3.)
D3 is pretty low level - geometry and binding data to create DOM elements. It’s not really a charting library - look for libraries built on top of it for abstractions like “composite chart” or whatever.
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.
Look into scales, you can put whatever you want in the same chart by positioning it using the same scales. https://github.com/d3/d3-scale
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!
Which wrapper library around d3 that's declarative would people recommend? I'm thinking something where I can swap the state in React between renders and it updates intelligently with animations etc.
Just use d3 directly in react, rendering svg is ok for most cases. You would want to ignore all the dom manipulation parts of d3, but otherwise they work well together.
Indeed. When you Google for "React/Vue/Ember D3", the tutorials always use the DOM manipulation layer of D3. But every front-end framework already comes with a great reactive system to ensure the DOM is in sync with the data. And those are a lot easier to use than D3's in my opinion.
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.
Just won't render, at all, for me. Lotta "Notebook not responding. There may be an infinite loop that has crashed this notebook, or a notebook open in another tab.".
So why should something happening in another tab be allowed to mess anything up? (Not that there is anything.)
I love D3, have been using it on and off for years.
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.
For those looking for higher level interfaces for interactive visualization via D3, check out Vega/Vega-Lite [1] and Altair [2] (a Python library based on Vega-Lite).
D3 started out as an academic project and Vega/Vega-Lite come from the same lab. Also, while Vega does not generate D3 code (Vega is a declarative visualization language and reactive runtime), it uses the D3 libraries internally and is heavily inspired by some of the core principles (e.g. data join).
One of the things I really like about D3 is how there's nothing it won't do, precisely because it's a lower level interface.
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?
I think they serve different use cases. I love Vega-lite for exploratory analysis and for quick prototyping. You can get fantastically complex visualisations very quickly with it. But for building "production" visualisations, I think the low level approach is better: you'll get much smaller bundle sizes, you have much more control over the final look and that control tends to be expressed "naturally" rather than in convoluted configuration.
I would not even touch vega, it’s the engine vega lite is built on. Vega lite is a declarative json format for representing charts. The spec is very well thought out and you can rapidly iterate on prototypes. Altair is a python wrapper for vega lite
+1. It's amazing what you can do with Vega(Lite) and/or Altair in little time. But once you want to build something that performs on the web you really need to rewrite things using another library, like D3.
I love D3. I tried plenty of other higher level libraries but very quickly you run into customization issues. So for Backtest (https://backtest.curvo.eu/), I moved all the charts to D3. It's a bit lower level and was more work to set up initially, but now I'm in full control and can easily extend any chart. D3 is a great piece of software!
For me, a data scientist, learning D3 feels so far off since the background needed to learn it seems vastly connected with some notion of frontend concepts, which for me are very foreign. And honestly, I don't care much about UI programming.
Is this impression correct? Is there a way around this? A learning source that covers both?
89 comments
[ 248 ms ] story [ 1918 ms ] threadMike 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.
https://kangax.github.io/compat-table/es6/
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.
[0] http://letmegooglethat.com/?q=D3+tutorial
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.
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.)
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
Is there anything in it that is now outdated?
It would be nice to mention the D3 version targeted in the very first paragraph.
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...
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?
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
https://observablehq.com/@d3/d3-line
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!
[0] https://leanpub.com/reactd3jses6
https://wattenberger.com/blog/d3
also, hey :)
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!
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 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.
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.
[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?
Is this impression correct? Is there a way around this? A learning source that covers both?