FFS there's already something named signals, since c. 1972.
A proposal to add signals to JavaScript
201–210 of 336 posts
Re: A proposal to add signals to JavaScript
#202Am 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…
Definitely not. I prefer the vanilla version as well.
Re: A proposal to add signals to JavaScript
#203Earlier 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?
Not "stupid", but maybe hasty / shallow? Many SPAs are long-running, and memory leaks can accrue quickly, destroying performance.
Re: A proposal to add signals to JavaScript
#204When they added Promises to JavaScript, I bristled at the thought that I might have to start writing `new Promise` everywhere.
In practice, I can count on two hands the number of times I’ve written `new Promise`. What did happen, though, is I started to write `.then` a whole lot more, especially when working with third party libraries.
In the end, the actual day-to-day effect of the Promise addition to JavaScript was it gave me a fairly simple, usually solid, and mostly universal interface to a wide variety of special behaviors and capabilities provided by third party libraries. Whether it’s a file read or an api request or a build step output, I know I can write `.then(res => …)` and I’m already 50% of the way to something workable.
If this Signal proposal can do something similar for me when it comes to the Cambrian explosion of reactive UI frameworks, I am in favor! What’s more, maybe it will even help take reactivity beyond UI; I’ve often daydreamed about some kind of incrementally re-computed state tree for things other than UI state.
Re: A proposal to add signals to JavaScript
#205Looks 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");
something = "else";
some.thing = "else";
Re: A proposal to add signals to JavaScript
#206I’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.…
Preach brother! My sentiments exactly. And I've developed SPAs that are massively complex and highly interactive, and whatever problems these folks are referring to that stuff like this supposedly solves, I've not yet encountered.
Re: A proposal to add signals to JavaScript
#207Earlier quoted context omitted.
There is an interesting debate about React and signals in the comments of this article, between Dan Abramov and Ryan Carniato - https://dev.to/this-is-learning/react-vs-signals-10-years-la...
I read it until the point where he defends the idea that these two functions obviously do something completely different: function One(props) { const doubleCount = props.count * 2; return Count: {doubleCount} ; } function Two(props) { return Count: {props.count * 2} ; } It honestly made me wonder whether the article was dated April 1 and I’d been had. More generously, JS framework design is hard. If you’re ambitious…
There are those of us for which this actually makes sense. More sense than react anyway.
Re: A proposal to add signals to JavaScript
#208Why does it need to be a part of the language? This could be a library. There are such libraries. They are small, so including them in your code is no big deal. Adding this to the language should not even be a goal . Thinking that the current crop of JS UI libraries designed their signals in such a good way that it needs to become a part of the language is hubris. Signals have many possible implementations with diffe…
Good points. We don’t want the wrong thing. But we want the right one!
Reactive UI won. The main thing stopping me from using vanilla JS is the absolute explosion in complexity managing state for even small sized applications. To me, any reactive framework is better than vanilla, so perhaps there is a construct missing? Now that it’s been a decade or so, we should start thinking about possible cut-points for standardization. Like with promises, this could bring down complexity for extremely common use-cases, if done right.
I think a better way to evaluate it would be: “would this proposal be used by existing reactive frameworks?”. If not, why? What’s missing? What’s superfluous? What about lessons from UI annd reactivity from other languages? There’s a lot of fragmented experience to distill, but it’s a worthwhile endeavor imo.
Re: A proposal to add signals to JavaScript
#209Earlier quoted context omitted.
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?
Sure! Where I work we build very specialized, very low user count live remote non destructive testing software that can be run on a browser. Well, it used to be native, but clients complained a lot in part due to IT restrictions on updates. That means that we basically have to have a remote processing unit, sync the state with the front end at all time, and with the scanning equipment too. That means multiple different canvases and charts, different tabs etc that all contain state, need state to be updated sometimes in the background, and need to have consistent state changes. I don't do a lot of front end dev, but I did help in setting up our new inference module there as I'm in the AI/ML side and it would've been a nightmare to deal with even if I mostly did stuff in a webgl canvas. It was angular, which I don't really like, but is still much better than going vanilla.
I know it's pretty niche, but I'd say most non-trivial (blogs, CMS, forms) front ends handle a lot of state. If they don't, then they are relatively simple anyways. That's a generalization but still, you quickly hit the point where react/other framework becomes worth the complexity overhead versus the complexity of doing it in vanillajs
Re: A proposal to add signals to JavaScript
#210Am 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…
[deleted]