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

41–50 of 336 posts

Re: A proposal to add signals to JavaScript

#41

Post by zdragnar »

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?

According to TFA, event emitters / observables cause unnecessary work when called multiple times.

The difference with signals is that the resulting value is only ever calculated when the end consumer reads the value- so you schedule render updates asynchronously from the actual writes to the signal, and whatever chain of computations the watchers perform is done just the one time during the render.

Interim values sent to the signal will get lost, so you really can't do too much interesting work in them. It's really just a fancy abstraction layer to coordinate a rendering cycle.

Re: A proposal to add signals to JavaScript

#43

Post by ivan_gammel »

ahmedfromtunis wrote: post #32
ivan_gammel wrote: post #23

Earlier quoted context omitted.

Did you read the document? They have an example there, which is quite similar to yours, and explain what is the problem.

Can you please point to where in the document such an example was mentioned? I rechecked the document and couldn't find it.

Just look for the example of a design pattern („Example - A VanillaJS Counter“ section), not for a literal implementation of it via events. Conceptually they are the same.

Re: A proposal to add signals to JavaScript

#44

Post by j1elo »

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");

For one I can write ".set" and the IDE would auto-complete with all possible somethings that can be set, even without having the slightest idea of which ones there are.

I've very much enjoyed this kind of consistency wherever is found (having a common prefix for common behaviors, in this case, setters)

Re: A proposal to add signals to JavaScript

#45

Post by gray_-_wolf »

cyanydeez wrote: post #25
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?

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?

Re: A proposal to add signals to JavaScript

#46

Post by angleofrepose »

Off topic, but I’m wondering if anyone attracted to this topic could help me understand why JavaScript doesn’t have macros.

I’m aware of much conversation around dismissing macros, often in the context of bad dev experience — but this sounds like a shallow dismissal to me.

At the end of the day, we have some of the results of macros in the JavaScript ecosystem, but rather than being supported by the language they are kicked out to transpilers and compilers.

Can anyone point me to authoritative sources discussing macros in JavaScript? I have a hard time finding deep and earnest discussion around macros by searching myself.

Re: A proposal to add signals to JavaScript

#47

Post by _the_inflator »

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 use the standard event handling API without a framework. Adding, deleting, cloning, firing, removing, fire once etc on many elements can have serious unwanted side effects.

Re: A proposal to add signals to JavaScript

#48

Post by troupo »

londons_explore wrote: post #39

Can't we just call javascript 'done'? We keep adding things to the language, and never subtract anything, which means learning it as a language is getting harder and harder.

They don't add these to the language. They add these to the (currently basically non-existent) standard library.

Given that almost every single framework under the sun (except React) has converged on signals, it makes sense to move that into the browser. This... this is how the web is supposed to work.

Re: A proposal to add signals to JavaScript

#49

Post by hoten »

angleofrepose wrote: post #46

Off topic, but I’m wondering if anyone attracted to this topic could help me understand why JavaScript doesn’t have macros. I’m aware of much conversation around dismissing macros, often in the context of bad dev experience — but this sounds like a shallow dismissal to me. At the end of the day, we have some of the results of macros in the JavaScript ecosystem, but rather than being supported by the language they are…

You could start here: https://github.com/search?q=org%3Atc39%20macro&type=code
Post reply on HN