Our great sponsors
-
hal9ai
Discontinued Hal9 — Data apps powered by code and LLMs [Moved to: https://github.com/hal9ai/hal9]
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
svg-line-chart
Discontinued Tired of 200kb charting browser libs? ...I feel ya. Come to the server-side!
I sympathize with the comments, as a software engineer, this comment from Mike really describes my frustration with Observable's runtime:
> 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.
However, I do think many others will prefer their reactive runtime; so this is by no means a criticism to Observable, they are doing great work. They are just not targeting JS-purists and that might be the right call.
As a software engineer, I love D3 but don't want to be stuck with a reactive runtime that is not vanilla JavaScript.
I got myself to build https://hal9.ai, an integrated environment to do data analysis based of JavaScript. Is not a D3 learning environment but you can certainly use it for that purpose. If someone is interested in providing feedback or helping with D3 examples, please do so at https://github.com/hal9ai/hal9ai or shoot me an email at javier at hal9.ai
'D3 for the impatient' is indeed an excellent book and was my entry point into D3, but I think you may be incorrect regarding its version compatibility. See the author's github repository here:
https://github.com/janert/d3-for-the-impatient
> All examples have been verified to work with this version of the D3 library (D3 Version _5.9.2_, downloaded 15. Apr 2019)
As someone building an in-browser notebook I have a lot of opinions on notebook environments. Notebooks serve different purposes, sometimes the notebook itself is the end-goal because the author is creating an interactive tutorial or explaining a complex concept with a bunch of visualizations. Observable is a fantastic tool for that, and the kind-of-Javascript reactive programming system it is built on is a great fit for that.
Outside of that use-case, I think notebooks are great for the first 20% of the effort that gets 80% of the work done. If it turns out one also needs to do the other 80% of the effort to get the last 20%, it is time to "graduate" away from a notebook. For instance if I am participating in a Kaggle machine learning competition I may train my first models in a Jupyter notebook for quick iteration on ideas, but when I settle onto a more rigid pipeline and infra, I will move to plain Python files that I can test and collaborate on.
This "graduation" from notebook to the "production/serious" environment should be straightforward, which means there shouldn't be too much magic in the notebook without me opting into it. Documentation in my eyes is not so different, I should be able to copy the examples easily into my JS project without knowing specifics of Observable and adapt it to my problem. Saying "don't be lazy and just learn Observable", or "you must learn D3 itself properly to be able to use it anyway" is not helpful. Observable being a closed, walled garden doesn't help: not being able to author notebooks without using their closed source editor is a liability that I can totally understand makes it a non-starter for some companies and individuals.
I think it's ok to plug my own project: It's called Starboard [1] and is truly open source [2]. It's built on different principles: it's hackable, extendable, embeddable, shareable, and easy to check into git (i.e. I try to take what makes the web so great and put that in a notebook environment). You write vanilla JS/ES/Python/HTML/CSS, but you can also import your own more advanced cell types. Here's an example which actually introduces an Observable cell type [3] which is built upon the Observable runtime (which is open source) and an unofficial compiler package [4]. I would be happy for the D3 examples to be expressed in these really-close-to-vanilla JS notebooks, but I can convince the maintainers to do so.
[1]: https://starboard.gg
[2]: https://github.com/gzuidhof/starboard-notebook
[3]: https://starboard.gg/gz/open-source-observablehq-nfwK2VA
[4]: https://github.com/asg017/unofficial-observablehq-compiler
As someone building an in-browser notebook I have a lot of opinions on notebook environments. Notebooks serve different purposes, sometimes the notebook itself is the end-goal because the author is creating an interactive tutorial or explaining a complex concept with a bunch of visualizations. Observable is a fantastic tool for that, and the kind-of-Javascript reactive programming system it is built on is a great fit for that.
Outside of that use-case, I think notebooks are great for the first 20% of the effort that gets 80% of the work done. If it turns out one also needs to do the other 80% of the effort to get the last 20%, it is time to "graduate" away from a notebook. For instance if I am participating in a Kaggle machine learning competition I may train my first models in a Jupyter notebook for quick iteration on ideas, but when I settle onto a more rigid pipeline and infra, I will move to plain Python files that I can test and collaborate on.
This "graduation" from notebook to the "production/serious" environment should be straightforward, which means there shouldn't be too much magic in the notebook without me opting into it. Documentation in my eyes is not so different, I should be able to copy the examples easily into my JS project without knowing specifics of Observable and adapt it to my problem. Saying "don't be lazy and just learn Observable", or "you must learn D3 itself properly to be able to use it anyway" is not helpful. Observable being a closed, walled garden doesn't help: not being able to author notebooks without using their closed source editor is a liability that I can totally understand makes it a non-starter for some companies and individuals.
I think it's ok to plug my own project: It's called Starboard [1] and is truly open source [2]. It's built on different principles: it's hackable, extendable, embeddable, shareable, and easy to check into git (i.e. I try to take what makes the web so great and put that in a notebook environment). You write vanilla JS/ES/Python/HTML/CSS, but you can also import your own more advanced cell types. Here's an example which actually introduces an Observable cell type [3] which is built upon the Observable runtime (which is open source) and an unofficial compiler package [4]. I would be happy for the D3 examples to be expressed in these really-close-to-vanilla JS notebooks, but I can convince the maintainers to do so.
[1]: https://starboard.gg
[2]: https://github.com/gzuidhof/starboard-notebook
[3]: https://starboard.gg/gz/open-source-observablehq-nfwK2VA
[4]: https://github.com/asg017/unofficial-observablehq-compiler
Something is wrong when we expect high quality libraries for free. The authors have mortgages to pay and children to feed. Not sure what the answer is. If coupling Observable with d3 is such an answer, then more power to them. Related, I've stumbled upon this blurb from Codemirror6. Perhaps another answer.
If you are using CodeMirror commercially, there is a social expectation that you help fund its maintenance.
https://codemirror.net/6
Recently I needed a simple chart for my startup. I looked online and all I could find was bloated libraries that were increasing the bundle size by many KBs. But then they also started rendering in the browser. Considering that it was possible to cache the request for a full day for all users, I wrote a small library that renders an svg on the server: https://github.com/rugpullindex/svg-line-chart
Chart in action: https://rugpullindex.com