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

261–270 of 336 posts

Re: A proposal to add signals to JavaScript

#261

Post by Offler »

Zababa wrote: post #254
flohofwoe wrote: post #253

Earlier quoted context omitted.

> ...but since signals are something that is used in a variety of frameworks... ...common usage is not really a justification for putting it into the language standard though. Glancing over the readme I'm not seeing anything that would require changes to the language syntax and can't be implemented in a regular 3rd-party library. In a couple of years, another fancy technique will make the rounds and make signals look…

From what I understand, a few/many of the big frameworks are converging on signals, and another commenter said that Qt had signals in the 90s https://news.ycombinator.com/item?id=39891883 . I understand your worries, and I would appreciate some wisdom from non-JS UI people, espcially if they have 20+ years of experience with them.

Every framework is moving to signals, apart from React and I'd say if this became a standard even they will. This is like Promise. It's a sensible shared concept.

Re: A proposal to add signals to JavaScript

#262

Post by M2Ys4U »

9dev wrote: post #248
esperent wrote: post #231

Earlier quoted context omitted.

> In practice you rarely need to explicitly go “new Promise” yourself However you do quite often need to use Promise.all, even when using async/await.

Also, wrapping callback APIs or containing side effects: function sleep(ms) { return new Promise((resolve) => setTimeout(resolve, ms)); } await sleep(100); There are some use cases for the Promise class still, and it’s great to have that kind of control facility at hand when you need it.

Promise.withResolvers can fill this gap now (though it's not natively available in Node, yet):

  function sleep(ms) {
    const { promise, resolve } = Promise.withResolvers();
    return setTimeout(resolve, ms), promise;
  }

Re: A proposal to add signals to JavaScript

#263

Post by Offler »

catlifeonmars wrote: post #181
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 think it’s worth avoiding a change in design when you pass some threshold of complexity. The vanilla JS approach has some scaling limitation in term of state graph complexity, and the problem isn’t the ergonomics above and below the threshold, but discontinuous change in ergonomics when you cross that threshold

Indeed at a certain scale the "easy" approach ends up becoming a mess. A simple counter isn't complex enough but this is a great idea and would be a positive for the language.

Re: A proposal to add signals to JavaScript

#264

Post by Offler »

tengbretson wrote: post #194
imbnwa wrote: post #192

Earlier quoted context omitted.

Remember the Observable proposal?

The Observable proposal made a stronger case in my opinion, since Observables provide an interface that is functionally unique and useful for the boundaries between app logic and libraries, so a single standard approach has benefits. Signals on the other hand live right where application state binds to the ui. Is this really somewhere that people are patching together a hodge podge of libraries that need to use a con…

Signals are used in every framework except React. Observables weren't. That's a huge difference.

Re: A proposal to add signals to JavaScript

#265

Post by Offler »

LittleDan wrote: post #111
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.

Look at legend-state, it's most definitely not Redux (in a good way IMO).

Re: A proposal to add signals to JavaScript

#266

Post by MrJohz »

spacechild1 wrote: post #245
leononame wrote: post #99

Earlier quoted context omitted.

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

> a concept that is increasingly used in UI development For a desktop app developer that's a pretty funny statement, given that the Qt framework introduced signals and slots in the mid 90s. I am curious how many web devs think that signals are a new concept. (I don't necessarily mean the parent poster.)

While they share the same name, and are both reactive primitives, there are some fairly key differences between these signals and the QT signals and slots mechanism.

The main one is that QT signals are, as far as I understand, a fairly static construct - as you construct the various components of the application, you also construct the reactive graph. This graph might be updated over time, but usually when components are mounted and unmounted. JS signals, however, are built fresh every time they are executed, which makes them much more dynamic.

In addition, dependencies in JS signals are automatic rather than needing to be explicitly defined. There's no need to call a function like connect, addEventListener, or subscribe, you just call the original signal within the context of a computation, and the computation will subscribe to that signal.

Thirdly, in JS signals, you don't necessarily need to have a signal object to be able to subscribe to that signal. You can build an abstraction that doesn't necessarily expose the signal value itself, and instead provides getter functions that may call the underlying signal getter. And this same abstraction can be used both inside and outside of other reactive computations.

So on the one hand, yes, JS signals are just another reactivity tool and therefore will share features with many existing tools like signals and slots, observables, event emitters, and so on. But within that space, they are also a meaningful difference in how that reactivity occurs and is used.

Re: A proposal to add signals to JavaScript

#267

Post by Offler »

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

I work on FX trading applications with hundreds of thousands of lines of code. Full fat desktop application replacements. Good luck not using a framework. 20-30 developers with multiple clients with their own devs.

Re: A proposal to add signals to JavaScript

#268

Post by berkes »

djbusby wrote: post #163
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)

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.

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

Re: A proposal to add signals to JavaScript

#269

Post by pvg »

tambourine_man wrote: post #102
pvg wrote: post #90

Earlier quoted context omitted.

FB's website has settings subpages that are more complicated than an average web app and is an SPA-style-mega-app made of piles of other apps. It typically keeps highly consistent state throughout. There's no doing that sanely by hand, you'll just forget something or, more likely, it will get lost between the dozens upon dozens of people needed to build such a thing.

1) Almost no one is building FB or Gmail, yet act like it. The precise reason why still escapes me. 2) For other use cases, it’s not that hard to manually update some elements in the DOM. You very quickly learn how not shot yourself in the foot. Certainly a lot easier (and faster) than dealing with the mess that is the React ecosystem.

This sounds more like a complaint the kids aren't happy to eat turnips and mashed bugs (just pick the legs and wings out!) like we had to and that their newfangled 'sandwiches' are too fancy. What if they get caught out in the forest with nothing but sandwiches? That oughta learn'em real quick.

Re: A proposal to add signals to JavaScript

#270

Post by moritzwarhier »

refulgentis wrote: post #161
shermantanktop wrote: post #159

Earlier quoted context omitted.

The rationale for it is the fact that multiple frameworks provide their own versions of this mechanism. The proposal is to relocate extremely popular and common functionality from framework space to the language/runtime space. The popularity of React is itself the rationale for the utility of this idea, and any terse version of the rationale is for show. Is that a good enough rationale? Maybe, maybe not, but you are…

Most importantly: OP is right re: vanilla example is most legible. Reading the proposal, I have no idea what this "Signal" word adds other than complexity. Less important: I really, really, really, really, am reluctant to consider that is something that needs standardizing. Disclaimer: I don't have 100% context if this concept is _really_ the same across all these frameworks. But frankly, I doubt it, if it was that s…

> Most importantly: OP is right re: vanilla example is most legible. Reading the proposal, I have no idea what this "Signal" word adds other than complexity.

The aim is to run computations or side effects only when the values they depend on change.

This is a perfectly normal scenario and you don't want to update all data the UI of a full application tree whenever something changes.

DOM updates are the most popular example but it could really be anything.

Of course in simple examples (e.g. this counter) you might not care about recomputing every value and recreating every part of the DOM (apart from issues with focus and other details).

But in general, some form of this logic is needed by every JS-heavy reactive web app.

Regardless of the implementation, when it comes to that, I'm not sure I see the benefit of building this into the language either.

Post reply on HN