materialite VS denorm

Hey, Electric co-founder here.

Yup, our reactivity is quite simple at the moment, as described, and works quite well because SQLite is so fast. There are other projects doing more sophisticated reactivity algorithms, like Riffle/LiveStore, which has a reactive DAG optimised to avoid re-rendering and https://github.com/vlcn-io/materialite, which is like differential dataflow for live queries.

They're quite bleeding edge at the moment, but you can expect more efficient primitives for incremental view maintenance / efficient subscriptions to land in the embedded database layer quite soon.

Just also re: above, shape filtering for partial sync landed in v0.10 https://electric-sql.com/blog/2024/04/10/electricsql-v0.10-r... :)

I've stopped paying close attention to the web framework scene in the past couple of years, as most of the interesting ideas on this topics are usually coming from different communities. But as I understand, the majority of popular web frameworks (React, Vue3, Angular) are still using tree diffing or hybrid "signals"+tree diffing strategies.

In my opinion, one of the most interesting ideas to explore in this problem space is a hybrid solution: differential dataflow[1][2](model) + self-adjusting computations(view-model + view).

1. https://github.com/vlcn-io/materialite

2. https://timelydataflow.github.io/differential-dataflow/

> Continuous aggregation

I found this to be a very common need, so I created [denorm](https://github.com/rivethealth/denorm) for doing this in vanilla PostgreSQL. (It also does incrementally updated joins as well.)

(I expect the performance of a native implementation to be superior. Unfortunately, I use managed database services.)