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

61–70 of 336 posts

Re: A proposal to add signals to JavaScript

#61

Post by dclowd9901 »

__s wrote: post #7

Promises are a nice success story, but without async/await it wasn't really necessary to standardize > The current draft is based on design input from the authors/maintainers of Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz, and more… Would be interested what existing library authors think of this proposal. Interesting that React is not in that list Signals are a bit like c…

React isn’t in this list because its effects are declarative, not imperative (except for props changes and re-renders which you could argue are in fact declarative, just one abstraction removed). UseEffect neatly compartmentalizes imperative behavior.

This looks a lot like ember data binding which becomes an imperative nightmare. Its default state is “foot gun” with tons of cognitive overhead and meta patterns to keep it from getting that way.

Re: A proposal to add signals to JavaScript

#62

Post by tambourine_man »

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. They call updating innerText “render”. You’re not rendering anything. At most, the browser is, but so is everything else it does related to painting. It feels like a desperate attempt to complicate what is one of the simplest DOM functions. It really baffles me.

Re: A proposal to add signals to JavaScript

#63

Post by tqwhite »

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.

Re: A proposal to add signals to JavaScript

#64

Post by beders »

I've been enjoying "signals" in the form of re-frame subscriptions for many years now.

They solve a neat subset of problems in front-end developments. But they don't solve all of them.

Adding it to JavaScript as language construct is unnecessary.

Re: A proposal to add signals to JavaScript

#65

Post by leptons »

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?

The problem is if you don't close the tab, the memory leak can cause that one tab's memory to balloon to 1GB or more because memory isn't being released, when that tab should only be consuming 50MB.

Re: A proposal to add signals to JavaScript

#66

Post by dclowd9901 »

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

One big problem is right now they are _tremendously_ slow to use. (At least through the Proxy native class). Not sure if this is an artifact of JITs or the nature of prototypal inheritance.

Re: A proposal to add signals to JavaScript

#67

Post by polynomial »

senoralligator wrote: post #3

Surely it would be better to fix the interoperability issues of the language? "Lets just add a single implementation of everything to the standard!" seems like quite a strange response to "users of the language are having trouble with interoperability due to false coupling."

Isn't this similar to small core vs large core debates you see in other projects, often where drivers are concerned? (ie question around where the coupling layer is materialized)

Re: A proposal to add signals to JavaScript

#68

Post by duxup »

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.

Re: A proposal to add signals to JavaScript

#69

Post by Waterluvian »

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.

I dunno. I sometimes feel the same, but a whole ton of recent features have been incredible at cleaning up code.

?? Is my favourite.

I also want set functions and possibly a match statement thingy.

Re: A proposal to add signals to JavaScript

#70

Post by zdragnar »

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?

It depends on how much you're leaking, and how fast.

Best case scenario, it just slows down garage collection a little bit, as you're holding into a lot of references that aren't going anywhere.

On the other hand, I recall a bug in a particular version of AngularJS where component DOM nodes wouldn't get cleaned up when navigating with the router unless you manually set all of the scope values their templates used to null.

We had a data dense application with tables and what not, and you could clearly watch memory jump tens or more megabytes flipping between pages in the chrome dev tooling.

Eventually (this was a SPA intended to be used for upwards of hours at a time) the page would crash.

Post reply on HN