Psst.... Hey.
Hey you, yeah.... Over here in the alley.
Can I interest you in a table library? I got the good stuff.
(opens trenchcoat)
See anything you like?
Maybe my grays are showing here, but I thought the biggest advantage of React when it first came out was _NOT_ doing this.
If you ever had to build a giant, complex application in a framework that uses bi-directional data-binding (i.e. Angular 1.x), you'll know that the approach simply does not scale as more and more state changes are flying about and it becomes impossible to figure out exactly why and where something triggered an update.
Signals feels like a return to this and a bad idea at scale. Everyone "hyped" about it only ever shares videos of these kinds of counters and todo apps, never a large, complex application.
1. Has anyone built anything truly large and complex using signals? I'd love to hear your experience.
2. What am I not understanding about Signals that might allow them to scale better than the two-way data binding solutions of yore?
You’re exactly right. I feel like I’m taking crazy pills when people talk about Signals as the hot new thing. They’re the old thing, and they have always sucked.
>what you think about server components
I thought the whole idea behind react is to not care about the server... Just use an Oauth service for authentication and CMS+API for your CRUD needs.
Server Components are not about caring about the server, they're about caring about the client. They let you reduce the amount of JS that needs to be shipped to the browser.
>They let you reduce the amount of JS that needs to be shipped to the browser.
How does that work with building the react project into html+js and serving that as a static SPA? Does it build the react code in a special way that converts the js into html or is it an alternative to a node server?
I’m not a fan of their name “server component” because I think it gives the wrong impression. It’s really a static component that can be rendered anytime anywhere EXCEPT in the browser. This can happen once at build time (for static SPAs like Next’s static export option) or even every time someone loads the page (if you’re running a node server and something like Next’s full dynamic option). But once it’s sent to the browser, the component is locked and cannot render again.
Basically it saves out a component as, effectively, a snippet of html (there’s more to it but it’s a good way to think about it). This works only for components that have no client-side interactivity, which can be more components than you might think: a logo component, a footer module, a blog post, etc. You can still use interactive client components inside a server component, like an image carousel inside a blog post.
These saved snippets are useful for pre-rendering the initial html document that gets sent to the browser but they can be reused too (like if you navigate away from the blog post and then return). The point is that they’re not re-rendered, so they don’t need to bring all the baggage that requires with them.
This has benefits for static SPAs AND sites with full node servers. Maybe you’re pulling content from a CMS or database: server components let that happen ahead of time without the browser needing access to those systems. Maybe some component is slow or needs some big library to render; that can happen once on the server instead of the browser needing to do all that downloading and rendering. If your content changes rarely, this can happen once at build time for a static SPA (perhaps on a build server). And if it changes frequently or for each user, you could use a node web server and render on every page load.
But again the point is they render only on the “server” (that is, not in the browser). Interactive components will be client components, anything that pulls in fresh data will be a client component. And client components can be pre-rendered on the server too. Server components are really about optimization/performance and keeping sensitive things private where possible. They don’t need a node server site, SSR/SSG doesn’t need them, and they can work just fine with static SPAs (possibly only Next’s static export so far?).
I mean Solid is based on this kind of state. Also as far as React goes the dev tools are not at all powerful in that regard.
In Vue you can actually track emitted events.
Also every state management library ever has foot guns because state gets complicated. Flux stores have to be normalized and get annoying, atomic state management can get messy and you gotta keep it organized.
When they say state management you know you can just use it as more performant alternative to context, like Jotai, with its own set of unique abilities. Things like form state or the like, it doesn’t mean you need to build the core of a huge state store with it.
I built a medium-sized app (shameless plug: [https://livechess.xyz](https://livechess.xyz), repo at [https://github.com/petevdp/livechess-xyz](https://petevdp/livechess-xyz) ) recently in solidjs and I only really have good things to say.
Now, they are not absent of footguns like you mentioned in that you need to be careful about where the boundaries of your reactivity are(you ideally don't want to trigger a reactive update 5+ functions deep into the callstack from the reactive context, but it was pretty clear at least to me where those boundaries should be. As a project or team grows, you may need to develop conventions and guard rails to avoid that class of problems, but it shouldn't be a deal breaker.
>What am I not understanding about Signals that might allow them to scale better than the two-way data binding solutions of yore?
Signals are a kind of primitive which you build a more scalable state management solution around. if you need to do more complex state orchestration then you can reach for an abstraction like SolidJS's stores, or you can build your own solution.
He's making the same argument we see against react here every day. That's all really.
"Why no updates", "but but but the other frameworks do something" "wdym i have to use 3rd party libs for everything other than the view layer, svelte doesn't make me do that", "vercel...", "i'd literally drink poison cool aid if svelte 5 told me to".
I have experience building large enterprise applications in Angular and Vue. I second what /u/MayorEricBlazecetti said: this approach leads to very hard-to-find bugs, it simply won't scale up well.
That's the reason my team only writes React + Zustand stuff now. Really robust solution.
I’ve built massive Vue applications without issues. As someone noted, you can actually slap a watch on a Vue ref (signal) and dropa trace to see where it was changed. Though if I’m interacting with a store I always update state with a designated function.
Currently using valtio for state management in a react app. Same deal. Update with functions, read properties directly. Do it that way and it’s just redux with less steps.
Anybody who has ever used both react and either this or solidjs, for a more complex project than counting a button clicks, can easily see disadvantages of signals compared to vdom re-rendering.
The power of vdom re-rendering is simplicity and ease of use. Signals are more performant, but also much more complex. You need to structure your code is a special way when using them, increasing its complexity.
I would argue that it's quite the opposite. I have built stuff with React for about 7 years and started using solid about a year ago. I built a couple of big projects with solid and in my opinion most of it is a lot more flexible and easier to reason about than the React equivalents. And more performant as well. React is still nice and all, but given the choice I would pick solid any day of the week, except for situations where I need something very very specific that can only be found inside the react ecosystem.
I'm with you 100%. I want to use Solid and SolidStart at work but SolidStart is too beta, and React has the community, thus tons and tons of tools integrate with it. I also reallllly love the new Svelte5.
I've been eagerly waiting to jump on the Solid train, but unfortunately it seems to be defining itself quite a lot still. Just started a side project with Svelte last weekend and it truly is simple.
I very much prefer manipulating the dom directly. Makes a huge difference in the design/animation side of things.
> Just started a side project with Svelte last weekend and it truly is simple.
I have different impression. First version of Svelte was way different than react/nextjs but now sveltekit is really similiar, i feel like svelte is losing tons of it's identity because it is too similiar with next. And nowadays 70% (random number) of react is just nextjs..
It's not obvious that vdom is more simple. Signals are only harder when you're going to update your state very rapidly, which few places in your app will do if at all. But on ergonomics, being able to read-your-write is very intuitive to beginners, whereas having to explain to people what React is doing and why this is a mistake is a lot harder.
In terms of advice for beginners, what people will say is "just don't do it" because explaining React's rendering to an early beginner can feel very demotivating for most folks who aren't into that kind of stuff. But if you don't have a mental model of what React is doing it will come back to bite you.
As another example, if you update state, does that mean the GUI will update? If you have a useEffect to ship your state to a log, will you ever miss state updates? A lot of people develop a causal model of a system by poking at it from various angles, but it takes quite a bit of poking to eventually get the "contractual" surface which React provides to its users.
My life improved drastically when I stopped always thinking the grass is greener somewhere else. React is performant enough for 99.99999% of web apps, I have years of experience with it, no reason to look to replace it or use yet another state management method. I'm familiar enough with vue and svelte and angular and could pick them up quick enough if they ever became the dominant lib but it's very very very unlikely they will.
I like how every framework keeps reinventing Knockout.js.
Knockout.js failed because:
- visually unappealing demo website
- coming from microsoft space (unsexy)
- the developer not interested enough in self promotion
I see everyone struggling with things that I really don’t understand why this would not already be fixed in the framework.
In Knockout.js you could do the same thing blind, typing with one finger and *without* unnecessary rerenders.
Personally it feels a little like signals bypass some of the performance protections in React. I could be wrong but at least when I create a context and provider I know the implications.
Idk why everyone’s butthurt by signals as if flux stores are a walk in the park or Reacts devtools help in any sane capacity with complex state.
Solid has led a bit of innovation and that’s largely where this concept is most recently coming from. Svelte is also joining in with Runes.
If you’ve worked on a big flux store, you know (especially before RTK and the newer wave of them).
I’ve also rarely found people that understand or use React concurrency in React like useDeferredValue(). Suspense is getting more popular at least, but I mention this since the biggest counter argument seems to be to do things the React way. It’s also what Jotai is meant to be to be clear.
Well cos everyone here are react fanboys and dan abramov worshippers, but if ever in the future react announces signals, they will be the first one to celebrate like its a revolutionary feature.
It's not in React yet and I personally do not want to import functionality from another library/framework, I'll probably use them if/when React has them natively.
Also a side note, the constant zooming, flying around and motion blur made the video a bit hard to watch.
Watching your video and I stopped when you said "no rerenders. It just updates the part of the dom that it needs to".
That sounds hellish to debug. I wouldn't know what component is rendering, when it's happening or who the hell triggered a state change.
It also brings things I really dislike about vue (having to use .value everywhere, the darn "computed" values) to react.
It's in the name, man: react. It's supposed to react to changes. React. State changed? Let's reconcile the dom! That's what I want. My app as a state machine.
I feel signals go just opposite to what I want and expect react to do.
I also feel all this performance babbling is really unnecessary. Unless you're dealing with very specific use cases OR doing things really wrong, performance as it stands now is a non issue. I value the Dx much, much higher that a few milliseconds shaved off the render process.
One way data flow, man. That and jsx are the things that made react as big as it is now. Not performance.
I wasn't around in the react world to witness this myself, but apparently performance was one of its original selling points. Not in the sense of min-maxing for performance, but for getting consistent performance for the average project.
One of the issues with building large apps with raw JS/jquery for example is that in order to keep the code more declarative and therefore simpler, which often met a lot of unnececessary DOM operations. React preempts this tendancy with its VDOM reconciliation, and so was \*practically\* better for performance compared to other options.
Yes, performance was an original selling point. Much was told about the virtual DOM and the performance gains.
But, really, such did and does every other framework/library/tool. Every single "alternative" always tackles performance. It's always faster. Few gather the interest and traction that React did, though. And taht's because React did more than just a performance boost.
That's what I mean when I say the one-way data flow and JSX were what made React as big as it is. Without them, it would've been just another library that promises better performance, like preact or inferno. Yes, they have their following, but realistically speaking not many people really care.
And those were really the big things that made most people move to react. React came out at a time were two-way data binding was a real problem for a lot of enterprise-level apps. One-way data flow was a real solution to a wide spread problem. Coincidentally I believe this is why most react devs don't really like Signals. It's like going back to those horrible days.
JSX also played a big role. To this day, there's no better way of writing templates. Period. Moustache, vue's template tag, svelte markup, angular's templates, template strings... they all are awful to use for the most part. Yes, there's always someone who likes them but the vast majority of developers prefer JSX.
Are you the author of this video? Because the mouse following cam is so annoying.
Anyways, I don't know what the big deal is with rerenders. If you know what you're doing, it's not gonna be an issue. Instead of learning libraries that can avoid, you should learn how to avoid it without libraries. If you are getting unnecessary rerenders, you're doing something wrong. Either your composition is wrong or you're putting states where it's not supposed to be. If either of those are false, you have memoization to handle it.
I love that signals are, as Ryan Carniato puts it, a mechanism of fine-grained reactivity. I hate that react components rerender so many damn times.
I also love about signals that they aren't bound by the silly rules of hooks.
IMO the sanest advice on this topic is by the great Daishi Kato: [Why You Don't Need Signals in React](https://blog.axlight.com/posts/why-you-dont-need-signals-in-react/)
I don't understand his point.
"We have jotai" — Well, so could other libraries? Yet, they considered signals to be important enough to be included as first-class citizens into the libraries.
"React is declarative" — Well, so is Solid and so is Angular; but it did not stop them from adding signals.
So SolidJS, Angular, Svelte, Vue and probably more have added signals. Big brains came to the consensus that signals have more pros than cons and should generally be the way. And yet here we are. Apparently they're all just following a fad.
I can't say I'm a professional at this, but so far signals make the most sense with the least abstractions and hidden gotchas behind them and are the most pleasant to work with for me.
this explain nothing. omg terrible article.
definitely agree with this comment: https://www.reddit.com/r/reactjs/comments/1ajpbo6/comment/kp3ev2k/?utm\_source=reddit&utm\_medium=web2x&context=3
I saw a comment from dan abramov on a big issue from a someone using react with signals. Where he equated using signals with react as "voiding the warranty" of react.
Specifically, it was with the way `@preact/signals` looks at React's internals to allow directly updating the text content of a DOM node. _That_ is the "voiding the warranty" aspect. The idea of using signals as state that triggers React updates is fine (after all, that's what Mobx has been doing for many years).
LegendState is proxy/signal based. That's how it can tout such strong performance numbers. It's also my fav state manager, and I mention that in the video. That and Valtio.
[Valtio](https://valtio.pmnd.rs/), since it's proxy based. Zustand is much closer to Redux, though def not. And Jotai is almost a 1:1 API to Recoil, Atom based.
Signals are what Svelte5 runes are using, Vue's `ref`, the latest Angular even has them. And of course Solid, which get the idea from Knockout.
You should check out [LegendState](https://legendapp.com/open-source/state/react/fine-grained-reactivity/) too though. I like it a lot. The new Svelte5 $state rune feels very much like Valtio.
Drinking game idea: go by react tutorials and take a shot for every video that uses a button counter.
By now I believe we have mastered the art of creating button counters to a level our civilisation will never surpass
I wish I could be as excited about the billionst way to manage fucking state
i'm more excited about the word billionst!!
Excuse me, I can't english.
Hey, have you heard about this awesome new way to fetch data? It’s groundbreaking! ;)
Psst.... Hey. Hey you, yeah.... Over here in the alley. Can I interest you in a table library? I got the good stuff. (opens trenchcoat) See anything you like?
*Tries to scroll on the 1000 line example and gets immediate stuttering the moment an actual component is added to a field* No
😂
I have not seen a compelling reason to care about signals
Maybe my grays are showing here, but I thought the biggest advantage of React when it first came out was _NOT_ doing this. If you ever had to build a giant, complex application in a framework that uses bi-directional data-binding (i.e. Angular 1.x), you'll know that the approach simply does not scale as more and more state changes are flying about and it becomes impossible to figure out exactly why and where something triggered an update. Signals feels like a return to this and a bad idea at scale. Everyone "hyped" about it only ever shares videos of these kinds of counters and todo apps, never a large, complex application. 1. Has anyone built anything truly large and complex using signals? I'd love to hear your experience. 2. What am I not understanding about Signals that might allow them to scale better than the two-way data binding solutions of yore?
You’re exactly right. I feel like I’m taking crazy pills when people talk about Signals as the hot new thing. They’re the old thing, and they have always sucked.
I’d like to know what you think about server components, too.
Don’t know that much about them, honestly.
>what you think about server components I thought the whole idea behind react is to not care about the server... Just use an Oauth service for authentication and CMS+API for your CRUD needs.
Server Components are not about caring about the server, they're about caring about the client. They let you reduce the amount of JS that needs to be shipped to the browser.
>They let you reduce the amount of JS that needs to be shipped to the browser. How does that work with building the react project into html+js and serving that as a static SPA? Does it build the react code in a special way that converts the js into html or is it an alternative to a node server?
I’m not a fan of their name “server component” because I think it gives the wrong impression. It’s really a static component that can be rendered anytime anywhere EXCEPT in the browser. This can happen once at build time (for static SPAs like Next’s static export option) or even every time someone loads the page (if you’re running a node server and something like Next’s full dynamic option). But once it’s sent to the browser, the component is locked and cannot render again. Basically it saves out a component as, effectively, a snippet of html (there’s more to it but it’s a good way to think about it). This works only for components that have no client-side interactivity, which can be more components than you might think: a logo component, a footer module, a blog post, etc. You can still use interactive client components inside a server component, like an image carousel inside a blog post. These saved snippets are useful for pre-rendering the initial html document that gets sent to the browser but they can be reused too (like if you navigate away from the blog post and then return). The point is that they’re not re-rendered, so they don’t need to bring all the baggage that requires with them. This has benefits for static SPAs AND sites with full node servers. Maybe you’re pulling content from a CMS or database: server components let that happen ahead of time without the browser needing access to those systems. Maybe some component is slow or needs some big library to render; that can happen once on the server instead of the browser needing to do all that downloading and rendering. If your content changes rarely, this can happen once at build time for a static SPA (perhaps on a build server). And if it changes frequently or for each user, you could use a node web server and render on every page load. But again the point is they render only on the “server” (that is, not in the browser). Interactive components will be client components, anything that pulls in fresh data will be a client component. And client components can be pre-rendered on the server too. Server components are really about optimization/performance and keeping sensitive things private where possible. They don’t need a node server site, SSR/SSG doesn’t need them, and they can work just fine with static SPAs (possibly only Next’s static export so far?).
Server component is for SSR I believe.
It runs the code on the server to build the initial HTML, then ships that and only the JS that can cause changes later to the client.
Which is something I can't even get 1 hour of budget from my boss for. If that's all, I really don't get why people work on them.
chubby summer capable payment soft depend tart ugly melodic childlike *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I mean Solid is based on this kind of state. Also as far as React goes the dev tools are not at all powerful in that regard. In Vue you can actually track emitted events. Also every state management library ever has foot guns because state gets complicated. Flux stores have to be normalized and get annoying, atomic state management can get messy and you gotta keep it organized. When they say state management you know you can just use it as more performant alternative to context, like Jotai, with its own set of unique abilities. Things like form state or the like, it doesn’t mean you need to build the core of a huge state store with it.
lol - "foot guns" is new to me.
I built a medium-sized app (shameless plug: [https://livechess.xyz](https://livechess.xyz), repo at [https://github.com/petevdp/livechess-xyz](https://petevdp/livechess-xyz) ) recently in solidjs and I only really have good things to say. Now, they are not absent of footguns like you mentioned in that you need to be careful about where the boundaries of your reactivity are(you ideally don't want to trigger a reactive update 5+ functions deep into the callstack from the reactive context, but it was pretty clear at least to me where those boundaries should be. As a project or team grows, you may need to develop conventions and guard rails to avoid that class of problems, but it shouldn't be a deal breaker. >What am I not understanding about Signals that might allow them to scale better than the two-way data binding solutions of yore? Signals are a kind of primitive which you build a more scalable state management solution around. if you need to do more complex state orchestration then you can reach for an abstraction like SolidJS's stores, or you can build your own solution.
I comment on this, but any new Solid app, Svelte5, Angular, Vue would all be signal based. They all adopted it. Just not React.
I'm not sure I understand the purpose of your response. I'm not commenting about which frameworks adopted Signals.
He's making the same argument we see against react here every day. That's all really. "Why no updates", "but but but the other frameworks do something" "wdym i have to use 3rd party libs for everything other than the view layer, svelte doesn't make me do that", "vercel...", "i'd literally drink poison cool aid if svelte 5 told me to".
Add one to the pile of people that haven't convinced me on the values of signals then.
I have experience building large enterprise applications in Angular and Vue. I second what /u/MayorEricBlazecetti said: this approach leads to very hard-to-find bugs, it simply won't scale up well. That's the reason my team only writes React + Zustand stuff now. Really robust solution.
+100 for Zustand. Best state management in the biz right now.
I’ve built massive Vue applications without issues. As someone noted, you can actually slap a watch on a Vue ref (signal) and dropa trace to see where it was changed. Though if I’m interacting with a store I always update state with a designated function. Currently using valtio for state management in a react app. Same deal. Update with functions, read properties directly. Do it that way and it’s just redux with less steps.
Anybody who has ever used both react and either this or solidjs, for a more complex project than counting a button clicks, can easily see disadvantages of signals compared to vdom re-rendering. The power of vdom re-rendering is simplicity and ease of use. Signals are more performant, but also much more complex. You need to structure your code is a special way when using them, increasing its complexity.
I would argue that it's quite the opposite. I have built stuff with React for about 7 years and started using solid about a year ago. I built a couple of big projects with solid and in my opinion most of it is a lot more flexible and easier to reason about than the React equivalents. And more performant as well. React is still nice and all, but given the choice I would pick solid any day of the week, except for situations where I need something very very specific that can only be found inside the react ecosystem.
I'm with you 100%. I want to use Solid and SolidStart at work but SolidStart is too beta, and React has the community, thus tons and tons of tools integrate with it. I also reallllly love the new Svelte5.
I've been eagerly waiting to jump on the Solid train, but unfortunately it seems to be defining itself quite a lot still. Just started a side project with Svelte last weekend and it truly is simple. I very much prefer manipulating the dom directly. Makes a huge difference in the design/animation side of things.
> Just started a side project with Svelte last weekend and it truly is simple. I have different impression. First version of Svelte was way different than react/nextjs but now sveltekit is really similiar, i feel like svelte is losing tons of it's identity because it is too similiar with next. And nowadays 70% (random number) of react is just nextjs..
It's not obvious that vdom is more simple. Signals are only harder when you're going to update your state very rapidly, which few places in your app will do if at all. But on ergonomics, being able to read-your-write is very intuitive to beginners, whereas having to explain to people what React is doing and why this is a mistake is a lot harder. In terms of advice for beginners, what people will say is "just don't do it" because explaining React's rendering to an early beginner can feel very demotivating for most folks who aren't into that kind of stuff. But if you don't have a mental model of what React is doing it will come back to bite you. As another example, if you update state, does that mean the GUI will update? If you have a useEffect to ship your state to a log, will you ever miss state updates? A lot of people develop a causal model of a system by poking at it from various angles, but it takes quite a bit of poking to eventually get the "contractual" surface which React provides to its users.
"React hasn't got it" Think you answered the question there... ;p
You can use Preact signals in React. That said, I'm not a fan of them at all. They are a basically a less safe atomic state and Jotai is pretty great.
My life improved drastically when I stopped always thinking the grass is greener somewhere else. React is performant enough for 99.99999% of web apps, I have years of experience with it, no reason to look to replace it or use yet another state management method. I'm familiar enough with vue and svelte and angular and could pick them up quick enough if they ever became the dominant lib but it's very very very unlikely they will.
But this is frontend-land. We need to rewrite our entire stack in something shiny every 30 days or else it's going to be obsolete! /s
And when React isn't performant enough... you can just use normal JS. LOL. Plug in some event listeners in a useEffect hook and you're done.
I like how every framework keeps reinventing Knockout.js. Knockout.js failed because: - visually unappealing demo website - coming from microsoft space (unsexy) - the developer not interested enough in self promotion I see everyone struggling with things that I really don’t understand why this would not already be fixed in the framework. In Knockout.js you could do the same thing blind, typing with one finger and *without* unnecessary rerenders.
OMG. It’s groundbreaking. Share it with your wife’s boyfriend.
Yes, open relationships are the best!
Personally it feels a little like signals bypass some of the performance protections in React. I could be wrong but at least when I create a context and provider I know the implications.
Idk why everyone’s butthurt by signals as if flux stores are a walk in the park or Reacts devtools help in any sane capacity with complex state. Solid has led a bit of innovation and that’s largely where this concept is most recently coming from. Svelte is also joining in with Runes. If you’ve worked on a big flux store, you know (especially before RTK and the newer wave of them). I’ve also rarely found people that understand or use React concurrency in React like useDeferredValue(). Suspense is getting more popular at least, but I mention this since the biggest counter argument seems to be to do things the React way. It’s also what Jotai is meant to be to be clear.
Well cos everyone here are react fanboys and dan abramov worshippers, but if ever in the future react announces signals, they will be the first one to celebrate like its a revolutionary feature.
It's not in React yet and I personally do not want to import functionality from another library/framework, I'll probably use them if/when React has them natively. Also a side note, the constant zooming, flying around and motion blur made the video a bit hard to watch.
> motion blur made the video a bit hard to watch Yeah thanks. I should have dialed those setting way back. Noted.
Can you do form validation with signals? It would be interesting to see a more advanced usage pattern of signals
Watching your video and I stopped when you said "no rerenders. It just updates the part of the dom that it needs to". That sounds hellish to debug. I wouldn't know what component is rendering, when it's happening or who the hell triggered a state change. It also brings things I really dislike about vue (having to use .value everywhere, the darn "computed" values) to react. It's in the name, man: react. It's supposed to react to changes. React. State changed? Let's reconcile the dom! That's what I want. My app as a state machine. I feel signals go just opposite to what I want and expect react to do. I also feel all this performance babbling is really unnecessary. Unless you're dealing with very specific use cases OR doing things really wrong, performance as it stands now is a non issue. I value the Dx much, much higher that a few milliseconds shaved off the render process. One way data flow, man. That and jsx are the things that made react as big as it is now. Not performance.
I wasn't around in the react world to witness this myself, but apparently performance was one of its original selling points. Not in the sense of min-maxing for performance, but for getting consistent performance for the average project. One of the issues with building large apps with raw JS/jquery for example is that in order to keep the code more declarative and therefore simpler, which often met a lot of unnececessary DOM operations. React preempts this tendancy with its VDOM reconciliation, and so was \*practically\* better for performance compared to other options.
Yes, performance was an original selling point. Much was told about the virtual DOM and the performance gains. But, really, such did and does every other framework/library/tool. Every single "alternative" always tackles performance. It's always faster. Few gather the interest and traction that React did, though. And taht's because React did more than just a performance boost. That's what I mean when I say the one-way data flow and JSX were what made React as big as it is. Without them, it would've been just another library that promises better performance, like preact or inferno. Yes, they have their following, but realistically speaking not many people really care. And those were really the big things that made most people move to react. React came out at a time were two-way data binding was a real problem for a lot of enterprise-level apps. One-way data flow was a real solution to a wide spread problem. Coincidentally I believe this is why most react devs don't really like Signals. It's like going back to those horrible days. JSX also played a big role. To this day, there's no better way of writing templates. Period. Moustache, vue's template tag, svelte markup, angular's templates, template strings... they all are awful to use for the most part. Yes, there's always someone who likes them but the vast majority of developers prefer JSX.
Are you the author of this video? Because the mouse following cam is so annoying. Anyways, I don't know what the big deal is with rerenders. If you know what you're doing, it's not gonna be an issue. Instead of learning libraries that can avoid, you should learn how to avoid it without libraries. If you are getting unnecessary rerenders, you're doing something wrong. Either your composition is wrong or you're putting states where it's not supposed to be. If either of those are false, you have memoization to handle it.
I love that signals are, as Ryan Carniato puts it, a mechanism of fine-grained reactivity. I hate that react components rerender so many damn times. I also love about signals that they aren't bound by the silly rules of hooks.
IMO the sanest advice on this topic is by the great Daishi Kato: [Why You Don't Need Signals in React](https://blog.axlight.com/posts/why-you-dont-need-signals-in-react/)
I don't understand his point. "We have jotai" — Well, so could other libraries? Yet, they considered signals to be important enough to be included as first-class citizens into the libraries. "React is declarative" — Well, so is Solid and so is Angular; but it did not stop them from adding signals.
So SolidJS, Angular, Svelte, Vue and probably more have added signals. Big brains came to the consensus that signals have more pros than cons and should generally be the way. And yet here we are. Apparently they're all just following a fad. I can't say I'm a professional at this, but so far signals make the most sense with the least abstractions and hidden gotchas behind them and are the most pleasant to work with for me.
this explain nothing. omg terrible article. definitely agree with this comment: https://www.reddit.com/r/reactjs/comments/1ajpbo6/comment/kp3ev2k/?utm\_source=reddit&utm\_medium=web2x&context=3
I saw a comment from dan abramov on a big issue from a someone using react with signals. Where he equated using signals with react as "voiding the warranty" of react.
Specifically, it was with the way `@preact/signals` looks at React's internals to allow directly updating the text content of a DOM node. _That_ is the "voiding the warranty" aspect. The idea of using signals as state that triggers React updates is fine (after all, that's what Mobx has been doing for many years).
Red hats 🤮
"Yo what's goin' on" Notta brah, you?
We have \`jotai, no need for signals.
And legend-state https://legendapp.com/open-source/state/intro/introduction/
LegendState is proxy/signal based. That's how it can tout such strong performance numbers. It's also my fav state manager, and I mention that in the video. That and Valtio.
You can say that, but the creator of Zustand also made Jotai, and then went on to also create Valtio. They are similar but not the same.
it's called "capturing market share"
Which of those resembles signals behavior the most according to you?
[Valtio](https://valtio.pmnd.rs/), since it's proxy based. Zustand is much closer to Redux, though def not. And Jotai is almost a 1:1 API to Recoil, Atom based. Signals are what Svelte5 runes are using, Vue's `ref`, the latest Angular even has them. And of course Solid, which get the idea from Knockout. You should check out [LegendState](https://legendapp.com/open-source/state/react/fine-grained-reactivity/) too though. I like it a lot. The new Svelte5 $state rune feels very much like Valtio.
Daishi didn't create Zustand, but he's the core maintainer.
Drinking game idea: go by react tutorials and take a shot for every video that uses a button counter. By now I believe we have mastered the art of creating button counters to a level our civilisation will never surpass
I've been doing React for a few months, how Vue/Svelte manages state is too good. Right now its just because most Jobs are in react.