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

181–190 of 336 posts

Re: A proposal to add signals to JavaScript

#181

Post by catlifeonmars »

itsjustme2 wrote: post #89

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…

I think it’s worth avoiding a change in design when you pass some threshold of complexity. The vanilla JS approach has some scaling limitation in term of state graph complexity, and the problem isn’t the ergonomics above and below the threshold, but discontinuous change in ergonomics when you cross that threshold

Re: A proposal to add signals to JavaScript

#182

Post by catlifeonmars »

refulgentis wrote: post #161
shermantanktop wrote: post #159

Earlier quoted context omitted.

The rationale for it is the fact that multiple frameworks provide their own versions of this mechanism. The proposal is to relocate extremely popular and common functionality from framework space to the language/runtime space. The popularity of React is itself the rationale for the utility of this idea, and any terse version of the rationale is for show. Is that a good enough rationale? Maybe, maybe not, but you are…

Most importantly: OP is right re: vanilla example is most legible. Reading the proposal, I have no idea what this "Signal" word adds other than complexity. Less important: I really, really, really, really, am reluctant to consider that is something that needs standardizing. Disclaimer: I don't have 100% context if this concept is _really_ the same across all these frameworks. But frankly, I doubt it, if it was that s…

> But frankly, I doubt it, if it was that similar, why are there at least a dozen frameworks with their own version?*

Welcome to the fashion cycle that is JavaScript. Given a few years, every old concept gets reinvented and then you have half a dozen frameworks that are basically the same but sufficiently different so that you have to relearn the APIs. This is what I think standardization helps circumvent

A good standard library prevents fragmentation on ideas that are good enough to keep getting reinvented

Re: A proposal to add signals to JavaScript

#183

Post by eyelidlessness »

pavlov wrote: post #137
Fatalist_ma wrote: post #100

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

> I read it until the point where he defends the idea that these two functions obviously do something completely different

> [code]

> It honestly made me wonder whether the article was dated April 1 and I’d been had.

They don’t do anything different if your model of components is that they rerun. But that model is only one way to implement components, and JSX is unopinionated about semantics exactly like this. Intentionally, by design.

If you’re only familiar with React and other frameworks with a similar rendering model, of course it’ll be surprising that those two functions would behave differently. But if you’re familiar with other JSX implementations like Solid, you’ll spot the difference right away: components don’t rerun, only the JSX does. The first function will always render the same thing because `doubleCount` is set up on component creation and static for the remainder of the time the returned div is mounted.

You are welcome to prefer React’s model. It certainly has some cognitive advantages. But it’s not inherently the only correct model either.

Re: A proposal to add signals to JavaScript

#184

Post by zaphar »

djbusby wrote: post #24
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?

I've been using patterns like this for more than a decade. The thing that's hard is, down the road you could have a listener, which triggers a other event, then another event, which comes back to the first routine and now you got a listen-loop that won't quit. And it's hard to ensure that all listener don't cause that trigger cascade.

I like signals as primitive but in this particular case they make it roughly about as easy to create loops accidentally as events do. I don't think this problem gets better or worse with signals.

Re: A proposal to add signals to JavaScript

#185

Post by eyelidlessness »

vbezhenar wrote: post #96

I didn't understand the example in the linked README. // A library or framework defines effects based on other Signal primitives declare function effect(cb: () => void): (() => void); What library? What framework? I lost here. What's effect? effect(() => element.innerText = parity.get()); How does effect knows that it needs to call this lambda whenever parity gets changed? Will it call this lambda on any signal chang…

> How does effect knows that it needs to call this lambda whenever parity gets changed?

Basically all implementations of signals (by whatever name) build a dynamic dependency graph, where edges are established by reading nodes. In a tracking context like this hypothetical `effect`, the read also establishes an edge between the signal’s state node and the effect’s computation node—effectively subscribing the latter to subsequent writes to the former, in order to determine when to rerun the computation.

Re: A proposal to add signals to JavaScript

#186

Post by tambourine_man »

pquki4 wrote: post #174
tambourine_man wrote: post #80

Earlier quoted context omitted.

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

60fps is not a high bar. A timer that gets updated every 10 millisecond (or in truth whatever the next event loop interval) is commonly used as tutorial, and there is no reason such a widget does not have a high refresh rate. The point of the original comment is that DOM updates should be fast, efficient and avoid visible delays to user's eye, which is not easy. If you are not careful, small changes in a large applic…

