A proposal to add signals to JavaScript

Re:A proposal to add signals to JavaScript by djbusby on Sunday March 31, 2024 @03:03PM (#39887047)

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.

[ Parent | on HN ]

Re:A proposal to add signals to JavaScript by eddd-ddde on Sunday March 31, 2024 @03:09PM (#39887094)

Isn't it possible to define all listeners / publishers in a declarative way which can be compiled to catch for this issues?

[ Parent | on HN ]

Re:A proposal to add signals to JavaScript by berkes on Sunday March 31, 2024 @06:21PM (#39888622)

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)

[ Parent | on HN ]

Re:A proposal to add signals to JavaScript by djbusby on Sunday March 31, 2024 @07:24PM (#39889200)

Yes, I want to mention, since I was up-thread, it is solved but not all tooling or environment are setup for that.

When the app is small you likely don't need it. And then it grows and you absolutely do.

It's better, in greenfield to use framework/tooling that is ready for it.

[ Parent | on HN ]

Re:A proposal to add signals to JavaScript by berkes on Monday April 01, 2024 @09:16AM (#39893851)

Good to hear you found it solved!

> It's better, in greenfield to use framework/tooling that is ready for it.

I don't really agree. Tooling, and even more so, Frameworks, come with giant trade-offs. Some are "paint-in-a-corner" trade-offs. So I would caution against pulling in a framework just to solve potential future issues. So much so, that I think it is one of the top10 things that will cause your project or startup to fail or get into serious trouble. It's really a form of "premature optimization".

[ Parent | on HN ]

Re:A proposal to add signals to JavaScript by jbreckmckye on Sunday March 31, 2024 @08:20PM (#39889545)

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

[ Parent | on HN ]

Re:A proposal to add signals to JavaScript by briantakita on Sunday March 31, 2024 @09:47PM (#39890106)

I was not aware of trkl. Well done! I wrote rmemo (Reactive Memo) which solves the same problems & is a similar size. Different semantics though.

https://github.com/ctx-core/rmemo

Nanostores is also small https://github.com/nanostores/nanostores.

And if you only need reactivity in the browser (not server side), VanJS is small & includes reactive primitives. https://vanjs.org/

[ Parent | on HN ]

Re:A proposal to add signals to JavaScript by rrr_oh_man on Tuesday April 02, 2024 @01:07AM (#39902575)

That looks great! Thanks for sharing!

[ Parent | on HN ]

Re:A proposal to add signals to JavaScript by zaphar on Sunday March 31, 2024 @09:24PM (#39889970)

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.

[ Parent | on HN ]

Re:A proposal to add signals to JavaScript by naasking on Tuesday April 02, 2024 @12:33AM (#39902408)

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.

[ Parent | on HN ]