Observable is fantastic, but as others have hinted at, IMO, I think it's trying to lock you in. I want the raw JS, in one click, so that I can build out a visualization locally, just hacking on HTML/JS. Steps to doing this are highly obfuscated when they could be a single button.
Overall you can see its evolution from prior sites- someone spent a huge amount of time demonstrating cool visualizations, then tried to make it all "proprietary". Nothing wrong with that, but why not make people addicted to the service by giving them the raw drug, rather than making them hate you for dancing through hoops?
Again- huge fan of access to many cool visualizations that have greatly improved what I can express visually for presentations etc., but very unhappy that I can't do this so much easier for my particular workflow. I'd love to be shown otherwise, but I've also spent a lot of time looking for answers, reading forum responses, etc., and they seem to all reflect wanting you to go through them, not along for the ride with them.
For instance, I host content on my personal website [0] that is written in using Observable, and in fact the site provides guides to allow anyone to export content[1] and embed elsewhere online.
My content can be entirely under my control if I save my libraries out of the Observable API as a tarball[2].
I genuinely think the differences between Observable and 'pure' javascript are driven by the vision for a more powerful way of using javascript for rapid prototyping, rather than any attempt to make it proprietary. I think these ideas are revolutionary and Observable is one of my favourite working environments as a data scientist.
I also think that Mike Bostock has shown good faith, and dedication to the open source community through decades of work, which he's always given away for free.
With all that said, if ObservableHQ and its API were to disappear overnight, the lack of an editing environment would make it difficult to update existing content and so I think there is space for a offline version of the editor. As far as I understand it, nothing's stopping a third party building this.
Thanks for the links, I completely concur with the goodness of everything you've raised.
To clarify where I'm coming from, my use-case is (fully) offline. I want to mock the visualization in the service then get the raw, static JS offline to be used as a template. I'll write a Ruby wrapper around the data I'm exploring and gradually parameterize the template as I better understand it, and what my data looks like in it. I don't want to dance with details of the JS, I want to dance with details of the data and parameters, so get me out of requiring online hooks ASAP. I know this is possible because prior versions of Observable let you do exactly what I want, but now I get some super friendly/not friendly interfaces that obfuscates what I'm familiar with.
As a separate issue not fully related- Ultimately my goal is a static visualization for scientific publications or presentations (I can export SVG from Observable, so my prior arguments doesn't hold here). Science has a very long shelf-life, in my field we routinely reference papers and their figures 200+ years old. While I absolutely love the idea of "living publications" I also fear life that depends on other's services. If the big people can't play nice (coughing in your direction Google services gone dark, I can think of various examples that have screwed over scientists), then you can see my caution in adopting Observable's all-in-dynamic approach.
I agree that Observable is fantastic, but also wish it was more open.
I'm building something similar called Starboard Notebook[0] that has a different set of trade-offs. It ends up being something in between Jupyter and Observable:
* One of the goals is to build Jupyter how it would have been if it was designed for the web (only).
* It's open source [1], plays nice with git (the format is plaintext), and supports local viewing & editing [2]
* Because of that you can host it yourself, put it on your blog / github pages, anywhere.
* There is little magic, it actually is just Javascript at it's base. This means you can use standard browser APIs and HTML, and when you are ready to "graduate" the notebook implementation that should be straightforward. In my eyes notebooks are only for the first 20% of the work that does 80% of the job for small applications/experimentation (which is often where it ends anyway).
* You can "build the ship as you sail": you can load new cell types dynamically at runtime. This is also how Python is supported (through WebAssembly).
* You can have interop with Python and Javascript which is really powerful. Example: Create a drag an drop form using HTML+JS, then process the dropped CSV file using Pandas and visualize using matplotlib.
I think the support for HTML,CSS,JS is unlike any other notebook, as well as the possibility to change the runtime at runtime (importing by URL new language plugins / other functionality). This makes it great for documentation (with examples you can actually execute), as an output format for automated reports, as a scriptable Tensorboard, as a platform for interactive articles, and for educational purposes (tutorials, homework).
Python works for stuff that was written for it purposefully.
Some python libraries work great: numpy, matplotlib, pandas. But many others are not supported directly and can be installed through micropip, but that's quite confusing! These are the issues with Pyodide currently:
* All python code that is executed is synchronous, which means it can not make requests (or call sleep). You can actually make a request using pyodide.open_url('path'), but that makes a synchronous request which isn't really a good idea for anything but small files. I believe asynchronous Python is possible, recent versions of emscripten support it, but it needs someone to put the pieces together (which is not easy!)
* Some packages are huge without being split up. Scipy is actually the only one that's really problematic, I believe it's around 80MB? It should be possible to split it up (into scipy.interpolate, scipy.stats, etc)
* Micropip is asynchronous, so you get a promise when you use micropip.install('my-package'), but you can't "await" it.
* Loading Python initially freezes the browser for a second or two.. not a great user experience.
* Libraries which are not pure python currently need to be manually made compatible with patches - including torch.
Python in the browser (not just in Starboard) needs more love. This is powered by Pyodide[0] which has been making steady progress, but the project is without corporate backing since Mozilla's change of direction. Perhaps Observable can allocate some of their funding towards supporting Python in their notebooks too through this project? Also consider this a call to action for other contributors who want to see Python in the browser become a reality :)
Overall you can see its evolution from prior sites- someone spent a huge amount of time demonstrating cool visualizations, then tried to make it all "proprietary". Nothing wrong with that, but why not make people addicted to the service by giving them the raw drug, rather than making them hate you for dancing through hoops?
Again- huge fan of access to many cool visualizations that have greatly improved what I can express visually for presentations etc., but very unhappy that I can't do this so much easier for my particular workflow. I'd love to be shown otherwise, but I've also spent a lot of time looking for answers, reading forum responses, etc., and they seem to all reflect wanting you to go through them, not along for the ride with them.