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

71–80 of 336 posts

Re: A proposal to add signals to JavaScript

#71

Post by tommiegannert »

Hmm, if we can optimize the reactive state management in all web apps, that sounds cool.

If this is to be a base for VueJS, it should handle deep changes. They have a note about support Map and Set, but being able to to control depth is nice in VueJS. (I'd say watch() should be deep by default, since non-deep is an optimization that can lead to accidental inconsistent state.)

Streams. Generally, I find RxJS backwards. Usually you just need "state", so that should be the easiest thing to implement. But I can't deny that the programming model is beautiful. Standardizing "state" without also considering streams seems odd to me. The "computed" creates a pipeline of updates, very similar to one you'd do with a map over a stream. If RxJS didn't already exist, I probably wouldn't have cared about this duality.

Async. Sure, signals can be synchronous, but Computed should definitely play well with async functions. This is a big shortcoming in VueJS (that people work around on their own.) That also implies handling "pending computation" gracefully for debuggability. I see there's a "computing" state, but this would have to be surfaced to be able to debug stuck promises.

Exceptions. I like the idea of .get() rethrowing exceptions from Computed. VueJS is a bit vague on that front, and just stops.

Re: A proposal to add signals to JavaScript

#72

Post by angleofrepose »

hoten wrote: post #49
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

A great resource that I should have found on my own. Thank you. I’ll look through this later. Giving it a quick glance now I see some of the same language I see other places; here that macros are “too far.”

I don’t know why macros are approached with apprehension. As I briefly get at in my first comment, I’m aware of a lot of dismissals of macros as a tool, but those dismissals don’t make sense to me in context. I’m missing some backstory or critical mind-share tipping points in the history of the concept.

What could be a good set of sources to understand the background perspective with which TC39 members approach the concept of macros?

Re: A proposal to add signals to JavaScript

#73

Post by troupo »

andrewstuart wrote: post #53
troupo wrote: post #42

Earlier quoted context omitted.

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

That’s not enough to compete with an existing “good enough” solution.

There's no existing "good enough" solution for reactive values in JS.

Also https://news.ycombinator.com/item?id=39887187

Re: A proposal to add signals to JavaScript

#74

Post by tambourine_man »

duxup wrote: post #68
tambourine_man wrote: post #62

I’ve been trying for decades to understand why people find it so hard to keep track of state and update the DOM. Sure, it requires a bit of discipline, but it’s vastly simpler to me than whatever solution comes up every few years (Backbone, Knockout, Angular, React, modifying the language itself, etc). There must be something profoundly different with the way I think. It even expresses itself in the function naming.…

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.

Re: A proposal to add signals to JavaScript

#75

Post by _heimdall »

I don't think signals will help move development away from further complexity, and that's really what we need today.

There's a fundamental question of why modern sites/apps reach for patterns like signals, memorization, hybrid rendering patterns, etc. I wouldn't begin to claim I have all the answers, but clearly there are gaps in the platform with regards to the patterns people want to implement and I'm not sure that jumping to signals as a standard helps better understand whether its the platform or our mental models that need updating to get back in sync.

Personally I've found code much easier to maintain when the frontend is only responsible for state that truly is temporary and doesn't live on the back end at all. For me any persisted state belongs on the server, as does any rendering that depends on it. This largely makes signals unnecessary, very few apps have such complex temporary state that I need a complicated setup to manage it.

Re: A proposal to add signals to JavaScript

#76

Post by beezlewax »

_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…

What kind of side effects specifically?

Re: A proposal to add signals to JavaScript

#77

Post by dclowd9901 »

tambourine_man wrote: post #62

I’ve been trying for decades to understand why people find it so hard to keep track of state and update the DOM. Sure, it requires a bit of discipline, but it’s vastly simpler to me than whatever solution comes up every few years (Backbone, Knockout, Angular, React, modifying the language itself, etc). There must be something profoundly different with the way I think. It even expresses itself in the function naming.…

Decades is a long time. You must remember the complexities of updating the DOM between browsers, surely.

Keeping the DOM in sync with a data state isn’t too difficult but doing so in a highly performant (60 fps) way _is_ tremendously difficult. Especially when it comes to creating APIs that aren’t leaky but also not too cumbersome.

It would frankly be easier to just paint pixels to a canvas game-style, than translating changes to a living DOM tree.

Re: A proposal to add signals to JavaScript

#78

Post by duxup »

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.

You could work for 50 years and never need those… it just depends on what you’re creating / how many devs and so on.

I know some guys who over the years wrote their own framework. It works great… for them.

Re: A proposal to add signals to JavaScript

#79

Post by nullvoxpopuli »

tommiegannert wrote: post #71

Hmm, if we can optimize the reactive state management in all web apps, that sounds cool. If this is to be a base for VueJS, it should handle deep changes. They have a note about support Map and Set, but being able to to control depth is nice in VueJS. (I'd say watch() should be deep by default, since non-deep is an optimization that can lead to accidental inconsistent state.) Streams. Generally, I find RxJS backwards…

> it should handle deep changes.

these can be implemented in userland via proxy -- and I think probably should, as is proven by this collection of utils: https://twitter.com/nullvoxpopuli/status/1772669749991739788

If we were to try implementing everything as reactive versions, there'd be be no end, and implementations couldn't keep up -- by pushing reactive Map/Set/etc to userland/library land, we can implement what we need when we need it incrementally, built on the solid foundation of the signal primitives.

> since non-deep is an optimization that can lead to accidental inconsistent state.

conversely, deep-all-the-time is a performance hit that we don't want to be default. Svelte and Ember take this approach of opt-in-deep reactivity.

Re: A proposal to add signals to JavaScript

#80

Post by tambourine_man »

dclowd9901 wrote: post #77
tambourine_man wrote: post #62

I’ve been trying for decades to understand why people find it so hard to keep track of state and update the DOM. Sure, it requires a bit of discipline, but it’s vastly simpler to me than whatever solution comes up every few years (Backbone, Knockout, Angular, React, modifying the language itself, etc). There must be something profoundly different with the way I think. It even expresses itself in the function naming.…

Decades is a long time. You must remember the complexities of updating the DOM between browsers, surely. Keeping the DOM in sync with a data state isn’t too difficult but doing so in a highly performant (60 fps) way _is_ tremendously difficult. Especially when it comes to creating APIs that aren’t leaky but also not too cumbersome. It would frankly be easier to just paint pixels to a canvas game-style, than translati…

If you need 60fps you shouldn’t use the DOM. It’s not a game engine. Like you said, go with canvas.
Post reply on HN