🏠 back to Observable

I want to learn D3. I don`t want to learn Observable. Is that ok?

Both D3 and Observablehqcom are excellent product. Thanks to the authors!
I want to learn D3.
However a lot of D3 official examples are coding in Observablehq.com.
I don`t want to learn Observable, because I mainly use D3 for off-line academic Chart.
Could Mike Bostock give every D3 official examples a common Javascribe environment code?
Or ? Forcing everyone who want to learn D3 must learn how to use Observablehq.com first?


Hi there TigerZhao007,

Welcome to Observable. I hope that you find this platform useful and the community welcoming.

I empathize with the difficulties of encountering links to Observable notebooks via blocks.org examples. I too was surprised to find links to ‘standard’ blocks have started to point to Observable, such as with the Sankey, radial stacked bar, and Diamonds II… among others. I also often wish to use visualizations offline, in locally-hosted papers. As shown by my activity on this forum, I’ve encountered a lot of questions and challenges trying to move between Observable and standard / traditional JS.

As a newcomer to JS in general myself, I would encourage you to stick with Observable for a time. Observable’s helped me to understand how pieces of a script play together… to be able to see more clearly which elements can be separated out, which must stay together, etc. Hopefully you’ll also find that your knowledge of D3 will improve more rapidly by tinkering with it in Observable.

Otherwise, except for Mike’s blocks, few (if any) of the bl.ocks.org examples link to Observable. I agree it would be cool of we could also see the original bl.ocks.org examples where they now link to Observable (and maybe Mike can figure out a way to do this), but barring that, there’s still an expansive world of examples online… so hopefully you don’t feel forced into a learning approach that doesn’t fit you.

Sorry if this isn’t much help. The Observable community has been really caring and helpful toward me. I encourage you to ask questions where you do have difficulties. And again - welcome!


Dear aaronkyle, Thanks so much for your reply.
You not only answered my question, but also expressed exactly what i want to say. Thanks again.
And yes, I am a newcomer to JS and my major is not CS or Programmer. So it is a little bit difficult to learn D3 and JS. And it turned out a lot D3 examples are linked to Observable. I was like “What the f***”, confused and helpless.
Thanks for your encouragement, I would stick with Observable for a while and try to understand.


I think you’ll learn d3 faster using observable, than other online sandbox environments out there


It’s important to realize that Observable is just javascript. It’s not magic, it just adds reactivity to the language.

I don’t think the canonical examples of D3 figures here really exploit Observable-specific features very heavily. But if you really want vanilla-only D3 instruction, there’s a lot out there. I’d recommend Interactive Data Visualization for the Web by Scott Murray, which has a free online edition.

1 Like


As we’ve been creating more D3 documentation and examples on observable (and more is coming…), I agree we have to be careful about this issue.

First, note that there is a lot of fantastic learning material out there — in very different forms (blocks, codepens, independent web pages, etc) — and a lot of them are linked from D3’s gallery and READMEs. But many authors are moving to Observable and creating exciting new stuff (testimony to how useful and productive the system is), so it’s unavoidable that more links will be made with these new examples.

Strictly speaking about the series of examples at https://observablehq.com/@d3 that are linked to from the API documentation:

Ideally, one should be able to read them statically (as if in a book), and copy-paste to a web page or a node script without needing too many adaptations.

In general, we’re trying to avoid Observable’s facilities, and prefer e.g. d3.create("svg").attr("width", width).attr("height", height).node() over DOM.svg(width, height) so that the code works almost immediately in the browser or in node.

However, sometimes it would add too much complexity not to use them:
viewof t = slider() might help people mess around with the values more than an editable cell with t = 300. The primary goal is to help people understand what the documented functions do.
— asynchronous loading of data in its own cell is much simpler & easier to understand than promises and callbacks
— using the built-in width to make the notebook responsive
— etc.

A separate issue is that the code in observable is fragmented into independent cells, which makes it difficult to copy / paste all in one swoop. Again, it helps to understand when you’re reading it, but gives you more work when you just want to reuse it. I have no good solution for this at the moment.

