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

191–200 of 336 posts

Re: A proposal to add signals to JavaScript

#191

Post by nikitaga »

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 different tradeoffs, and none of them deserve to have a special place in the JavaScript spec.

Before these libraries used signals, they or their predecessors used virtual DOM. Luckily, that didn't become part of JS, but how are signals any different? They aren't. The argument for making them standard is even worse than for virtual DOM.

Are we just going pile every fad into a runtime that basically has no way to dispose of no-longer-wanted features without breaking the web? That is quite short sighted.

Re: A proposal to add signals to JavaScript

#192

Post by imbnwa »

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?

Re: A proposal to add signals to JavaScript

#193

Post by tambourine_man »

pquki4 wrote: post #176
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.

If you are working in a team with 5+ developers who work on the UI where people need to be able to quickly reuse components and put them in large, complicated applications with lots of data that could be fetched and updated with HTTP requests, it is almost impossible not to use any of those frameworks. If you are working on your own, or only create small web apps, sure, you can avoid frameworks in some cases.

> it is almost impossible not to use any of those frameworks.

Agreed, but because it’s a lot easier to just search for “React programmer” these days than it is to evaluate lots of JavaScript candidates, which has a much wider scope and proficiency level and make sure they’ll fit right in when hired.

But not because direct DOM manipulation is not inherently scalable. See puter[1] for instance, a fairly complex, 100k+ lines of code of jQuery.

https://github.com/HeyPuter/puter

Re: A proposal to add signals to JavaScript

#194

Post by tengbretson »

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?

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 consistent api? I'm not so sure.

Re: A proposal to add signals to JavaScript

#195

Post by extheat »

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

Even better on Node, you have EventEmitter. A much simpler interface.

Re: A proposal to add signals to JavaScript

#196

Post by explaininjs »

cyanydeez wrote: post #165
explaininjs wrote: post #28

Earlier quoted context omitted.

The new `using` feature handles RAII just fine. This proposal is entirely unnecessary given the existence of `using` and the already-existing event listeners. https://iliazeus.github.io/articles/js-explicit-resource-man...

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

Re: A proposal to add signals to JavaScript

#197

Post by Izkata »

cuddlecake wrote: post #162
tqwhite wrote: post #63

Earlier quoted context omitted.

Yes. Thank you. I am already tired trying to figure out how this would improve my life and annoyed at trying to read other people's code that has more abstracted crap in it.

Promises are, technically speaking, "abstracted crap". So is abstracted crap only ok if it's already in the JS standard library?

Promises proved themselves in libraries before they got added to Javascript.

Re: A proposal to add signals to JavaScript

#198

Post by aporetics »

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

Well said

Re: A proposal to add signals to JavaScript

#199

Post by 6510 »

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?

You have to name the function or you cant remove it :P

Re: A proposal to add signals to JavaScript

#200

Post by eyelidlessness »

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…

> Disclaimer: I don't have 100% context if this concept is _really_ the same across all these frameworks.

Very nearly[1] every current framework now has a similar concept, all with the same general foundation: some unit of atomic state, some mechanism to subscribe to its state changes by reading it in a tracking context, and some internal logic to notify those subscriptions when the state is written. They all have a varied set of related abstractions that build upon those fundamental concepts, which…

> But frankly, I doubt it, if it was that similar, why are there at least a dozen frameworks with their own version?*

… is part of what distinguishes each such framework. Another part is that state management and derived computations are only part of what any of the frameworks do. They all have, beyond their diverse set of complementary reactive abstractions, also their own varied takes on templating, rendering models, data fetching, routing, composition, integration with other tools and systems.

Moreover, this foundational similarity between the frameworks is relatively recent. It’s a convergence around a successful set of basic abstractions which in many ways comes from each framework learning from the others. And that convergence is so pervasive that it’s motivating the standardization effort.

This especially stands out because the reference polyfill is derived from Angular’s implementation, which only very recently embraced the concept. From reading the PR notes, the implementation has only minor changes to satisfy the proposed spec. That’s because Angular’s own implementation, being so recent, internalizes many lessons learned from prior art which also inform the thinking behind the spec itself.

This is very much like the analogy to Promises, which saw a similar sea change in convergence around a set of basic foundational concepts after years of competing approaches eventually drifting in that same direction.

[1]: Most notably, React is unique in that it has largely avoided signals while many frameworks inspired by it have gravitated towards them.

Post reply on HN