←back to thread

Reactive HTML Notebooks

(maxbo.me)
356 points california-og | 3 comments | 18 Nov 24 08:33 UTC | HN request time: 1.831s | source
Show context
spankalee ◴[18 Nov 24 17:23 UTC] No.42174609[source]▶
I strongly agree with the premise of the article - HTML could be a fabulous substrate for computational notebooks!

But I didn't love the choices for how to implement it here. Dynamic, reactive HTML can be a lot more declarative than this, and Observable is cool, but strays from standard JS.

I started to build a reactive HTML system called Heximal that eventually will have notebook support, but it's declarative, based on HTML templates and custom elements with a expression / reactivity system (based on the TC39 Signals proposal) on top.

https://github.com/elematic/heximal

It's a bit like a mashup of HTMX, Tangle, Curvenote, and Polymer. Or like HTML if were natively reactive.

I think it will lend it self to graphical editing and notebook user cases quite well.

replies(2): >>42177179 #>>42179149 #
1. tlarkworthy ◴[18 Nov 24 21:20 UTC] No.42177179[source]▶
> 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.

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...

replies(1): >>42177781 #
2. spankalee ◴[18 Nov 24 22:27 UTC] No.42177781[source]▶
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.

replies(1): >>42180362 #
3. tlarkworthy ◴[19 Nov 24 05:41 UTC] No.42180362[source]▶
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