[slopinthebag]

At first I thought this was using a compiler to figure out data dependencies on regular javascript objects, including built in's on the window and coming from third party dependencies, so you could do this:

   <div>window width: {window.innerWidth}</div>

But it's not, it's just on objects that subclass a Store.

[dashersw]

This is an interesting idea, though, thanks for bringing it up! I will think about it and try to add it to the compiler. Especially native objects like `window` would be great to create handlers for in the compiler. It would make life really easy for the developer.

[slopinthebag]

Yeah, I experimented with this a while ago, basically compile templates to get their dynamic data dependencies and then poll them for changes, although I did it at runtime. I was able to have thousands of components running with fairly minimal cost, turns out strict equality checks are pretty cheap, although there was issues with defining custom objects or anon functions inside the template. A compiler could be much smarter about this, including nested field access on objects, ignoring temporary objects and functions, and deduping checks so only the minimal amount of values would be polled each frame. Values out of the viewport can "sleep" or be polled on a lower frequency. It's kind of an interesting paradigm because it doesn't require anything on the part of the developer to write their state management in a specific way or to wrap third party dependencies in a reactive wrapper.

Of course polling is not fashionable as it's seen as "crude" or "unoptimised" but typically most UI's only have a few dozen input sources at most visible on a screen, and polling that amount of data amounts to less than a ms even on slower mobile hardware. In extreme cases with thousands of data points the compiler could be smart and "short-circuit" the checks, or the component could opt into manual update calls.

But it's super powerful to have what amounts to true immediate mode UI, the entire issue of state management basically goes away. `window.state` becomes a perfectly viable option haha.

Anyways, cool framework.