A proposal to add signals to JavaScript
github.com
A proposal to add signals to JavaScript
1–10 of 336 posts
Re: A proposal to add signals to JavaScript
#2Re: A proposal to add signals to JavaScript
#3Surely it would be better to fix the interoperability issues of the language? "Lets just add a single implementation of everything to the standard!" seems like quite a strange response to "users of the language are having trouble with interoperability due to false coupling."
Re: A proposal to add signals to JavaScript
#4Surely it would be better to fix the interoperability issues of the language? "Lets just add a single implementation of everything to the standard!" seems like quite a strange response to "users of the language are having trouble with interoperability due to false coupling."
I don't think the language hurts or hinders interop much? It has a wide range of tools that can adapt objects between different shapes, for when we do have two similar but different interfaces we are trying to bridge.
I struggle to see what more one could want. Do you have any specific features you think would help a massive ecosystem of packages be able to work together, when for example different packages have different Signal implementations?
Re: A proposal to add signals to JavaScript
#5Surely it would be better to fix the interoperability issues of the language? "Lets just add a single implementation of everything to the standard!" seems like quite a strange response to "users of the language are having trouble with interoperability due to false coupling."
is it strange?
Vue reactivity isn't compatible with Svelte, nor Angular.
As a counter example to your question, what if we all had competing implementations of the object primitive. Libraries would barely work with one another and would need an interop layer between them (just as reactivity layers do today!)
Re: A proposal to add signals to JavaScript
#6Surely it would be better to fix the interoperability issues of the language? "Lets just add a single implementation of everything to the standard!" seems like quite a strange response to "users of the language are having trouble with interoperability due to false coupling."
is it strange? Vue reactivity isn't compatible with Svelte, nor Angular. As a counter example to your question, what if we all had competing implementations of the object primitive. Libraries would barely work with one another and would need an interop layer between them (just as reactivity layers do today!)
I'll admit I don't use JavaScript very often, but surely the state of polymorphism could be improved? For example, C++ recently added concepts, and most (modern) languages have some way to describe interfaces.
As to your counterexample, I agree with current JavaScript that would be a problem, but with good language support it would certainly be possible. For example, Rust (and C++?) have competing implementations of the global allocator, and must users will never notice.
Re: A proposal to add signals to JavaScript
#7Promises 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 channels, except they're broadcast instead of single receiver. It'd be neat if this could somehow be leveraged to allow web workers to communicate with channels instead of onMessage callbacks. Specifically being able to `select` over signals/channels/promises like in Go would over a syntactic benefit over having to try manage multiple concurrent messaging mechanism with callbacks (maybe by allowing signals to be included in `Promise.any`)
Re: A proposal to add signals to JavaScript
#8Surely it would be better to fix the interoperability issues of the language? "Lets just add a single implementation of everything to the standard!" seems like quite a strange response to "users of the language are having trouble with interoperability due to false coupling."
I don't think the language hurts or hinders interop much? It has a wide range of tools that can adapt objects between different shapes, for when we do have two similar but different interfaces we are trying to bridge. I struggle to see what more one could want. Do you have any specific features you think would help a massive ecosystem of packages be able to work together, when for example different packages have diff…
Better ways to describe polymorphism, a better type system in general really. Look to async Rust for a great example of such interoperability.
Re: A proposal to add signals to JavaScript
#9Promises 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…
> Promises are a nice success story, but without async/await it wasn't really necessary to standardize
One benefit of standardisation that's not tied to async/await is that the JavaScript engines has been able to do performance optimisations not otherwise possible which benefit Promise-heavy applications
Re: A proposal to add signals to JavaScript
#10Promises 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...