What does this buy me over events?
Automatic dependency tracking, guarantees against circular references, improved observability and potentially better devtools
And a backdoor in a build tree
A proposal to add signals to JavaScript
51–60 of 336 posts
Re: A proposal to add signals to JavaScript
#52Is dependency tracking problem statically solvable (without calling effect once and subscribing to all .get's)? I don't think this needs to be a language feature, rather abstraction of existing features. In other words, can't this be a library? I know that SolidJS is able to figure out dependent signals, but probably doing so on the first execution.
I believe Svelte does figure it out at build time.
Which does make me question the mention of Svelte in the proposal, and makes me wonder what the Svelte developers think of it - because IIUC they indeed don't need this (at runtime), if I'm not mistaken.
Re: A proposal to add signals to JavaScript
#53Re: A proposal to add signals to JavaScript
#54Looks bad. It adds what looks like more nonsense complexity. Also, "Signals" as a name is not descriptive to what is proposed (see e.g. Qt Signals).
Re: A proposal to add signals to JavaScript
#55Earlier quoted context omitted.
I think the comment you're replying to is referring to the pub/sub sections of the proposal. They don't explicitly mention events, but events are a subset of the publish/subscribe pattern.
But then so are signals. The only "benefit" signals as proposed here give you is less control over the exact dispatch pattern of the graph, for instance things like debouncing, throttling, batching, etc etc etc. Aka all the things you absolutely must have control over if you want to make something resembling a high performance application.
Signals are not a subset of events. Signals combine event subscription with value construction, which promotes a remote declarative model for updates.
> The only "benefit" signals as proposed here give you is less control over the exact dispatch pattern of the graph, for instance things like debouncing, throttling, batching,
Events don't give you any more control over those properties than signals, they just require more boilerplate.
Re: A proposal to add signals to JavaScript
#56Promises are a nice success story, but without async/await it wasn't really necessary to standardize > The current draft is based on design input from the authors/maintainers of Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz, and more… Would be interested what existing library authors think of this proposal. Interesting that React is not in that list Signals are a bit like c…
Maybe they can call it "EventEmitter" https://nodejs.org/en/learn/asynchronous-work/the-nodejs-eve...
That looks like it fits with the theme, but events are difficult to compose & tend to have easy leaks by requiring explicit attach/detach (not that I'm sure the proposal here addresses those issues)
Re: A proposal to add signals to JavaScript
#57Cool. My least favorite, cumbersome and brittle aspect of using Ember becoming a core aspect of JavaScript functionality.
No fucking thank you.
Re: A proposal to add signals to JavaScript
#58Can't we just call javascript 'done'? We keep adding things to the language, and never subtract anything, which means learning it as a language is getting harder and harder.
[deleted]
Re: A proposal to add signals to JavaScript
#59The lack of signals isn’t remotely the largest issue with JS, and adding them has minimal impact for most users of JavaScript. The biggest issue is the lack of a standard library, resulting in npm hell in most projects.
Re: A proposal to add signals to JavaScript
#60Earlier quoted context omitted.
Mostly the teardown logic and inevitable memory leaks. A alt proposal would be some kind of auto remove listener if it goes out of context
Maybe a stupid question, but isn't the memory released anyway when I close the tab? So why do memory leaks matter?
Not a web dev person, but some "tabs" have a very long lifetime, e.g., webmail clients, Whatsapp, etc.