I agree with all of it. I did recently a timeline with hundreds of elements, 3D transforms etc. Everything was smooth and not because I was particularly clever, but because browsers are fast. All direct DOM manipulation.

My complaint with modern frameworks is not FPS, but rather that a hello world often requires 20k files plus a compilation step and the upshot isn’t particularly clear to me. I’ve never been to one of its landing pages and thought: wow, that’s a problem I have and this looks like the perfect solution.

Conversely, I clearly remember the first time I saw jQuery. Loading content via Ajax and fading in when done, all in 3 lines of code and cross browser. I was sold at that very second.

Re: A proposal to add signals to JavaScript

#187

Post by Pufferbo »

andrewstuart wrote: post #172
Pufferbo wrote: post #169

Earlier quoted context omitted.

You don’t need to pass a Preact signal as a prop to get reactivity. If you’re using Preact, signal references will make your component reactive by default, and if you’re using React you can introduce reactivity by way of the useSignals hook or a Babel plugin. (1) React signals have become my go to state management tool. So easy to use and very flexible. 1: https://www.npmjs.com/package/@preact/signals-react

>> React signals have become my go to state management tool. I've ditched almost all state in my React apps except state local to the component. Custom events do all the work for passing information around the application and directing activity. What do signals give me that events do not?

I’m also a fan of local state, but there are some cases where it makes sense for a bit of global state - mainly user context.

However you can use signals for local state as well and they work amazingly. Being able to assign a new value to a signal without having to go though a setter is a way cleaner pattern, in my opinion.

The other use cause is for communication between micro frontends. It’s so nice to just be able to import/export a signal and get its reactivity. Before them, I would create a pub/sub pattern and that’s just not as clean.

Re: A proposal to add signals to JavaScript

#188

Post by tambourine_man »

zero_shift wrote: post #175
tambourine_man wrote: post #74

Earlier quoted context omitted.

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.

I think it would help if you mentioned the kinds of applications you're building. What do you mean by "web apps" here? My memory of the web in 1999 was that the only rich web UX was in Java applets

There was this thing called DHTML. It was no Ajax, but you could hide and show elements, change its contents, respond to events, etc. Cross browser was a nightmare. And the server side handled most of the work.

Today I build all sorts of things with lots of interactive elements on the frontend, but trying to avoid using React if I can.

Re: A proposal to add signals to JavaScript

#189

Post by briantakita »

zero_shift wrote: post #173
berkes wrote: post #149

Earlier quoted context omitted.

Yes. It is. And most pub/sub or Observer architectures and design patterns have the "loop" thing solved just fine. In fact, the GOF spend an entire paragraph on the problem of complex update semantics in "design Patterns" (1995) ch Observer p299. So, while it is a real problem, it's one that has been solved (for at least 29 years)

In fact I solved a similar issue in my JS reactive micro library in just 500 bytes: https://github.com/jbreckmckye/trkl

I was not aware of trkl. Well done! I wrote rmemo (Reactive Memo) which solves the same problems & is a similar size. Different semantics though.

https://github.com/ctx-core/rmemo

Nanostores is also small https://github.com/nanostores/nanostores.

And if you only need reactivity in the browser (not server side), VanJS is small & includes reactive primitives. https://vanjs.org/

Re: A proposal to add signals to JavaScript

#190

Post by imbnwa »

bastawhiz wrote: post #120
ivanjermakov wrote: post #13

Is dependency tracking problem statically solvable (without calling effect once and subscribing to all .get's)? I don't think this needs to be a language feature, rather abstraction of existing features. In other words, can't this be a library? I know that SolidJS is able to figure out dependent signals, but probably doing so on the first execution.

> In other words, can't this be a library? You answered your own question: > I know that SolidJS is able to It already is, obviously. But how is SolidJS supposed to work with other non-SolidJS code? It can't. Unless every library builds support for every other library, they can't possibly interoperate.

> It already is, obviously. But how is SolidJS supposed to work with other non-SolidJS code?

Who actually writes code like this? People use some signal graph library for application code typically, I’ve never seen anyone mixing SolidJs with MobX in application code or as a consequence of a library dep.

Post reply on HN