A proposal to add signals to JavaScript • Hacker News Board

Re: A proposal to add signals to JavaScript

#81

Post by andrewstuart » Sun, Mar 31, 2024, 7:53 PM UTC

_the_inflator wrote: post #47

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?

Historically, this example is the reason why the Web evolved into jQuery and from there forked into the world of Angular and React mainly. Event handling is getting messy very easily. If you want to get deeper into it, have a look at event bubbling and propagation. Large applications need a robust event handling. This is the nowadays hidden benefit of frameworks like Angular, Vue etc. Believe me, you don’t want to us…

I use events extensively in large applications and its never been a problem. In fact they solve complexity.

Re: A proposal to add signals to JavaScript

#82

Post by [deleted] » Sun, Mar 31, 2024, 7:53 PM UTC

explaininjs wrote: post #40

ivan_gammel wrote: post #35

Earlier quoted context omitted.

Oh, come on. They do have an example of architecture, not literal example of events. It doesn’t matter what trivial implementation of Observer pattern you choose.

Except one is already built into the language? And it provides all the upsides of signals with none of the downsides? (Modulo proper use of `using` directives)

[deleted]

Re: A proposal to add signals to JavaScript

#83

Post by doomroot » Sun, Mar 31, 2024, 7:54 PM UTC

beezlewax wrote: post #76

_the_inflator wrote: post #47

Earlier quoted context omitted.

Historically, this example is the reason why the Web evolved into jQuery and from there forked into the world of Angular and React mainly. Event handling is getting messy very easily. If you want to get deeper into it, have a look at event bubbling and propagation. Large applications need a robust event handling. This is the nowadays hidden benefit of frameworks like Angular, Vue etc. Believe me, you don’t want to us…

What kind of side effects specifically?

I believe memory leaks to start

Re: A proposal to add signals to JavaScript

#84

Post by nurple » Sun, Mar 31, 2024, 7:55 PM UTC

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

Re: A proposal to add signals to JavaScript

#85

Post by zdragnar » Sun, Mar 31, 2024, 7:55 PM UTC

senoralligator wrote: post #6

nullvoxpopuli wrote: post #5

Earlier quoted context omitted.

is it strange? Vue reactivity isn't compatible with Svelte, nor Angular. As a counter example to your question, what if we all had competing implementations of the object primitive. Libraries would barely work with one another and would need an interop layer between them (just as reactivity layers do today!)

I'll admit I don't use JavaScript very often, but surely the state of polymorphism could be improved? For example, C++ recently added concepts, and most (modern) languages have some way to describe interfaces. As to your counterexample, I agree with current JavaScript that would be a problem, but with good language support it would certainly be possible. For example, Rust (and C++?) have competing implementations of…

The reactivity layers are all pretty tied into the hearts of the frameworks. There's no advantage to any framework to expose such a thing to end users to leverage a competing implementation.

As for polymorphism, even the current class syntax largely operates in the same way as the original prototypal inheritance mechanism, with a few exceptions in constructor behavior to support subclassing certain built-in objects.

You can pretty easily create run-time traits- like functions with prototpyes, the class construct is an expression whose resulting value can be passed around, mutated, etc.

For example, you can write a function that takes a class as an argument, and returns a new class that extends it.

Re: A proposal to add signals to JavaScript

#86

Post by lelanthran » Sun, Mar 31, 2024, 7:57 PM UTC

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?

> Anything wrong with that?

Well, don't events only bubble upwards? You need to know the exact element of it is not on a lower level in the DOM tree.

Events were too messy, so I wrote a small pub/sub message queue type of thing. Anyone anywhere in the DOM can subscribe to messages based on subject regexes.

Makes things a lot easier, especially when I added web components to wrap existing elements so that publishing and subscribing is done with attributes, not js.

Re: A proposal to add signals to JavaScript

#87

Post by notnullorvoid » Sun, Mar 31, 2024, 7:58 PM UTC

makkesk8 wrote: post #20

Looks useful, but what baffles me is.. Why is every framework setting state or their "signals" using "setX" functions? What's wrong with the built in getter and setters that you can either proxy or straight up override? This feels arguably cleaner: something = "else"; Than: setSomething("else");

Some libraries that feature signals style reactivity do use getter and setters (ember.js, and mobx are 2 good examples). However it makes sense for the primitive API to use functions since getter and setters are functions under the hood and get applied to an object as part of a property descriptor. It's also not always desirable to have a reactive value embedded in an object, sometimes you just want to pass around a single changeable value.

As for why some libraries choose the `[thing, setThing] = signal()` API (like solid.js) that's often referred to as read write segregation. Which essentially encourages the practice of passing read only values by default, and opting in to allowing consumer writes on a value by explicitly passing it's setter function. This is something that was popularized by React hooks.

Either way this proposal isn't limiting the API choice of libraries since you can create whatever kind of wrappers around the primitive that you want.

Re: A proposal to add signals to JavaScript

#88

Post by Xenoamorphous » Sun, Mar 31, 2024, 8:02 PM UTC

gray_-_wolf wrote: post #45

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

Maybe a stupid question, but isn't the memory released anyway when I close the tab? So why do memory leaks matter?

Have you ever seen Chrome’s “aw, snap!” screen (if you use Chrome)?

More often than not that’s due to a memory leak.

Re: A proposal to add signals to JavaScript

#89

Post by itsjustme2 » Sun, Mar 31, 2024, 8:03 PM UTC

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 of the parity and unnecessary rendering." - Sounds like they want premature memoization.

- "What if another part of our UI just wants to render when the counter updates?" Then I agree the strawman example is probably not what you want. At that point you might want to handle the state using signals, event handling, central state store (e.g. redux-like tools), or some other method. I think this is also what they meant by "The counter state is tightly coupled to the rendering system."? Some of this document feels a little repetitive.

- "What if another part of our UI is dependent on isEven or parity alone?" Sure, you could change your entire approach because of this if that's a really central part of your app, but most often it's not. And "The render function, which is only dependent on parity must instead "know" that it actually needs to subscribe to counter." is often not an unreasonable obligation. I mean, that's one of the nice things about pure computed functions- it's easy to spot their inputs.

Re: A proposal to add signals to JavaScript

#90

Post by pvg » Sun, Mar 31, 2024, 8:05 PM UTC

tambourine_man wrote: post #74

duxup wrote: post #68

Earlier quoted context omitted.

In simple applications it is easy. More complex it is not easy.

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.

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.