Are Signals Worth the Hype? by Atila Fassina

[@vijaykumarreddyalavala3713]

Real talk starts at 04:00

[@jaydeep-p]

Thanks

[@samiullahsheikh5015]

Thanks

[@baka_baca]

🎉 thank you!

[@RusydyMuhiddin]

Thank you

[@Nikgek]

gigachad

[@farhan3d]

Hey Atila, nice to see you here and what a cool presentation! I will likely be working more in the JS / React domain going forward, so stumbled upon here. In case you didn't remember... I'm that certain PO that worked with you someplace for a somewhat brief period ;) All the best!

[@armanrozika]

one thing that opened my mind was when i realized that rendering (in vdom) != painting (in browser).

[@i-am-the-slime]

Cool talk. I like react. I use it from PureScript, it's great. I'm curious if I can make this work in PS

[@dinaiswatching]

Awesome! While every other JS framework already has support for signals in their latest versions, React's concern for implementing a compiler surely won't provide performance gains as we can see by that presentation.

[@maximus1172]

god i hate react lmao

[@neociber24]

I still don't see why React need to support signals. Would be nice, but how intensive need your app rendering be to it make any sense?

[@АртурУляшев-е1ь]

@@neociber24 to support fine grained reactivity in react you should monkeypatch React.createElement function so the only parent node will be rerendered (check how preact-signals did do it) and as Dan Abramov said React will never adopt signals and neither should react developers

[@AtilaDotIO]

@@neociber24 my point is that it's not about avoiding rendering or improving rendering performance. My point was about improving DX and UX by having a better way to understand how your framework handles your inputs and user's interactions. While React can reach decent performance without Signals, having a Pull based system implies a lot of code is written (by you or the framework) to protect such performance and it's really easy to fall out of those optimizations unknowingly. So, imho, signals are a better architecture to describe data in apps.

[@br3nto]

I’m dreading the Signals proposal in JS. The way signals are implemented force devs to write many wrappers around pretty much everything. This means it will always be just a library. There is a better abstraction that used to exists, which signals could be built on top of: Object.watch() and Object.observe(). It allows devs to register a callback that gets called whenever a variable value changes or whenever an object property changes. Just from that description you can see how signals can be implemented on top of that. What this gives library authors is clean minimal syntax to respond to changes in the app. E.g if variable data changes, re-render my table. It’s subtly different and lower level than signals. Signals track dirty state and have an update step. This is just “ when you do a variable assignment, your callback gets called”. There’s so separate methods for setting a value vs reading the current value. This means there are no wrappers upon wrappers upon wrappers. Library authors can make cleaner code, and opt in to signals if it’s actually needed, which most often it is not.

[@АртурУляшев-е1ь]

Why is useState only "pull" system according to Atila? useState is like signals but only setState pushes not to subscribers to this particular value but it tells vdom that current component should be rerendered and then vdom also like signals aggregates all the setState calls and then in rAF rerenders only components that are need to be rerendered under the hood the logic is pretty the same as signals so it's also push-pull system btw I hate react

[@AtilaDotIO]

Hello!😊 thanks for your question! `useState` is Pull-based exactly because it doesn't push to subscribers. The system has no idea what is being used. What happens on `setState` is that from the point in your tree where a state update is triggered, it tears down the whole branch and renders it again with the new data. In Push-Pull systems (like signals), when there's a data update, the subscribers are notified and only the value is updated. There's no teardown involved because the system can track exactly the point in which the data is. So this statement: > vdom also like signals aggregates all the setState calls is not true. The vDOM is completely removed and added again with the fresh data, regardless if it's a single element which has been changed. What the compiler is trying to do is memoize (cache) the components that _don't_ depend on that data and thus re-render less. But that doesn't mean it updates only the data that changes, it means that it will try to prevent adjacent components that have nothing to do with the data.

[@АртурУляшев-е1ь]

@@AtilaDotIO I'm talking about the logic of useState hook under the hood (implementation of signals and useState in react) I'm not talking about what parts of ui it rerenders (I know that whole function reruns again and whole branch is being removed)

[@AtilaDotIO]

@@АртурУляшев-е1ь the fact that the UI re-renders and reruns the whole thing is a consequence of it not being Push-based. So we can't argue how the API behaves without considering how it works under the hood. So, the TL;DR is: it works in a much much different way than Signals do, but it can reach similar performance if the right measures and preventions are put in place. Even if the performance can reach "close enough" levels, it will still be Pull-based though.

[@jeremytenjo]

Can you update and get the latest signal value outside react components and hooks?

[@AtilaDotIO]

Not sure I get the question. React components don't have signals. getting data update outside of your framework system may be possible, but it depends on the framework and tooling you're using to handle those states. In Solid it would be possible outside of "components" - but to have reactivity enabled, you'd need to be within a "reactive root", which we have a helper to allow you to declare them.

[@hakoo2700]

Dayumn! Loved it. I really enjoyed the svelte's implementation of signals (called runes as you mentioned), as always they focus on DX very verrry much. The whole "React" way of component style/structure should really start to change. I hope as every framework learned from solid to move towards signals, solid can take inspirations from others to move away from structuring components in a "React" way. I'm really eager to see that happen and what you comeup with (if its worth it)! What are your thoughts on svelte's implementation of signals? (specifically the DX and component structure)

[@br3nto]

7:20 push-then-pull: like a skinny web hook.

[@Fiercesoulking]

i rise my hand and say I'm not really hyped for something which is nearly undebuggable . You putting lambdas(anonymous functions ) into a blackbox. Lambdas alone aren't the icing on the cake because on very low level view they are function pointers which obscure where your actual function is and then this is hiding them on top of it. There more views to this: 1. The idea behind it only update parts of your code when its needed/ certain inputs are happening isn't new this is a common optimization strategy but most of the time without lambdas and nobody gave it a name because its trivial. 2. The whole concept is a bandage to the problem with the DOM tree and how webdevs want to change everything in it all the time and then have weird synchronization problems. You can argue who is to blame about it browser devs and international committees who natively only support webpages or webdevs who wants webapp.

[@andreilucasgoncalves1416]

Yeah, I was enjoying a lot my solidjs application until the createEffect created an infinite loop that was undebuggable

[@nustaniel]

I cry on the inside when I see people use a wrapper to write JavaScript.

[@ifeoraokechukwu1346]

He is truly biased. He's using useEffect() wrongly for the derived data. He can just calculate the derived data without useEffect() He can get the derived `double` state without useEffect() in react. Also, `setState(...)` in react isn't synchronous like in solidjs. To get the same result as in solidjs, move the console.log(...) to useEffect() and move the derived `double` data out of the useEffect() and delete the useState() for `doubleCount`

[@pratheeshp007]

He did mention about it, I think you missed it

[@AtilaDotIO]

@@pratheeshp007 thanks! @ifeoraokechukwu1346 the point of that exercise is a constrained way of reproducing real-life code. For simple states like that, it's absolute overkill - but in real world apps - those are exactly how they happen - long `useEffects` with multiple conditionals to sync in data. That's what I was aiming to reproduce. It still is beside the point of the `console.log` example though. The reason why React behaves different than Solid is because of how the scheduler works, not the state itself - it's a tradeoff that pretty all frameworks have between scheduling/batching updates vs doing than eagerly. At another talk I used Svelte for this. I am biased about Solid because I work on the team and so many pieces of Solid's developer experience I help shaped - naturally, I like it more. But I respect how others frameworks implement things and I go out of my way to present a fair comparison.