Yeah, my current thinking on incrementality is that biggest advance of React was that you don’t have to think about state transitions, only about rendering from scratch. Incrementality kind of pulls into different direction: it forces you to think about transitions first and foremost, and I’m not sure it’s what people really want to do unless they absolutely have to

maybe it's the same as what you're thinking: so far building on top of flex and experimenting with solidjs, I spend a lot of time thinking about scope, because where you setup your listener determines when and where your DOM changes. In solidjs, you have to be careful where you read your reactive values so that it sets up the listener in the place you want, otherwise you can end up with subtly broken code or performance problems.

I don't know if you've seen it, but hyperfiddle seems to encapsulate the side-effects and incrimentality quite nicely at the edges. The function dom/div ... is actually an endpoint with (initialize ...) , (update old... ...), and (destory ...). There is no diffing of a vdom - each html object is the endpoint of a missionary signal chain.

@U5P29DSUS can you point me to something I can read about it? Or source code I could study?

The actual source code is https://github.com/hyperfiddle/electric/blob/master/src/hyperfiddle/electric_dom2.cljc#L45. The underpinning model is described pretty well https://hyperfiddle.notion.site/UIs-are-streaming-DAGs-e181461681a8452bb9c7a9f10f507991. Just a note - there is nothing fundamental to electric about a clj and cljs build. At a high level, electric is just a DSL for missionary, the graph/signal processor. The only really special thing about electric is that e/server and e/client are transparent terminations of a signal on the current runtime that sends that signal via a websocket to the other runtime.

Great article! I've been also thinking about this a lot. Both React and Svelte (UI as a function model) couple the reactive context boundary to a component/function and reconcile over a courser-grained unit. Solid (UI as a DAG model) unlocks extra performance because it avoids doing unnecessary work by automatically shrinking the reactive context down to fine-grained boundary of individual leaf nodes. These models can also be mixed, for example Vue is a hybrid with a reactivity system similar to Solid's signals, but chose familiarity over performance and renders using VDOM like React. Solid's approach is the most performant because these implementations are just wrappers on top of slow OOUI APIs (DOM). I'm a fan of Solid, but for a from-the-scratch implementation with direct graphics rendering the performance difference might end up less significant. Another downside of reactive graphs is that they don't play that well with immutable data structures. I am about to explore HUI more to get myself more familiar, but if I understand correctly it seems that ui/dynamic is a way to establish reactive context explicitly. That may be the best of both worlds. By default one could use course-grained reactive contexts which are more convenient and easier to reason about. But there would still be an option to add explicit finer-grained reactive contexts to optimize performance bottlenecks without bending the model.

Fwiw solid js is very similar to electric, as far as I understand.

Yes I think so too, the similarity is that both build reactive DAG and do fine-grained updates. Solid is much less sophisticated. The compiler is optional and only compiles JSX templates for performance, but the reactive graph is expressed in plain JS primitives. Electric takes it on the next level by introducing a new DSL for distributed reactivity, of course the lines are a bit blurry since the compiler is hidden behind macros. Definitely worth to keep an eye on both.