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

[TigerZhao007]

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?

[aaronkyle]

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!

[TigerZhao007]

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.

[bumbeishvili]

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

[shastabolicious]

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.

[Fil]

Hello!

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.

[bgchen]

@Fil

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

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:

Learning from D3 in Action - in Observable

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):

Observable vs Regular Flavor Javascript

(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.)

[jrus]

@Fil

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.

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.)

[aie]

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 !

[jrus]

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…

[cladelpino]

Well… I agree with the original poster (this frustration lead me to this thread as the first search result) so to put it other words what is being said through an example… currently the new tutorial of d3.js begins with a feature unique to observable javascript…

All I was looking from a “getting started” tutorial was how to create a d3 element in a web page… Which is specifically not covered…

@Fil

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.

This seems not to be the case… import {chart as temperatureHistogram} with {temperatures as data, height} from “@d3/histogram”

So anyway, I wrote this just to let you know that probably many people who already know what
interactive data visualization means and have already developed websites will experience the kind of feelings expressed in this thread.

[muhmud]

I’ve created an account just to express my frustration over this.

Why can we not simply download vanilla code examples without any “Observableness” in them?

Is that really too much to ask?

[mbostock]

@muhmud

Why can we not simply download vanilla code examples without any “Observableness” in them?

Observable notebooks are like spreadsheets, where cells run automatically whenever you edit or values change. That’s not how conventional (imperative) programming languages work, so sadly you can’t simply copy-paste a whole notebook into a vanilla JavaScript application.

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: easier to understand, easier to tinker, easier to adapt and reuse, easier to collaborate and share.

You can download the vanilla JavaScript for any notebook by clicking Download Code in the notebook menu. (See Downloading and Embedding for details.) This code can be self-hosted so you can run whatever you create in Observable anywhere. And our embeds are much more powerful than iframes, allowing deep integration (e.g., with React). We’re making this easier; see Jeremy’s Handy Embed Code Generator for a start. This transpiled code isn’t intended to be edited directly; we recommend you edit on Observable.

As to the broader question of why go to the trouble to introduce a new language, a live editor, and a collaboration platform to accompany it: our goal is to help people help each other. We want to foster collaboration and creativity. For this to succeed, code must become more approachable, which means breaking a few eggs. There’s an incredible community of people on Observable that can help you (through comments and suggestions) and a wealth of techniques to learn from and reuse (through forks and imports). With the Observable community, the D3 examples can be so much better than what I could ever make on my own.

[muhmud]

Thanks for taking the time to provide a detailed reply.

This is why I still think this is an issue: choice

It may really be the case that Observable is the next big thing but, as it stands, I am not given any alternative when I come here from the d3 site, for example, apart from going elsewhere. I already tried using the Download Code feature, however, Observable is still within the code that you get. In order to do what I needed to, which was present a very quick demo of what we could do with d3 using our data, I had to spend much longer on it than I originally thought I would need.

Now, you could probably argue that I could have done my demo using Observable and it would be easier, quicker, and more malleable, but as the OP says in the title of the post here, what if I don’t want to right now? Instead of using Observable as something I depend on for delivering my code, what if instead I wanted to sandbox some ideas and then move to using straight JS code? There are a multitude of reasons why people would not want to change up everything they’re doing today.

In my opinion not having an option to export an Observable notebook as regular code is severely limiting, and think I might have actually used it if it had this functionality. Without it, I’ve got a hell of a lot of buy in. For my demo, I ended up hacking around the d3 code from here to get what I wanted to work, which led to frustration and a desire for things to go back to how they used to be with the d3 example code.

Thanks,

Muhmud.

[KobyO]

I greatly admire the Observable team and all the amazing work being done here, but I couldn’t agree more with @muhmud! Like many others, I found myself on this thread as a result of a lot of frustration.

I agree that Observable may be the way to go, and I do agree with a lot of the advantages being presented - but the problem is (and I think I see many others expressing similar views): why, oh why, can’t we have the copies of the ‘regular’ code that we are used to, in addition to the observable versions? I think that being able to compare old with new would drastically ease the learning process for so many people. Of course after Observable becomes more mainstream and understood, the old code can be removed. As it stands right now, I feel like I would have to suspend a lot of my work in order to fully dive into and embrace Observable - unfortunately that is just not an option for many programmers like myself.

If there is a reason why the Observable team does not want to provide ‘regular’ code with Observable code, it would be great to know what the reason is - part of the frustration comes from feeling that this is such a small ask, and yet we’re not getting it.

Thanks again for the awesome work.

[mbostock]

@KobyO

If there is a reason why the Observable team does not want to provide ‘regular’ code with Observable code, it would be great to know what the reason is - part of the frustration comes from feeling that this is such a small ask, and yet we’re not getting it.

Maintaining two parallel sets of examples, one Observable and one vanilla, is no small task. The D3 examples represent thousands of hours of work (418 notebooks on Observable and counting), and over the last few years we’ve committed to Observable because we think the examples will be better the community’s help and it’s a better way to learn D3.

There are plenty of vanilla D3 examples available on the web, such as the D3 Graph Gallery, and resources for using D3 with other frameworks, such as Amelia Wattenberger’s Fullstack D3 and Data Visualization. But these aren’t maintained by the D3 team as we are focusing our efforts on supporting the community at Observable.

[KobyO]

Thank you very much, I appreciate the explanation.

But is it possible to leave the bl.ocks.org vanilla examples up after they are ported to Observable (with the caveat that they are no longer maintained and may even be slightly different from the new sample)? While it is true that there are many other D3 examples on the web, the bl.ocks.org examples that have been removed are the closest thing to the new Observable samples that we can use as a reference for understanding the transition.

[HarryStevens]

All the blocks with D3 examples still exist as gists. If you find yourself trying to look at a block but being redirected to an Observable notebook, you can replace bl.ocks.org with gist.github.com in the example’s url. Then you can clone or download the gist and open it up locally.

[KobyO]

Thank you very much, I did not know that - this is very helpful information.