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

91–100 of 336 posts

Re: A proposal to add signals to JavaScript

#91

Post by runarberg »

nurple wrote: post #84
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?

Welcome to Node.js v21.6.2. Type ".help" for more information. > window.dispatchEvent(new Event('counterChange')) Uncaught ReferenceError: window is not defined

    $ node
    Welcome to Node.js v20.6.1.
    Type ".help" for more information.
    > const target = new EventTarget()
    undefined
    > target.dispatchEvent(new Event("counterChange"))
    true

Re: A proposal to add signals to JavaScript

#92

Post by notnullorvoid »

angleofrepose wrote: post #46

Off topic, but I’m wondering if anyone attracted to this topic could help me understand why JavaScript doesn’t have macros. I’m aware of much conversation around dismissing macros, often in the context of bad dev experience — but this sounds like a shallow dismissal to me. At the end of the day, we have some of the results of macros in the JavaScript ecosystem, but rather than being supported by the language they are…

Macros don't really make sense in JS runtime spec. Since you can mostly already achieve macro level features by using eval or new Function, but it's not very efficient. Macros make most sense at build time, and there have been a few attempts at generalized build macros with various bundlers / transpiler plugins. I think the space needs more time to mature. I'm optimistic that we'll eventually see some sort of (un)official macro spec emerge.

Re: A proposal to add signals to JavaScript

#93

Post by duxup »

itsjustme2 wrote: post #89

Am I the only one that thinks the vanilla js example is actually easier to read and work with? - "The setup is noise and boilerplate heavy." Actually the signals example looks just as noisy and boilerplate heavy to me. And it introduces new boilerplate concepts which are hard for beginners to understand. - "If the counter changes but parity does not (e.g. counter goes from 2 to 4), then we do unnecessary computation…

I agree the initial example is easier to read, but it has problems as stated.

Re: A proposal to add signals to JavaScript

#94

Post by tambourine_man »

duxup wrote: post #78
tambourine_man wrote: post #74

Earlier quoted context omitted.

I’ve been writing web apps for easily 25+ years. Never have I reached for React and friends voluntarily. But again, I know I’m in a minority. I’m just not completely sure why.

You could work for 50 years and never need those… it just depends on what you’re creating / how many devs and so on. I know some guys who over the years wrote their own framework. It works great… for them.

Right, the only thing that convinces me is team and hiring dynamics. But that’s not what these tools advertise.

It’s always like: you have dozens of interactive controls in this view, it’s getting out of hand, you should use this language that compiles to HTML and JavaScript and carry all these dependencies. To which I always reply: no thanks, I rather deal with the dozens of controls.

Re: A proposal to add signals to JavaScript

#95

Post by duxup »

tambourine_man wrote: post #94
duxup wrote: post #78

Earlier quoted context omitted.

You could work for 50 years and never need those… it just depends on what you’re creating / how many devs and so on. I know some guys who over the years wrote their own framework. It works great… for them.

Right, the only thing that convinces me is team and hiring dynamics. But that’s not what these tools advertise. It’s always like: you have dozens of interactive controls in this view, it’s getting out of hand, you should use this language that compiles to HTML and JavaScript and carry all these dependencies. To which I always reply: no thanks, I rather deal with the dozens of controls.

> team and hiring dynamics. But that’s not what these tools advertise.

I think that’s a given for any proposed standard. We all get a common way we understand things and can even just communicate about a thing.

Re: A proposal to add signals to JavaScript

#96

Post by vbezhenar »

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 change? Why this talk about caching then? Probably not.

Anyway I think that signal idea is sound, if I understood correctly what the authors tried to convey. My main issue with those decoupling architectures is that once your application is complex enough, you will get lost trying to figure out why this particular event being emitting. Ideally signals should fix this by modifying stacktrace, so when my callback is being called, it'd already contain a stacktrace of the code which triggered that signal in the first place.

Re: A proposal to add signals to JavaScript

#97

Post by falcor84 »

doomroot wrote: post #83
beezlewax wrote: post #76

Earlier quoted context omitted.

What kind of side effects specifically?

I believe memory leaks to start

Are you implying that there are memory leaks in browsers' internal implementation of events? Because my take is that the problem is with "user space" scripts not cleaning up after themselves, and I don't see how that would get better by adding yet another API to be mindful of.

Re: A proposal to add signals to JavaScript

#98

Post by jupp0r »

This is a horrible idea. Instead of building some dependency tracking into this niche feature of the language, JS should come up with a generic way of enabling framework developers to clean up resources without putting the burden on users of their API to manually do this.

Re: A proposal to add signals to JavaScript

#99

Post by leononame »

itsjustme2 wrote: post #89

Am I the only one that thinks the vanilla js example is actually easier to read and work with? - "The setup is noise and boilerplate heavy." Actually the signals example looks just as noisy and boilerplate heavy to me. And it introduces new boilerplate concepts which are hard for beginners to understand. - "If the counter changes but parity does not (e.g. counter goes from 2 to 4), then we do unnecessary computation…

Why do you think this is premature memoization? This is an example, boiled down to a simple function. Do you think people just came up with the use case for this without ever having needed it?

I think an effort in standardizing signals, a concept that is increasingly used in UI development is a laudable effort. I don't want to get into the nitty gritty about what is too much boilerplate and whether you should build an event system or not, but since signals are something that is used in a variety of frameworks, there might be a good reason to it? And why not make an effort and standardize them over time?

Re: A proposal to add signals to JavaScript

#100

Post by Fatalist_ma »

pavlov wrote: post #14
__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…

> “Interesting that React is not in that list” Signals are not a part of the core React API, unlike Preact. My vague gut feeling is that signals are too much like a generalized useEffect() and would only introduce further confusion into React by muddling what happens during the render cycle. For better and worse, React takes a different tack to updates than signals do. But maybe I’m wrong about their applicability.

There is an interesting debate about React and signals in the comments of this article, between Dan Abramov and Ryan Carniato - https://dev.to/this-is-learning/react-vs-signals-10-years-la...
Post reply on HN