Lab note #055 Rabbit holes leave project in shambles

Last week, I started looking at Signals. When I stepped back and looked at the entire front-end ecosystem, it seemed like many of them outside of React (Solid, Vue, Svelte, Preact), converged on some variation of Signals. There is even a Javascript proposal to include Signals in the language. Given front-end frameworks are doing the most work of any ecosystem I'm aware of on unstructured reactivity, I had to ask myself why that was.

So I started doing some online archeology about the debate between Signals (Solid, Vue, Svelte) vs Functional component (React) approaches. I implemented a basic Signals library to figure out what it was doing. My conclusion? I understand why the state-of-the-art moved this way, but I'm still wary of what we're giving up when UI isn't just a function of state and props (via Solid). I think it can be reconciled, if we view components as returning effects to be executed by the runtime to edit a DOM tree.

The other side-effect of going down this rabbit hole is unearthing other rabbit holes. I learned about autotracking (in Ember) a few days ago, and have been doing the same analysis on it as I did with signals. Autotracking uses a clock, not unlike a vector clock, instead of a dirty bit. However, it doesn't try to memoize any derived state functions unless it's directly connected to a reactive state.

Lastly, I found out about DBSP, which is a paper on incremental view maintenance based on Differential Dataflow. This is a structured reactivity technique, where we rely on the algebraic properties of a specific data type to define differentiation and integration. That's enough to construct the incremental version of any SQL statement. I haven't looked into it too hard, but it is enticingly promising.

Stepping back, all this makes me think there's an underlying common model for reactivity/incrementality, real-time collaboration, and offline sync. I have to figure out what it would look like.

While I managed to get the current notebook's execution model over the finish line, I'm not satisfied with it. In addition, despite the desire to use algebraic effects, it's hamstrung by a language that doesn't support first-class continuations (Python and Javascript, for people commonly working with notebooks). Right now, it's not looking good for algebraic effects.

So where does that leave me? The project is currently on the floor in shambles, based on the new information that I learned. I'm wary that I'm just procrastinating on the hard work after building something, but I think I need to redo it.