4 ms·

Congrats for reaching 1.0! Nice little library, but as it's signals based, it would be nice to make it compatible with the signals proposal (https://github.com/

Congrats for reaching 1.0! 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 https://github.com/tc39/proposal-signals) At the same time for me, while it's super nice, in my opinion it just doesn't differentiate enough from other signals based frameworks to get mass adopted / make CRUD apps that much easier to make. 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 loved Svelte until I started using SvelteKit and realized how hard the data synchronization part is.

vanviegen 1y ago
> 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 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. :-)
- MrJohz 1y ago
  Aberdeen's proxy is essentially an object of nested signals. In general: proxy({ name: "Foo", email: "bar", }); is semantically equivalent to new Signal({ name: new Signal("Foo"), email: new Signal("bar"), }); The syntax for getting a value will look different in each case, but using Javascript proxies you can fairly easily wrap the latter in such a way that it looks like the former. That's what happens with SolidJS's createStore utility, and I assume it's what's happening here as well. Aberdeen looks like it's taking Vue's approach of making the proxy/automatically nested case the default, which is typically more convenient as nested reactivity is the thing that makes signals really sing. But it's still just signals, and the same behaviour can always be replicated using manually nested atomic signals. EDIT: I've just realised you're OP, so you probably know more about your reactivity system than I do! But at least the way you're describing it, it sounds like it's working the same way as signals do, just with an emphasis on the nested signal case by default.
  - vanviegen 1y ago
    That's indeed how Aberdeen works, except that the nested proxy objects are created on-demand, when first accessed. 'Nested signals' it is then. :-)
austin-cheney 1y ago
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.
- llbbdd 1y ago
  examples?
  - austin-cheney 1y ago
    Examples of what? Do you mean examples of not using React?
    - lylejantzi3rd 1y ago
      I think he meant examples where "Managing and updating the DOM is stupid simple." The consensus here seems to be that updating the DOM is a difficult problem. It would be nice to have counter-examples. https://news.ycombinator.com/item?id=43734312 https://news.ycombinator.com/item?id=43734312
      - austin-cheney 1y ago
        I am sure it is hard if you have never written an application without React, jQuery, whatever before. That doesn't make it hard though. It just means its something, only at present, uncomfortable. Here is how I do it. This is all the front end code for a large personal project. https://github.com/prettydiff/webserver/blob/main/lib/dashboard/dashboard_script.ts https://github.com/prettydiff/webserver/blob/main/lib/dashbo... My observation is that no matter how complicated and large the application gets anything that ultimately runs in the browser scales in size disproportionately slower in the browser code than elsewhere. This remains true no matter how much of the instruction set you intentionally try to put into the browser. That said, why even bother with this framework bullshit in the first place if the code it abstracts is never the primary problem in any given application? The larger the application gets the less significant the browser portion of that code becomes as a percentage of total application size.
HWR_14 1y ago
> 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.
boredtofears 1y ago
> Nice little library, but as it's signals based How do you reach that conclusion? There is nothing mentioning signals in the docs anywhere.
- MrJohz 1y ago
  The proxy object is a fairly classic way of doing signals (see Vue, SolidJS), and the whole thing about functions rerunning whenever data that was accessed inside that function changes is pretty much the definition of signals. It looks like the author is trying to avoid making direct comparisons with signals and existing signal frameworks, which makes sense - depending on your target audience, it can be a bit "inside baseball" - but it's definitely using some sort of signals-like mechanism under the hood.
  - boredtofears 1y ago
    Huh. I guess in my trend-chasing days we just called that event driven programming.
    - MrJohz 1y ago
      It basically is that, although the key idea with signals is the automatic tracking. There's no sort of `signal.subscribe()` call happening, instead any time you use a signal inside a reactive context, it automatically gets subscribed. This simplifies a lot of patterns that would otherwise be rather complicated. For example, you might have an effect like: if (showName()) { console.log(name()); } else { console.log("the name is a secret"); } In this case, both `showName` and `name` are signals. If `showName()` is true, then the effect will automatically subscribe to both signals, and this function will rerun every time the name changes, or someone toggles `showName`. But if it's false, then the effect will only subscribe to the `showName` signal, which means even if the name changes somewhere else, that won't affect this expression at all. In complex situations, it can be harder to see where the reactivity is flowing without the explicit subscriptions, especially at first, but it's also a lot more intuitive to just use data and have it automatically become reactive where it makes sense. It's also the base for most major web frameworks outside of React.

