> Nice little library, but as it's signals based, it would be nice to make it compatible with the signals proposal (https://github.com/tc39/proposal-signals)

Based on the current proposals, it seems that a signal can only contain a single atomic value, for which changes can be tracked. Aberdeen's `proxy` can efficiently wrap complex data structures (objects within arrays within objects, etc), tracking changes on the level of primitive values (integers, strings).

For that reason, I wouldn't really call Aberdeen signals based.

Yeah, "what data to sync and when" describes the problem quite nicely! And indeed, it's entirely different from this library, except that I have a partial solution in mind that may fit Aberdeen rather well... We'll see. :-)

I just read the signals proposal and was not impressed. There is a lot group thought in JavaScript, in Java too but more in JavaScript, around standardizing convenience based upon knowingly bad decisions from convenience abstractions.

Managing and updating the DOM is stupid simple and that simplicity has nothing to do with state, which a fully separate yet equally simplistic concern. That is something UI frameworks most commonly fail at horribly with a mountain of highly complex state bullshit that is forced on everything. But because framework people cannot architect original applications at any level these failures become indefensible standards enshrined by the most insecure among us.

> The problem with remote server/database is ,,what data to sync and when'' by the way, it's very different problem from what your framework is solving.

I also feel that the data synchronization (and conflict handling) is where there are a lot of opinions and patterns but few drop in libraries. Although I'm posting this in no small hope that I get corrected with someone pointing out something I should be using.