Not sure why this is so contentious. You can search online how many others this impacted as well. All of the modern examples for d3 were rebaked into the observable notebook pattern and it seriously obfuscated how to use d3 itself.
https://github.com/josephg/egwalker-paper/blob/master/diagra...
I didn't try echarts though. I might have to give it a go if its good.
Last time I looked at D3 a half decade or so ago I thought it was an open source lib?
Observable and D3 were created by the same person.
It’s like saying, “I refuse to use PyTorch because their docs are built with mkdocs.”
Moreover, even if the coupling were limiting (which, again, it is not), it’s odd to attack observable since everything they put out is fully open-source. It’s not like they’re hiding docs behind a paywall, they’re actively contributing to the viz ecosystem through basically everything they release (eg Observable Plot, Observable framework).
As far as echarts goes, it’s a great tool. The declarative syntax for charting always feels a bit odd, but it’s easy enough to wrap into component libraries. AFAIK it still powers many of the big BI viz tools used today (eg AWS Quicksight).
You might not notice it if you already know D3 inside and out, but for newcomers, it’s a bit of a turnoff. It’s ok if you like it though!
And no, this isn’t about “blindly copying and pasting.” It’s about people wanting to use D3 without having to learn an entirely different execution environment. That’s a reasonable boundary to set, especially when time and focus are finite.
You can use as many italics as you want but I don’t think it’s a wildly bold claim and your counter example is simply silly.
A few years later, I needed to build a simple novel visualization. A major new version of d3 had come out, and all the examples and documentation got Observable-ified.
Enough time had passed that I could only vaguely recall some of the original concepts, so I set out to re-learn. YMMV but, for me, it was impenetrable. With the limited time I had, I just couldn’t figure out how to untangle d3 from observable. I gave up. Very sad.
I don't understand the relevance of any of this, but I think I've done a fair job outlining my points above. Let me give my best summary: the execution environment used by a library's (example) documentation is independent from learning the API of the library itself. I agree that newcomers to JavaScript may find plenty of confusion there, and I'm sure a decent chunk of D3's users may be new to web-programming in general, but it's not the job of D3 maintainers to account for that.
I actually think our back-and-forth is a perfect example of why open-source is so painful to work on.
D3 is one of the best documented libraries out there is. There are multiple books, hundreds of hours of youtube videos, and most importantly, dedicated maintainers (Mike Bostock, Philippe Riviere, etc.) who've poured hours into additional sources of documentation and are very responsive on GitHub issues.
The unfortunate outcome here is that users have come to expect this sort of high-quality support and documentation (again with the italics, who does this guy think he is???). Every D3 submodule has standard api documentation, sure, but thats expected of all libraries these days. However, the additional example documentation (again, nobody got paid to make this material) for the most recent releases has been migrated from bl.ocks.org (a now defunct open-source service users didn't pay for it) to Observable Notebooks. Now, Observable is a VC-backed business, yes, but the documentation is still completely free. In this thread, you mention you don't like this, so in at least one online conversation where D3 comes up, you actively advocate against using it out of principle! (Couldn't resist!).
Of course this is just my viewpoint on what has transpired, and I'm likely articulating it in a more-inflammatory-than-reality manner. But I'd prefer to have D3 documentation in the form of free, interactive Observable Notebooks rather than to have no documentation at all. Even more so if it helps out the authors of the open-source library.
As a tip for those who have difficulties going from the reactive Observable model to vanilla js -> you can always just take an observable notebook and ask AI to convert it to a set of vanilla files for you.
PS - Sorry for the novel, at an airport!
Wait. This is actually hilarious.
Observable is cool when you want to build data notebooks. Observable is obnoxious if you want to add a D3 pie chart to your Vue application and have to untangle calls to D3’s API from reactive cell values, which look like ordinary JavaScript, but are not, and will cause compilation and runtime errors when copied.
The problem is that D3 resources mix D3 documentation with demos of D3 itself, and demos of Observable, into a single, inseparable combination. Nobody would complain were those three things separate resources; alas, they’re not.
Every time someone raises this issue, they are shot down by people like you, with the same nonsensical argument—just because the maintainers write cool demos in a fringe datavis DSL, that doesn’t automatically mean it’s helpful for the 99% use case of rendering charts in normal apps.
Yep - as I wrote: "If you want to just blindly copy and paste d3 code, you may have issues with the docs being hosted on observable."
If instead you learn the core api (selections, bindings, and update patterns), any chart is really just a matter of using the correct layout/generator.
Here's d3 pie: https://d3js.org/d3-shape/pie
No need for going into Observable at all, as the pie generator is completely documented.
But if, as you mentioned, you prefer to copy the code from Observable, the linked pie example is extremely simple to do so: https://observablehq.com/@d3/donut-chart/2
Zero reactive cells, you can literally just copy the code inside the cell statement (e.g. the curly braces).
Really? They've finally open-sourced the notebook editor? I can't find it on their GitHub. The long-proprietary notebook editor is a big part of people's objections to Observable.
They didn't because it's literally their core business.