Hi @kave, and welcome to the forum!
Just in case you haven’t seen it, please let me begin by referring you to this notebook, which is the ‘official’ guide:
It’s true that Observable has its own way of doing things, and you’re not alone in being frustrated by these differences. I’ll try to unpack some of what’s going on with the downloading method. Because I am a novice user, I will be a bit overly unassuming in this response. I see you know node and a lot of what I am going to write will clearly be basic to you. Please forgive me… my hope here is to try to give a summary response to the general question as I understand it: how can I just download and run an Observable app.
When you click ‘download code’, Observable provides you with a tar archive. To see the contents of this file, you’ll need to ‘open’ it in a manner similar to how you would open a .zip file. In the case of the parallel sets notebook you referenced, the archive content includes these files:
- dde4715990f04109@246.js
- index.html
- index.js
- inspector.css
- LICENSE.txt
- package.json
- README.md
- runtime.js
Unlike the bl.ocks example you shared, Observable notebooks are not straight / vanilla javascript. Instead, they’re more akin to a bundled React or even Node.js app in the sense that in order to run, they need a runtime environment. That’s what the runtime.js file provides to you. Most of the rest of the notebook javascript (and other content, which effectively is ‘wrapped’ in javascript cells) is contained in the dde4715990f04109@246.js file – including, in this case, the data (note on this ‘gotcha’ below). Aside from these two files, you’ll also need the index.js and the inspector.css to run a notebook… and you might notice that these are all that’s referenced in the index.html file, which effectively brings all these parts together to run your application. The rest of the files have important functions, but strictly speaking there’re not necessary.
Oh - one big ‘gotcha’ that isn’t well documented (and I’ll see if I can link to threads discussing this in a bit) is that b/c your example has a file attachment, you’ll have to load in the data… but it’s totally obscure: in this case, it involves download the CSV and renaming it to a file called /files/3a1e9bb1ba5d9eb731c86c272fccb2543886aca0ef0b80add89f0471177427c5c6627d5ee5d85d011e44cc14019a0509bf309c6db2d347f9bdf7fe26723432d7 … and you won’t find it in the tar archive.
As Bryan and I were trying to explain above, if your goal is just to grab and run Mike’s example, all you need to do is pull out the five files identified above [runtime.js, dde4715990f04109@246.js,inspector.css,index.jss,index.html], run a server instance, and they will return the visualization. Here are the files served through GitHub to show this:
It’s definitely true that this whole process is very different than just grabbing and pasting in JavaScript from bl.ocks – and there’s an entire thread about the frustrations that people have voiced over this.
To me, I kinda feel like it’s similar to the experience I had first looking at a React.js app: I didn’t see how the parts fit together, it required a lot of effort to get started, and I didn’t really understand why one would bother with the application if one could just write plain JavaScript. What use a runtime? In the case of React, why compile from .jsx, which isn’t Javascript and can’t be stuck into a <script> tag. I never did learn React… but I am doing pretty OK learning Observable. What’s the difference? Firstly, there’s this amazing community here on the forum that answers most of the questions I raise. Secondly, Observable offers me immediate positive reinforcement: I don’t have to reload a server instance, clear a cache, or do any other steps when testing some code. The runtime provides cell interactions that link together components and show me instantly how parts fit, where I break things, and why. I don’t need a separate console screen to explore my data, which helps me a lot. …But this is a digression.
Anyway - maybe this answers your question, maybe not. I guess the long and short is that what you’re missing, so to speak, is that the Observable team made a deliberate choice to move away from rendering D3.js examples as bl.ocks written in plain JavaScript to instead showing them through an application that requires a runtime (the Observable runtime) as a trade-off between the convenience of copy-paste examples and an interactive notebook environment that separates code segment into discreet functional elements. They download feature is intended as a sort of ‘bridge’, as it allows you to take any notebook and serve it without much fuss (as I sought to model here… though given, it was fussy… particularly with respect to file attachments… and the Observable team would do well to document this better.)
With some work, you can also just copy and paste the code from within the parallel sets notebook into script elements in plain JS, and it’d work just fine (since it is essentially a static graph and doesn’t really leverage the power of the runtime)… but for other more complex notebooks, the runtime is the glue, and it helps to allow users to separate out bits of code in blocks while taking care of all the heavy lifting of cell interactions.
I hope this helps!
PS: This is one of my favorite tools for making all of this way easier in terms of embedding a visualization directly in an application: