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

161–170 of 336 posts

Re: A proposal to add signals to JavaScript

#161

Post by refulgentis »

shermantanktop wrote: post #159
38 wrote: post #142

Earlier quoted context omitted.

> I don't want to get into the nitty gritty about what is too much boilerplate and whether you should build an event system or not You're basically saying you want this thing, but you don't want to have to justify it

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 similar, why are there at least a dozen frameworks with their own version?*

Also, I've lived through React, Redux, effects, and so on becoming Fundamentally Necessary, until they're not. Usually when it actually is fundamental you can smell it outside of JS as well. (ex. promises futures). I've seen 1000 Rx frameworks come into style and go out of style, from JS to Objective-C to Kotlin to Dart. Let them live vibrant lives, don't tie them to the browser.

* I know that's begging the question, put more complex: if they are that similar and that set in stone that its at a good point to codify, why are there enough differences between them to enable a dozen different frameworks that are actively used?

Re: A proposal to add signals to JavaScript

#162

Post by cuddlecake »

tqwhite wrote: post #63
kookamamie wrote: post #54

Looks bad. It adds what looks like more nonsense complexity. Also, "Signals" as a name is not descriptive to what is proposed (see e.g. Qt Signals).

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?

Re: A proposal to add signals to JavaScript

#163

Post by djbusby »

berkes wrote: post #149
eddd-ddde wrote: post #30

Earlier quoted context omitted.

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

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.

Re: A proposal to add signals to JavaScript

#164

Post by bastawhiz »

ivanjermakov wrote: post #152
bastawhiz wrote: post #120

Earlier quoted context omitted.

> In other words, can't this be a library? You answered your own question: > I know that SolidJS is able to It already is, obviously. But how is SolidJS supposed to work with other non-SolidJS code? It can't. Unless every library builds support for every other library, they can't possibly interoperate.

It's a shame that JS ecosystem is so sparse. E.g. in Rust it's much more common to rely on existing "building blocks" like futures, tokio, syn, serde even just for basic bindings, favoring interoperability.

I think you've got it backwards. Fifteen years ago we had jQuery and not a whole lot else. Everyone just used the "building blocks" libraries of js. But then the community and the ecosystem grew exponentially, and we have innumerable choices. Python is similar: I can think of a half dozen ways off the top of my head to build a web app. At least Python was on top of standardizing things like WSGI, but even then you can see rough edges like the non-interoperable nature of concurrent code (twisted vs tornado vs greenlets vs threading vs multiprocessing vs asyncio etc).

Rust will have the same thing happen in another decade or so. It's prevalence will grow the community, which will grow the ecosystem, and the positive feedback loop will mean that there's a huge amount of choice. That's a good thing, but it will have downsides, like decreased interoperability (unless the language evolves). JavaScript was cursed for a very long time by leadership that was essentially asleep at the wheel.

Re: A proposal to add signals to JavaScript

#165

Post by cyanydeez »

explaininjs wrote: post #28
cyanydeez wrote: post #25

Earlier quoted context omitted.

Mostly the teardown logic and inevitable memory leaks. A alt proposal would be some kind of auto remove listener if it goes out of context

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.

Re: A proposal to add signals to JavaScript

#166

Post by Muromec »

everybackdoor wrote: post #51
troupo wrote: post #42

Earlier quoted context omitted.

Automatic dependency tracking, guarantees against circular references, improved observability and potentially better devtools

And a backdoor in a build tree

Imaginary exercise for the reader: find a sneaky dot in a patch that implements this in Firefox.

Re: A proposal to add signals to JavaScript

#168

Post by andrewstuart »

claytongulick wrote: post #113
troupo wrote: post #73

Earlier quoted context omitted.

There's no existing "good enough" solution for reactive values in JS. Also https://news.ycombinator.com/item?id=39887187

Getters and setters work pretty well. addEventListener("foo", () => {...}, {once: true}) Is a pretty easy way of handling one-shot events. Those have been "good enough" for me to build large, complex healthcare applications.

>> Getters and setters work pretty well.

What do you mean can you explain more?

Re: A proposal to add signals to JavaScript

#169

Post by Pufferbo »

andrewstuart wrote: post #156
ksherlock wrote: post #153

Earlier quoted context omitted.

I agree. But look at Preact's signal documentation - https://preactjs.com/guide/v10/signals "In Preact, when a signal is passed down through a tree as props or context, we're only passing around references to the signal. The signal can be updated without re-rendering any components, since components see the signal and not its value. This lets us skip all of the expensive rendering work and jump immediately to any com…

>> In Preact, when a signal is passed down through a tree as props or context, I have found that passing props makes React-like applications very complex and messy and props are to be avoided as must as practical. The mechanism for avoiding props is Custom events. It concerns me to see the concept of signals being passed as props when surely signals/events should be removing the need for props?

You don’t need to pass a Preact signal as a prop to get reactivity. If you’re using Preact, signal references will make your component reactive by default, and if you’re using React you can introduce reactivity by way of the useSignals hook or a Babel plugin. (1)

React signals have become my go to state management tool. So easy to use and very flexible.

1: https://www.npmjs.com/package/@preact/signals-react

Re: A proposal to add signals to JavaScript

#170

Post by xg15 »

mardifoufs wrote: post #125
tambourine_man wrote: post #102

Earlier quoted context omitted.

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.

You don't need to be building Facebook or Google to have a TON of state in a webpage. Obviously if you are doing a basic dashboard, a blog or something similar, it isn't really needed. But for more complex stuff I think react provides a much better way to handle state changes than just using vanilla js. It's not like using react makes an app more complex, because if you wanted to do the same thing in vanillajs you'd…

Could you give a concrete example for the more complex stuff?
Post reply on HN