Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A proposal to add signals to JavaScript

github.com

Post reply on HN
Print view View original

111–120 of 336 posts

Re: A proposal to add signals to JavaScript

#111

Post by LittleDan »

mg wrote: post #15

When I need to signal something across my application, I use events: window.dispatchEvent(new Event('counterChange')); And every part of the application that wants to react to it can subscribe via window.addEventListener('counterChange', () => { ... do something ... }); Anything wrong with that?

LGTM! Smells like Redux (in a good way). But then ultimately at the root you probably want the event to update your “model”, and then that leads to an update of the “view”. This is the part where signals can be useful.

Re: A proposal to add signals to JavaScript

#113

Post by claytongulick »

troupo wrote: post #73
andrewstuart wrote: post #53

Earlier quoted context omitted.

That’s not enough to compete with an existing “good enough” solution.

There's no existing "good enough" solution for reactive values in JS. Also https://news.ycombinator.com/item?id=39887187

Getters and setters work pretty well.

    addEventListener("foo", () => {...}, {once: true})
Is a pretty easy way of handling one-shot events.

Those have been "good enough" for me to build large, complex healthcare applications.

Re: A proposal to add signals to JavaScript

#114

Post by pyrolistical »

vbezhenar wrote: post #96

I didn't understand the example in the linked README. // A library or framework defines effects based on other Signal primitives declare function effect(cb: () => void): (() => void); What library? What framework? I lost here. What's effect? effect(() => element.innerText = parity.get()); How does effect knows that it needs to call this lambda whenever parity gets changed? Will it call this lambda on any signal chang…

I suspect the watcher is needed by the implementation of effect

Re: A proposal to add signals to JavaScript

#115

Post by briantakita »

mg wrote: post #15

When I need to signal something across my application, I use events: window.dispatchEvent(new Event('counterChange')); And every part of the application that wants to react to it can subscribe via window.addEventListener('counterChange', () => { ... do something ... }); Anything wrong with that?

> Anything wrong with that?

It only works in browser environments.

Re: A proposal to add signals to JavaScript

#116

Post by alexchamberlain »

rblatz wrote: post #59

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

This is referenced in the proposal:

> JavaScript has had a fairly minimal standard library, but a trend in TC39 has been to make JS more of a "batteries-included" language, with a high-quality, built-in set of functionality available

I think the description "minimal" is fairer than "no" wrt the standard library.

Re: A proposal to add signals to JavaScript

#118

Post by bastawhiz »

__s wrote: post #7

Promises 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…

> without async/await it wasn't really necessary to standardize

Hard disagree.

`x instanceof Promise` simply doesn't work. If my library has a then method that accepts a catch callback and yours doesn't, they're silently non-interoperable, and there's no way to detect it. When does `finally` run? What expectations can you have around how async the callbacks are? Without a standard, every single library that uses promises needs to bring its own polyfill because you can't trust what's there. And you can't actually consume any other library's promises, because you can't trust that they behave in the way you expect them to.

And I'm not just speculating, this was reality for many years and a hell that many of us had to endure.

Re: A proposal to add signals to JavaScript

#119

Post by bastawhiz »

ttfkam wrote: post #117

Looks like Svelte 5 only somehow worse?

The proposal is very clear that it's not trying to be pretty, it's trying to be sensible and correct so that frameworks like Svelte can build on top of them and work interoperably with other libraries and frameworks.

Re: A proposal to add signals to JavaScript

#120

Post by bastawhiz »

ivanjermakov wrote: post #13

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

> In other words, can't this be a library?

You answered your own question:

> I know that SolidJS is able to

It already is, obviously. But how is SolidJS supposed to work with other non-SolidJS code? It can't. Unless every library builds support for every other library, they can't possibly interoperate.

Post reply on HN