vanviegen 1y ago

> 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 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. :-)

MrJohz 1y ago
Aberdeen's proxy is essentially an object of nested signals. In general: proxy({ name: "Foo", email: "bar", }); is semantically equivalent to new Signal({ name: new Signal("Foo"), email: new Signal("bar"), }); The syntax for getting a value will look different in each case, but using Javascript proxies you can fairly easily wrap the latter in such a way that it looks like the former. That's what happens with SolidJS's createStore utility, and I assume it's what's happening here as well. Aberdeen looks like it's taking Vue's approach of making the proxy/automatically nested case the default, which is typically more convenient as nested reactivity is the thing that makes signals really sing. But it's still just signals, and the same behaviour can always be replicated using manually nested atomic signals. EDIT: I've just realised you're OP, so you probably know more about your reactivity system than I do! But at least the way you're describing it, it sounds like it's working the same way as signals do, just with an emphasis on the nested signal case by default.
- vanviegen 1y ago
  That's indeed how Aberdeen works, except that the nested proxy objects are created on-demand, when first accessed. 'Nested signals' it is then. :-)

austin-cheney 1y ago

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.

llbbdd 1y ago
examples?
- austin-cheney 1y ago
  Examples of what? Do you mean examples of not using React?
  - lylejantzi3rd 1y ago
    I think he meant examples where "Managing and updating the DOM is stupid simple." The consensus here seems to be that updating the DOM is a difficult problem. It would be nice to have counter-examples. https://news.ycombinator.com/item?id=43734312 https://news.ycombinator.com/item?id=43734312
    - austin-cheney 1y ago
      I am sure it is hard if you have never written an application without React, jQuery, whatever before. That doesn't make it hard though. It just means its something, only at present, uncomfortable. Here is how I do it. This is all the front end code for a large personal project. https://github.com/prettydiff/webserver/blob/main/lib/dashboard/dashboard_script.ts https://github.com/prettydiff/webserver/blob/main/lib/dashbo... My observation is that no matter how complicated and large the application gets anything that ultimately runs in the browser scales in size disproportionately slower in the browser code than elsewhere. This remains true no matter how much of the instruction set you intentionally try to put into the browser. That said, why even bother with this framework bullshit in the first place if the code it abstracts is never the primary problem in any given application? The larger the application gets the less significant the browser portion of that code becomes as a percentage of total application size.

HWR_14 1y ago

> 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.

boredtofears 1y ago

> Nice little library, but as it's signals based How do you reach that conclusion? There is nothing mentioning signals in the docs anywhere.

MrJohz 1y ago
The proxy object is a fairly classic way of doing signals (see Vue, SolidJS), and the whole thing about functions rerunning whenever data that was accessed inside that function changes is pretty much the definition of signals. It looks like the author is trying to avoid making direct comparisons with signals and existing signal frameworks, which makes sense - depending on your target audience, it can be a bit "inside baseball" - but it's definitely using some sort of signals-like mechanism under the hood.
- boredtofears 1y ago
  Huh. I guess in my trend-chasing days we just called that event driven programming.
  - MrJohz 1y ago
    It basically is that, although the key idea with signals is the automatic tracking. There's no sort of `signal.subscribe()` call happening, instead any time you use a signal inside a reactive context, it automatically gets subscribed. This simplifies a lot of patterns that would otherwise be rather complicated. For example, you might have an effect like: if (showName()) { console.log(name()); } else { console.log("the name is a secret"); } In this case, both `showName` and `name` are signals. If `showName()` is true, then the effect will automatically subscribe to both signals, and this function will rerun every time the name changes, or someone toggles `showName`. But if it's false, then the effect will only subscribe to the `showName` signal, which means even if the name changes somewhere else, that won't affect this expression at all. In complex situations, it can be harder to see where the reactivity is flowing without the explicit subscriptions, especially at first, but it's also a lot more intuitive to just use data and have it automatically become reactive where it makes sense. It's also the base for most major web frameworks outside of React.