Comment by d--b

The part about Signals is telling and illustrates well why the idea while laudable is practically unfeasible.

I get why OP likes signals. In every large enough project there is a half baked implementation of a DAG calc tree and it makes sense that a language could standardize one.

But these abstractions have a huge mental / implementation cost.

The problem, as with most engineering things is a tradeoff problem. The react model - where you just update the global state and re-render everything - is slower but easier on the brain. The signals model is faster, but so much effort.

Most apps out there don’t need to be crazy fast, and people will choose react because it’s just simpler.

But signals don’t really have anything to do with templating, do they? So why do we have to choose, could we have templating and signals as separate things?

Well OP thought about templating and realized you do need a way to tell the dom how to fit your templated node where it belongs and update it when things change.

And this is where these proposals fail. There needs to be a choice here. The API must pick a side (well technically it could allow for both, but ugh), and developers won’t ever agree which side it should go.

The big problem of UIs has always been how they update, not how they’re defined. Microsoft tried (and failed) at defining a ton of models, MVC, MVP, MVVM, and what not, all of them were painful AF. Then imgui come and say, well what if UIs didn’t have state at all. Ooh this is nice, but kind of hard on the cpu, so what do we do?

Well, perhaps one of the biggest reason for the success of web apps is in fact that the dom didn’t impose a way to bind data to its view. And so we may be doomed to framework hell.