A proposal to add signals to JavaScript • Hacker News Board

Re: A proposal to add signals to JavaScript

#291

Post by troupo » Mon, Apr 01, 2024, 3:55 PM UTC

nikitaga wrote: post #218

klabb3 wrote: post #208

Earlier quoted context omitted.

Good points. We don’t want the wrong thing. But we want the right one! Reactive UI won. The main thing stopping me from using vanilla JS is the absolute explosion in complexity managing state for even small sized applications. To me, any reactive framework is better than vanilla, so perhaps there is a construct missing? Now that it’s been a decade or so, we should start thinking about possible cut-points for standard…

If you want to do "the right thing" – implement your proposal as a library, AND convince people to use it on its own technical merits . Then when everyone uses it (because it's so obviously "the right thing"), you can start asking if anyone wants your library to be built into the language. But that's not what you're doing. You're gunning for becoming the standard from the start – you are trying to convince people to…

> implement your proposal as a library, AND convince people to use it on its own technical merits.

That is almost literally exactly what happened: most major JS frameworks (except React) converged on Signals.

> Because not having signals in the language was never an actual problem holding back reactive UI development in JS.

Oh, but it did hold back reactive development. There are many limitations on current implementations of signals precisely because there's no proper support for many things in the language.

> You need to sell why your (or any) signals implementation needs to be in the JavaScript standard.

That is why it is:

- a proposal that

- calls for input from implementers, users, library developers etc.

> Unlike e.g. promises that are useful on their own,

But the exact same thing happened with promises: everyone had their implementation, there was no need for a proposal to add that specific API to the standard library. Deferred (the precursor to Promises) existed for several years before Promises. Here's the full history: https://samsaccone.com/posts/history-of-promises.html

And yet, 15 years later here we are

Re: A proposal to add signals to JavaScript

#292

Post by Offler » Mon, Apr 01, 2024, 4:25 PM UTC

nikeee wrote: post #123

Back in the days there was an effort to put observables in the language because they were popular (and rxjs was, too). Glad that didn't happen. And I think everybody else is, too. Maybe we should keep that in mind when standardizing features of frameworks.

They weren't used in virtually every single frontend framework though while Signals are

Re: A proposal to add signals to JavaScript

#293

Post by febed » Mon, Apr 01, 2024, 4:30 PM UTC

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?

Very hard to debug as the application gets larger

Re: A proposal to add signals to JavaScript

#294

Post by Too » Mon, Apr 01, 2024, 4:45 PM UTC

wruza wrote: post #243

Too wrote: post #223

Earlier quoted context omitted.

One good argument for standardizing Signals is that debugging them seems to be a nightmare. Imagine a deep tree of calculated signals firing off each other and you need to find the source of what started the chain reaction. Standardizing will allow devtools to develop around it.

They don't fire off each other, they simply depend on each other like functions do: a = () => 42 b = () => a() - 1 c = () => a() + b() * 2 It isn't a bigger nightmare than debugging pure functions. The source for `c` is `a` and `b`. All signal values (as proposed) will be lexically available in a body of a dependent signal, so there's no hidden registry to navigate anyway. If in-browser IDEs want to record a call tre…

There is still a watch() mechanism that from a consumers point of view hide the originating event of an update. Otherwise if all you wanted was functions, just use functions.

When watch fires out of control, you need debugging tools to understand why your render() function is being invoked more often than it should.

This type of problem happens all the time in react and you need to trace upwards to find that 7 components up the chain someone accidentally included new Date() in the state that propagates down through props and re-renders everything.

Re: A proposal to add signals to JavaScript

#295

Post by jonathanlydall » Mon, Apr 01, 2024, 5:04 PM UTC

recursive wrote: post #282

3m wrote: post #241

Earlier quoted context omitted.

Doing multiple async tasks concurrently as opposed to in sequence. If you have never used this you have either worked on extremely simple systems or have been leaving a ton of perf gains on the table.

How is this different from await a, await b, await c?

If each await was to a setTimeout call waiting 1000ms, awaiting all 3 would take approximately 3000ms.

If you await a Promise.all with an array of the promises, it will take approximately 1000ms.

In summary, using individual awaits runs them serially, while Promise.all runs them concurrently.

If you’re doing CPU bound work without workers, it doesn’t make much of a difference, but if you’re doing I/O bound tasks, like HTTP requests, then doing it in parallel will likely make a significant difference.

Re: A proposal to add signals to JavaScript

#296

Post by jonathanlydall » Mon, Apr 01, 2024, 5:07 PM UTC

recursive wrote: post #284

mattdesl wrote: post #242

Earlier quoted context omitted.

I often map a series of X to Y with Promise.all. For example, mapping a series of image URIs to loaded Image elements. It is shorter to write than a for of loop, and importantly, all images will be loaded in parallel rather than sequentially, which can be significantly faster. images = Promise.all(uris.map(loadImage))

You could also do it with a loop to start the promises and another one to await them. Is it just a shorter way of expressing that?

As per my other reply to you, there is a difference, a for loop will take the sum of each call to fetch the image while Promise.all will do the requests concurrently, meaning the total time will be that of the slowest request.

Re: A proposal to add signals to JavaScript

#297

Post by recursive » Mon, Apr 01, 2024, 5:23 PM UTC

jonathanlydall wrote: post #295

recursive wrote: post #282

Earlier quoted context omitted.

How is this different from await a, await b, await c?

If each await was to a setTimeout call waiting 1000ms, awaiting all 3 would take approximately 3000ms. If you await a Promise.all with an array of the promises, it will take approximately 1000ms. In summary, using individual awaits runs them serially, while Promise.all runs them concurrently. If you’re doing CPU bound work without workers, it doesn’t make much of a difference, but if you’re doing I/O bound tasks, lik…

I get what you're saying, but that's just not how it works in my experience. I've got a repro in codepen. What am I missing?

https://codepen.io/tomtheisen/pen/QWPOmjp

    function delay(ms) {
      return new Promise(resolve => setTimeout(resolve, ms));
    }

    async function test() {
      const start = new Date;
      const promises = Array(3).fill(null).map(() => delay(1000));
      for (const p of promises) await p;
      const end = new Date;
      console.log("elapsed", end - start); // shows about 1010
    }
    
    test();

Re: A proposal to add signals to JavaScript

#298

Post by recursive » Mon, Apr 01, 2024, 6:35 PM UTC

jonathanlydall wrote: post #296

recursive wrote: post #284

Earlier quoted context omitted.

You could also do it with a loop to start the promises and another one to await them. Is it just a shorter way of expressing that?

As per my other reply to you, there is a difference, a for loop will take the sum of each call to fetch the image while Promise.all will do the requests concurrently, meaning the total time will be that of the slowest request.

As per my other reply to your other reply, when I've written code that actually does `await` in a loop, it already does all the work concurrently. There's a code sample that illustrates what I'm familiar with.

On the other hand, the language designers are not random framework authors. They know what they're doing. There must be some reason why `Promise.all` exists. I just don't know what it is.

To re-iterate, I understand the difference between serial and parallel tasks. But I have also found that it's possible to do parallel tasks with `await` in a loop. So I'm still missing something.

Re: A proposal to add signals to JavaScript

#299

Post by Offler » Mon, Apr 01, 2024, 7:24 PM UTC

qudat wrote: post #179

> 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… This is primarily the only handful of consumers of this stdlib.

That's basically every major framework apart from React and it includes some major React libraries.

Re: A proposal to add signals to JavaScript

#300

Post by uzerfcwn » Mon, Apr 01, 2024, 7:55 PM UTC

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?

As an end user, I love when web applications pass events through the DOM tree, because it allows me to easily create plugins by hooking on the same events. Youtube is a prime example of how to do things right.

Unfortunately, modern frameworks really want to use their own event channels, which makes hooking a pain.