> and Observable is cool, but strays from standard JS.
The front end does but the underlying runtime is running just javascript, and the source code is basically javascript with some trivial macros which are fully captured in the MIT licensed acorn parser. That's why normal Javascript debugging expression work perfectly in Observablehq.
I love the Observable runtime. I wrote a decompiler for it so you can bidirectionally convert between the front end source and the compiled pure JS representation.
What is the need for the runtime? I've ported exported ObservableHQ code to plain JS, and the runtime bits were a lot of hard-to-read indirection. Lots of calling into function references with strings identifying the parameter names.
It seems like it might provide some kind of reactive signal abstraction, but modern signal libraries, and the TC39 Proposal, seem to do this in a lower-level and more ergonomic way.
It detects naming collisions, orchestrates recomputation with a topological sort and manages module reuse and normalizes generators and promise to a common abstraction. The parameter indirection is for separating the inner cell code from the inter-cell dependency graph. You need to do that for the partial recomputation to work without the user manually plumbing in the dependencies (like you have to do in React). I will read the TC39 I don't know it so can't compare.
Edit: yes seems like signals could be a major building block to do the recomputation part
The front end does but the underlying runtime is running just javascript, and the source code is basically javascript with some trivial macros which are fully captured in the MIT licensed acorn parser. That's why normal Javascript debugging expression work perfectly in Observablehq.
https://github.com/observablehq/parser
I love the Observable runtime. I wrote a decompiler for it so you can bidirectionally convert between the front end source and the compiled pure JS representation.
https://observablehq.com/@tomlarkworthy/observablejs-toolcha...