| |
| ▲ | infecto 11 days ago | parent | next [-] | | I refuse to use it out of principle that they have intertwined it with observable. All the modern docs for d3 assume you are using observable. So unless you are relying entirely on AI it’s now even harder to grok the documentation. 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. | | |
| ▲ | dleeftink 11 days ago | parent | next [-] | | There's Plot, which is as standalone as anything[0]. That said, I still find D3 unparalleled in depth and scope. [0]: https://github.com/observablehq/plot | | |
| ▲ | josephg 10 days ago | parent [-] | | I used Plot for an academic paper I wrote recently. It was the only charting library that I found that let me generate the charts I wanted to draw - which in my case was a grouped bar chart with a logarithmic scale. Ie: 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. | | |
| ▲ | shiandow 10 days ago | parent [-] | | I reckon you can get something quite similar with matplotlib without too much trouble, though that strongly depends on how comfortable or familiar you are with it. |
|
| |
| ▲ | kowlo 11 days ago | parent | prev | next [-] | | It's a shame - and I'm not sure why they did it other than to use D3.js' popularity promote Observable. | |
| ▲ | the_real_cher 10 days ago | parent | prev | next [-] | | When did Observable get their hands on D3? Last time I looked at D3 a half decade or so ago I thought it was an open source lib? | | |
| ▲ | infecto 10 days ago | parent | next [-] | | Past few years but I don’t have a timeline handy. I am probably ignoring important details but Mike Bostock cofounded observable maybe 4-5 years ago? So for all intents and purposes they have always been the same crew but they made a conscious decision to tightly intertwine d3 docs with observable notebooks. | |
| ▲ | gaws 7 days ago | parent | prev [-] | | > When did Observable get their hands on D3? Observable and D3 were created by the same person. |
| |
| ▲ | jwilber 11 days ago | parent | prev [-] | | This is a very bizarre take. If you want to just blindly copy and paste d3 code, you may have issues with the docs being hosted on observable. But absolutely zero part of the d3 api (or core design patterns of use) have anything to do with observable. 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). | | |
| ▲ | infecto 11 days ago | parent | next [-] | | Look, it’s not “bizarre” to point out that Observable has deeply shaped the modern D3 ecosystem. The issue isn’t that the D3 API has changed, it’s that a huge number of learning resources, examples, and docs have been rebaked into Observable’s reactive notebook style, which, for people not using Observable, adds a ton of indirection and mental overhead. 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. | | |
| ▲ | abtinf 11 days ago | parent | next [-] | | Pre-observable, I used d3 to develop a very complex visualization with real-time updates. It was difficult because d3 has a lot well-thought-out-but-complex concepts, but the docs and examples helped me fully understand how it worked, and the result turned out spectacular. 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. | | |
| ▲ | edoceo 10 days ago | parent [-] | | Same story here, landed on Apache Echart (it seems, like many others) |
| |
| ▲ | WuxiFingerHold 10 days ago | parent | prev | next [-] | | I'm an experienced dev and looked seriously into D3 some month ago for the first time. I can confirm what you wrote. The notebooks feel like an unnecessary hurdle. It's not a big hurdle, but one that could be avoided so a slightly annoying experience. | |
| ▲ | jwilber 11 days ago | parent | prev | next [-] | | "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." 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! | | |
| ▲ | infecto 11 days ago | parent | next [-] | | Appreciate the lengthy response, but I want to clarify a few things since I think my original point keeps getting mischaracterized. First, the italics. You opened with “This is a very bizarre take”—emphasis on very—which, whether you intended it or not, sets a smug tone. It’s the kind of rhetorical move that shuts down discussion before it starts. I’m not saying this to nitpick style, but to point out how quickly this moved from a discussion about tooling to a dismissal of my viewpoint. It is an easy tell the person writing gives away when they use it like you do. Now, to the substance: yes, the D3 API is technically independent of Observable. But in practice, Observable is now the primary medium through which new users encounter and learn D3. The official examples, new documentation, and most teaching material are embedded in the Observable environment, which introduces its own model of reactivity, syntax, and execution. That’s not a minor detail, it’s a real obstacle for people who just want to understand and use D3 in plain JavaScript. Your PyTorch/mkdocs analogy completely misses the mark. Mkdocs is a static site generator. It doesn’t change the code you’re learning—Observable, on the other hand, does. You can’t meaningfully learn D3 from many of these new examples without understanding how Observable cells work. That’s a tight coupling, and one I don’t think should be hand-waved away. “Just use AI to convert the notebook” is a non-answer. It assumes everyone is okay with outsourcing understanding to a black box just to get a usable snippet. That’s exactly the kind of indirection I’m objecting to in the first place. Lastly, yes, I’ve set a personal boundary: I don’t want to buy into an ecosystem that made a choice I don’t support. That’s not a call to boycott, it’s just me saying, this direction doesn’t work for me. If that’s enough to dismiss my view as bizarre, then I’m not sure what kind of discussion is even possible here. | | |
| ▲ | boomskats 11 days ago | parent [-] | | Entirely unrelated, but I've not heard anyone describe it as `outsourcing understanding` until now. That's a great phrase. |
| |
| ▲ | kowlo 11 days ago | parent | prev | next [-] | | > you can always just take an observable notebook and ask AI to convert it to a set of vanilla files for you. D3.js docs used to be fine. Now you need to "ask AI" to untangle them? | |
| ▲ | listenallyall 10 days ago | parent | prev [-] | | > But I'd prefer to have D3 documentation in the form of free, interactive Observable Notebooks rather than to have no documentation at all This is the core point. Yes of course the existing d3js docs are better than nothing. That isn't the complaint. The complaint is the current docs are significantly worse than older d3js docs that weren't notebook-based. | | |
| ▲ | jwilber 9 days ago | parent [-] | | Can you provide an example? I’ve been using d3 on-and-off for almost 10 years, and the core docs have just gone from README’s to static-hosted pages with the same (version-specific) content (eg https://d3js.org/d3-selection/selecting). What is significantly worse here between the two? To my eyes, they’re basically identical: https://github.com/d3/d3-selection/tree/86 My best guess is that you’re referring to bl.ocks.org, which hosted d3 examples as standalone html examples, but this was independent from the d3 docs. | | |
| ▲ | infecto 8 days ago | parent [-] | | The issue isn’t that the API documentation has disappeared, it’s that the learning experience for newcomers has degraded. The Observable-first direction has made it significantly harder for new users to grok D3 without buying into an entirely new runtime and mental model. Yes, the docs are technically still there, but they’re increasingly fragmented, and many examples now assume you’re using Observable or some variation of its reactive notebook model. Bl.ocks.org wasn’t officially part of the D3 docs, but it played a critical role: it was the on-ramp. People learned by tweaking examples, not by reading method signatures in isolation. Saying people just want to “copy-paste” kind of misses the point, examples are how many developers build actual understanding. They’re not just blindly pasting code; they’re reverse-engineering patterns, figuring out how the pieces fit together. We get it — you enjoy the library. But many users don’t appreciate the direction it’s taken. Such a bizarre defense. I guess we are not supposed to look at the examples when trying to grok a new library, especially a library for chart visualizations which is historically not known to be the easiest to work with. |
|
|
| |
| ▲ | gaws 7 days ago | parent | prev [-] | | > You can use as many italics as you want Wait. This is actually hilarious. |
| |
| ▲ | 9dev 11 days ago | parent | prev | next [-] | | Ah, the good old "you’re not allowed to criticise open source projects, because they’re open source!" 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. | | |
| ▲ | jwilber 9 days ago | parent [-] | | "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." 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). |
| |
| ▲ | mkl 11 days ago | parent | prev [-] | | > it’s odd to attack observable since everything they put out is fully open-source 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. | | |
| ▲ | gaws 7 days ago | parent [-] | | > They've finally open-sourced the notebook editor? They didn't because it's literally their core business. |
|
|
| |
| ▲ | rorylaitila 11 days ago | parent | prev | next [-] | | We needed charting for ad-hoc business reporting from SQL. ECharts was at the right level of ease of use and available charts, interactive, and looks great right out of the box. | |
| ▲ | kowlo 11 days ago | parent | prev | next [-] | | Not touching D3.js since Observable. | |
| ▲ | smelendez 10 days ago | parent | prev | next [-] | | Depends on the use case. If you’re a data viz team and do this all the time, and everyone knows or is willing to learn D3, then sure. Otherwise, if you just need to add a graph to your website, you may find it slows you down and makes code less maintainable. I personally find it confusing and as others mentioned I can forget how it works over time, though I admire it. I don’t think I could jump in and edit D3 code today without careful study, any more than I could jump in and edit Perl code. Echarts/Highcharts etc. are much more intuitive. | |
| ▲ | 10 days ago | parent | prev | next [-] | | [deleted] | |
| ▲ | ActVen 11 days ago | parent | prev [-] | | I used to love using it. But, all of my coworkers hated it. I haven't revisited since the AI boom. Maybe it will have a bit of a comeback. Many people found it too difficult. |
|