Maybe a tool, or a tutorial, could help with the necessary changes — things like replacing require by <script>, using async/await explicitely, etc.

Finally, I agree that it would be great to also have more D3 examples that could be directly usable offline (in node). I certainly learned a lot with d3-geo’s test and bin scripts. But this type of link “Try d3-zoom in your browser.”? — I’m not sure anyone could learn anything from that.


This sounds like a cool idea! A tool would be awesome, but I’m not sure how it could be done. On the tutorial side, maybe something like the “inverse” of this notebook:

These two forum posts of mine come to mind – maybe they’d be useful as case studies.

I also just found this notebook, which goes through the code of a D3 bar chart in 3 different styles (as a single Observable cell, as multiple Observable cells, and as it would be embedded in a standalone HTML page):

(I don’t like the “Chart as a set of expressions” version there though since it doesn’t really play well with Observable’s reactivity.)


Yes, this is a good insight.

There’s friction here in both directions. I often want to take an existing observable cell with a big bunch of code in it and split a few variables out into separate cells to play with them, and I also often want to take a bunch of separate cells and put them into one cell because they are not generally relevant to the whole notebook or I want to duplicate an output cell and tweak the parameters independently in the two copies. It’s not exactly hard to do this manually, but it’s also not instant. I also don’t know exactly how it could/should be improved.

(These actions require more or less the same code transformations as porting external javascript code to notebooks / porting notebooks to plain javascript.)


observablehq is sure a genius project … but I was 100% fully satisfied with plain javascript. I can not do anything with observable. I am here to do and not to observe. D3.JS is so great, a fantastic tool. But whatever observable is usefool for some few, I am sure most of serious coders will blow a fuzz with this non sense. OR OR OR, simply add a raw script to be “observable” with not change, I mean the raw one, the source ready to be tested in plain javascript, raw and immediately useable. That would be great : a great step toward the glory useful past.
THANKS ! :slight_smile:

I can not do anything with observable […] I am sure most of serious coders will blow a fuzz with this non sense […] step toward the glory useful past

I can’t figure out what you are trying to say.

If you want to write javascript code down in a text file and run it in your browser, nobody is stopping you…

1 Like

I’m interested in porting techniques en-masse out of Observable and into Open Source, MIT Licensed plain vanilla JavaScript code, to overcome some of these limitations.

My main concern in doing so is the licencing model of the code content within Observable. My current approach is clean-room reimplementation of everything from scratch, since most of the content in Observable seems to be “unlicensed” (meaning all rights reserved by the author, plus granting Observable users the right to fork & modify the work within Observable but not outside Observable). I’d guess clean-room reimplementation is what companies are doing as well, when they find some cool technique implemented inside Observable and want to use it in their product.

You could always try contacting a notebook author and asking them about licenses.

My impression is that most (but perhaps not all) authors who do not include an explicit license are still intending their code to be freely usable by others, and would be willing to slap an MIT-type license on, offer an explicit license to you, or at least discuss licensing the code.

clean-room reimplementation of everything from scratch

Clean-room re-implementation means that the person doing the re-implementation has never touched or looked at the original code. To do it up to the standards of corporate lawyers my understanding is that you’d want to get one person who looks at a notebook to write a spec, and then someone different (who has never visited the notebook in question, and learns no other information about it) to take that spec and make an implementation from it. Deep pocketed corporations worried about copyright infringement lawsuits but who need to e.g. implement some API for interoperability with some other deep-pocketed corporation’s proprietary product can afford to hire a team of engineers to do this kind of thing, even though it is generally pretty difficult and inefficient.

I am guessing you are not actually doing this.

If you are really worried about liability for copyright infringement then contacting the authors would probably be considerably safer than what I am guessing your current method is. (Disclaimer: I am not a lawyer or an expert in copyright law.)

I’d guess clean-room reimplementation is what companies are doing as well

Anecdotally many companies nowadays are in practice pretty sloppy about copyright infringement, and just copy/paste their way through problems and hope nobody ever notices.