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

221–230 of 336 posts

Re: A proposal to add signals to JavaScript

#221

Post by troupo »

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…

> why are there enough differences between them to enable a dozen different frameworks that are actively used?

Because they are not in the standard library of the language? Because they all arrived at the solution at different times and had to adapt the solution to the various idiosyncratic ways of each library? Because this happen in each and every language: people have similar, but different solutions until they are built into the language/standard library?

Re: A proposal to add signals to JavaScript

#222

Post by troupo »

LittleDan wrote: post #110
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 there is room for improvement in how we explain this. The problems aren’t really visible in this small sample and comes up more for bigger things. PRs welcome.

I wouldn't be surprised if Ryan Carniato already has a perfect explanation somewhere :)

Re: A proposal to add signals to JavaScript

#223

Post by Too »

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…

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.

Re: A proposal to add signals to JavaScript

#224

Post by Cloudef »

troupo wrote: post #29
lloydatkinson wrote: post #16

Sorry but I’ll be a little bit mad if this Preact/Angular inspired thing is approved and made part of the spec, while Observable was deliberately ostracised.

> I’ll be a little bit mad if this Preact/Angular inspired thing Signals predate both and originate in KnockoutJS at least. They were popularized in recent years by SolidJS. And then adopted into Preact, Vue and others. Angular is a very late newcomer to the signals game. Edit: and this is literally in the introduction section: --- start quote --- This first-class reactive value approach seems to have made its first…

Signals are actually much older concept from 70s introduced in smalltalk as a ValueHolder. Later Qt reused the same concept and called them "signals & slots".

Re: A proposal to add signals to JavaScript

#225

Post by Too »

The examples only show simple values. What happens when mutating nested objects and arrays?

Other frameworks usually struggle a lot with this. With workarounds like having to override equality functions in useMemo() or call .set after a mutation even if you pass in the same instance as before.

Re: A proposal to add signals to JavaScript

#226

Post by ngc6677 »

unemployable wrote: post #157
doomroot wrote: post #83

Earlier quoted context omitted.

I believe memory leaks to start

Memory leaks can occur when a component adds events to an element outside of the component (such as the window) and then gets removed from the DOM without removing the event handler from the window. This is solved in native Web Components by the mount/unmount methods where you can run code to remove event listeners when the component has been unmounted. For other event listeners, they get removed when the DOM element…

Example with web components in all frameworks https://webcomponents.dev/blog/all-the-ways-to-make-a-web-co... and an other version to experiment with https://jsbin.com/yiviragiba/8/edit?html,css,js,console,outp...

Re: A proposal to add signals to JavaScript

#227

Post by troupo »

Izkata wrote: post #197
cuddlecake wrote: post #162

Earlier quoted context omitted.

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.

Signals have, too. And it is literally spelled out in the readme, in the introduction section

Re: A proposal to add signals to JavaScript

#229

Post by jonathanlydall »

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…

I think you’re right, I don’t see how building this into the base library makes some things possible which weren’t before.

I think that the Promise API was not the actual thing people directly wanted (and on its own had no compelling reason to be added to the base library), but a standardised Promise API was needed in order to add the hugely useful async/await keywords which are unachievable without changes to the language.

I am however a big fan of a really good base library (it’s one of the things I love about working with .NET), but they should be focussing on functionality with the broadest reach (as in most encountered by average JS devs working on day to day tasks), e.g. things like better tools for working with dates and times.

Re: A proposal to add signals to JavaScript

#230

Post by klabb3 »

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…

I don’t have a dog in the fight. I also don't see yet any mainstream support behind the proposal. So I don’t get why it has to be so heated?

The main benefit is interop. Same with promises. You can implement all of promises with custom callbacks - in fact it’s trivial. But competing implementations don’t typically land on API compatibility simply because they’re solving the same problem. That causes a fractured ecosystem. Maybe interop could be important with signals? I think they should argue that, if so!

> Users will still need to use libraries for that, just like they do today.

Yes? But you reduce the lifting by the libs - ideally enabling a class of vanilla use-cases which can be made demonstrably improved. You could say querySelector was unnecessary because you can do it in lib. Or filter, or map. Standardization can cover std-lib like features too no?

Doesn’t mean I am in favor. I think you should always default to no unless strong and consistent proven benefits. But why not have good faith arguments for what problems this will or won’t solve. For instance, if hypothetically let’s say react or svelte has a different model that cannot possibly use these signals, then that’s probably a sign it’s not good. My philosophy with proposals is balancing the curiosity and honest inquiry with a grumpy defensive inquisition before saying aye. Flaming though is really not helpful.

> You're basically saying that we should add signals to JS because we've added (much simpler or more needed) things to JS before

> saving bundle size

Yes, I agree these are weak arguments.

Post reply on HN