Live data from Hacker News

D3 7.0

github.com

1–10 of 65 posts

Re: D3 7.0

#4
Exciting to see ESM everywhere. It works so well with Observable. I'm trying to put live playgrounds at observable for my packages as part of docs [0] - just starting, nothing exciting to see there yet, but I think the concept of playground as part of docs is quite awesome.

[0] https://observablehq.com/@mirek/tsql-examples

Re: D3 7.0

#5
> Adopt type: module. #3501

Standard JS modules, very nice! D3 now works in all playgrounds and libraries even as dependencies without non-standard tooling!

https://jsbin.com/ducosajehi/edit?html,output

I do wish they didn't even publish UMD, that's a recipe for duplication if some libraries import the module and some import the UMD.

Re: D3 7.0

#7
The one critique I have of D3 is that it is becoming increasingly closely paired with Observable, such that when I'm searching for examples of how to make something in d3, I can only find Observable examples that require the Observable runtime in order to function properly.

I think the examples should have a JS native version in addition to the Observable implementation.

Re: D3 7.0

#8

The one critique I have of D3 is that it is becoming increasingly closely paired with Observable, such that when I'm searching for examples of how to make something in d3, I can only find Observable examples that require the Observable runtime in order to function properly. I think the examples should have a JS native version in addition to the Observable implementation.

That's a bit like complaining that there are examples on codepen.

I'm super grateful that they provide such good documentation, which is second to none, in a nicely explorable environment.

Re: D3 7.0

#9
post #8

The one critique I have of D3 is that it is becoming increasingly closely paired with Observable, such that when I'm searching for examples of how to make something in d3, I can only find Observable examples that require the Observable runtime in order to function properly. I think the examples should have a JS native version in addition to the Observable implementation.

That's a bit like complaining that there are examples on codepen. I'm super grateful that they provide such good documentation, which is second to none, in a nicely explorable environment.

The difference is that examples in Codepen are easily reproducable in another environment.

d3, on the other hand, has converted most of their examples to Observable, which requires extensive research to convert back to JS (in the best case) and in the worst case requires reverse engineering the runtime.

I'm not the only one with this opinion, there are plenty of others who have struggled through similar issues and discussed it.

"The process of converting an Observable notebook to standalone html and/or js is clearly not as simple and copying and pasting. The use of Observable notebooks for all D3 examples has made the introduction to the library much more challenging for this reason." [0]

[0] https://stackoverflow.com/questions/53155957/convert-d3-obse...

[1]: https://talk.observablehq.com/t/i-want-to-learn-d3-i-don-t-w...

Re: D3 7.0

#10

The one critique I have of D3 is that it is becoming increasingly closely paired with Observable, such that when I'm searching for examples of how to make something in d3, I can only find Observable examples that require the Observable runtime in order to function properly. I think the examples should have a JS native version in addition to the Observable implementation.

It's a real pain. I work with lots of "data science" types who are often trying to concurrently learn JavaScript and d3 - often with JS as their first or second programming language. It's difficult enough for an experienced programmer coming back to d3 after a few versions to pick out what's d3 vs. what's Observable - and very difficult to help a relative newbie through the process of turning what's shown in an Observable notebook into something that can run in an ordinary web page.
Post reply on HN