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

311–320 of 336 posts

Re: A proposal to add signals to JavaScript

#311

Post by naasking »

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…

> Am I the only one that thinks the vanilla js example is actually easier to read and work with?

Even if that were true for this example, the signal-based model grows linearly in complexity and overhead with the number of derived nodes. The callback-based version is super linear in complexity because you have an undefined/ unpredictable evaluation order for callbacks producing a combinatorial explosion of possible side effect traces. It also scales less efficiently because you could potentially run side effects and updates multiple times, where the signal version makes additional guarantees that can prevent this.

Re: A proposal to add signals to JavaScript

#312

Post by Sammi »

imbnwa wrote: post #192
nikitaga wrote: post #191

Why does it need to be a part of the language? This could be a library. There are such libraries. They are small, so including them in your code is no big deal. Adding this to the language should not even be a goal . Thinking that the current crop of JS UI libraries designed their signals in such a good way that it needs to become a part of the language is hubris. Signals have many possible implementations with diffe…

Remember the Observable proposal?

There's the old one that fizzled out: https://github.com/tc39/proposal-observable

And there's the new one which seems to be getting implemented in node right now: https://github.com/WICG/observable

Re: A proposal to add signals to JavaScript

#313

Post by Sammi »

meindnoch wrote: post #122

"let's bake my current framework du jour into the standard library!" It's a bit like tattooing your girlfriend's name onto yourself.

Except that's not what this is doing.

It's baking a building block into the standard library, that most frameworks have converged on using.

Promises became widely used, then they got included in the standard library. This is like that.

Re: A proposal to add signals to JavaScript

#314

Post by mattdesl »

recursive wrote: post #298
jonathanlydall wrote: post #296

Earlier quoted context omitted.

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

To do parallel tasks in a loop for the situation I outlined (getting a final array of images from URIs), it would be really cumbersome, and your implementation would be pretty much equivalent to the inner workings of Promise.all.

As others have mentioned; if you aren’t using Promise.all, you are likely missing a good deal of opportunities for easier and more performant async code.

Re: A proposal to add signals to JavaScript

#315

Post by cyanydeez »

explaininjs wrote: post #196
cyanydeez wrote: post #165

Earlier quoted context omitted.

Nice, but mixing typescript into a proposed standard just confusing.

The standard doesn't have anything to do with TypeScript, not sure where you got that from? https://github.com/tc39/proposal-explicit-resource-managemen...

Im referring to the link. Trying to demonstrate a proposed feature usingvtypescript.

Re: A proposal to add signals to JavaScript

#316

Post by recursive »

mattdesl wrote: post #314
recursive wrote: post #298

Earlier quoted context omitted.

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

To do parallel tasks in a loop for the situation I outlined (getting a final array of images from URIs), it would be really cumbersome, and your implementation would be pretty much equivalent to the inner workings of Promise.all. As others have mentioned; if you aren’t using Promise.all, you are likely missing a good deal of opportunities for easier and more performant async code.

For non-rejecting promises, `await Promise.all(promises)` is basically performance equivalent to `for (const p of promises) await p;`. In case you think the second one does serial work, here's a codepen for you. https://codepen.io/tomtheisen/pen/QWPOmjp

The "inner workings" could be a for loop, with the exception of rejected promises. The only opportunity for quicker resolution is when one of the promises reject, at which time Promise.all() immediately rejects.

I think the allegations of "easier" are significantly overblown too.

Re: A proposal to add signals to JavaScript

#317

Post by naasking »

gibbitz wrote: post #139
falcor84 wrote: post #97

Earlier quoted context omitted.

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.

I believe this would be more related to something like memoizing a DOM structure in a "Live" listener that is later removed from the DOM but not garbage collected due to the reference in the event listener. As the poster mentioned, developer error -- not a fundamental language or browser implementation flaw.

If a language or browser implementation can't reclaim this unused memory thus creating a memory leak, that arguably is a flaw. It's literally a DoS attack vector that can be exploited by the untrusted scripts that run in the browser sandbox.

Re: A proposal to add signals to JavaScript

#318

Post by naasking »

zaphar wrote: post #184
djbusby wrote: post #24

Earlier quoted context omitted.

I've been using patterns like this for more than a decade. The thing that's hard is, down the road you could have a listener, which triggers a other event, then another event, which comes back to the first routine and now you got a listen-loop that won't quit. And it's hard to ensure that all listener don't cause that trigger cascade.

I like signals as primitive but in this particular case they make it roughly about as easy to create loops accidentally as events do. I don't think this problem gets better or worse with signals.

Signals are a bit better because they only propagate when computed values actually changed. This is an implicit fixed point/stopping condition that doesn't intrinsically exist with events.

Re: A proposal to add signals to JavaScript

#319

Post by naasking »

tambourine_man wrote: post #62

I’ve been trying for decades to understand why people find it so hard to keep track of state and update the DOM. Sure, it requires a bit of discipline, but it’s vastly simpler to me than whatever solution comes up every few years (Backbone, Knockout, Angular, React, modifying the language itself, etc). There must be something profoundly different with the way I think. It even expresses itself in the function naming.…

> Sure, it requires a bit of discipline

I strongly suspect that in ages past you would have been an ASM programmer shaking your fist at those crazy portable C programmers, and then a C programmer shaking his fist angrily at those crazy memory safe Java programmers.

Progress in programming can be marked by eliminating the need for ceremonial kinds of strict discipline needed to achieve good results.

Which isn't to say React is some kind of next evolution, but signals certainly are a step in the right direction.

Re: A proposal to add signals to JavaScript

#320

Post by rrr_oh_man »

zero_shift wrote: post #173
berkes wrote: post #149

Earlier quoted context omitted.

Yes. It is. And most pub/sub or Observer architectures and design patterns have the "loop" thing solved just fine. In fact, the GOF spend an entire paragraph on the problem of complex update semantics in "design Patterns" (1995) ch Observer p299. So, while it is a real problem, it's one that has been solved (for at least 29 years)

In fact I solved a similar issue in my JS reactive micro library in just 500 bytes: https://github.com/jbreckmckye/trkl

That looks great! Thanks for sharing!
Post reply on HN