Beyond Signals: The Next Big Shift in Web Reactivity

I'm Ryan Carniato, author of SolidJS as you heard. I'm very happy to be speaking at this conference that appreciates 90s nostalgia as much as I do. But yeah, I want to talk today about a phenomenon that's been going around the front-end world for the past few years, signals, of course. And if you're not familiar, this is not the introduction. I've been giving that talk the last couple of years. But to summarize, you can think of it kind of like a spreadsheet. A normal assignment represents a moment in time. It means that on completion, variable A reflects the current sum. But if either B or C changes, you have to do the assignment again. This relationship does not hold, whereas with reactivity, it does. A will always be the sum of B and C, even as they change.

Signals are just a set of primitives to help represent the synchronization. And at the core, you just need to know three. Standard state, our namesake, signals. Drive state, in Solid, we call these memos. But they're pure computations based on state.

And then side effects, which is how we effect our world. Straightforward enough in concept, perhaps even familiar looking. But the consequences of using them go well beyond this. It's no secret that at this point, when I open sourced Solid JS back in 2018, signals were the furthest from most people's minds. They'd been around in JavaScript for I'd say better part of a decade at that point.

But had fallen out of favor, thanks to the React component model. Even the few libraries or frameworks with signals that had survived had sort of hidden them away under plain looking objects. But with Solid JS, that all kind of changed. And while we can't take complete credit for the shift, I'd actually say React itself, with its announcement of hooks shortly afterwards, saying data primitives are okay was really instrumental. It's hard to ignore the impact when pretty much every framework other than React has adopted signals first class at this point.

So great, right? End of story. No, I think we're just at the beginning of a much bigger change. And I'm not alone in this thinking. The post above is from one of the developers responsible for bringing signals to Angular. We're on the precipice of the biggest revolution in how frontend UIs have worked in over a decade. And I'm not talking about AI this time. AI makes it easier to build, but can only use the mechanisms available to it.

The way things are today, people still need to work at this level architecturally to solve certain kind of problems to get the most out of your applications. Signals are not new. We've been able to use them in every framework for years. Even React. MobX, anyone? Just having signals isn't enough. Signals are a mechanism for change. But how you use them makes all the difference. I'm going to approach this from a few directions.

The common thread of what makes signals powerful is the knowledge of the data graph that powers your application. With that, we can do incredible things that we wouldn't easily be able to do otherwise. I'll be talking today about the future a lot. Many of my code examples will be referencing upcoming features of Solid that may not have been officially released yet. Let's get into it. I'm going to start with performance, as that's both the easiest to talk about and arguably the least important. Adding signals, like adding any sort of state management, actually lowers the performance ceiling of your framework. Adding mobX or legend state or Jyoti to React or even signals to React isn't guaranteed to improve the performance in all cases. In fact, on average, it makes them slower.

Unfortunately, it doesn't work that way, as Joe Savona from the React team found out if you watched his talk from ReactConf recently. Adding signals, like adding any sort of state management, actually lowers the performance ceiling of your framework. You know, like the React compiler might allow you to write more optimal code, but it doesn't have a meaningful impact on the absolute performance. This is an excerpt from the JS framework benchmark, but it's pretty intuitive to realize this would be the case.

Adding mobX or legend state or Jyoti to React or even signals to React isn't guaranteed to improve the performance in all cases. In fact, on average, it makes them slower. You might be surprised. Because even with signals, they still have their whole system for doing their VDOM updates. You aren't escaping that. Sure, in some cases, you can avoid component re-renders, but optimal code would be doing that anyway without the additional overhead.

So the answer to how signals get better performance is fine-grained rendering. It's what you can get rid of. Using the React graph to only update what has changed. Components don't matter anymore. No virtual DOM. I need to thank Misko Hevery from Angular quick for this graphic. It doesn't tell the whole story, but it's a start. Think React, think Felt 3. Think most frameworks before about a year ago.

Picture some application where you need to pull state up high so it's available at multiple points like a shopping cart in the header and maybe a buy button deep in your page. You update the state, your trigger re-renders down the tree. Only the shopping cart really needs to update, but we do all of this extra work. Now what can you do? Well, we've heard this like a million times the last few years. Memoize. You can realize that the data you send down to the buy button isn't changing and only run the one path. Generally, this is what the React compiler does. It's what Felt 3 did. The thing is, if the cart has changed, there's no avoiding this rerunning all the components from the owner of the state down to that change.

We can prune branches that didn't change along the way, but the change has to reach its place in the UI. But what if you could just do that? Now you might be thinking, I can do that. My signals in React, et cetera. To a degree. The point is that the point in which you use the signal enters the tree and becomes the new root. However, with fine grain rendering, all props just work that way by default. You can declare the state in the top of your app, bottom, pass it through ten components to the exact same results. It doesn't need to rerun the whole component or any of its parents, just the parts that change. This whole category of will my component rerun goes away and performance composition becomes a nonconcern.

The takeaway, when the dependency is decided on read rather than write, your application has a lot more knowledge how to update. The other takeaway should be that absolute performance is not the most important thing. But I still want to highlight that it's real, and it's a product of architecture, not effort. This year, two other frameworks for the first time have joined us on the fine grain rendering train, Svelte and Vue. I think they've actually improved on our seven-year-old implementation. So, if we haven't been looking at performance in solid really for the last seven years, what have we been doing? Glad you asked. Lots of work into building out our ecosystem, but a decent amount of work to understand the implications of this render model. Everything from HMR to SSR to hydration had never been done before this model. We also built a meta framework, introduced the world to server functions back in 2022, and single-flight mutations back in 2024. But more recently, we've turned to our roots in Reactivity. Let's talk about the next topic, mutability. I think there's a lot of non-believers still in the audience.

There always are. Mutability is often seen as some evil, especially from the functional programming side of things. I looked online, and apparently they make T-shirts and stickers like this explaining how terrible it is. But this is one of those topics where compilers and VDOMs can't easily follow. It honestly is what started me creating solid.js. With mutability comes stable references. You don't need to clone everything along a path. It means less work, which is good for performance and good for your sanity.

They don't have a point in terms of unchecked mutation, but control mechanisms like read-write segregation, you know how to get that tuple when you make a hook, do 95% of the work here without being immutable. It isn't like immutability doesn't have its own issues with traceability. Ever so often, you hear a horror story where someone has used useEffect and DDoS themselves. Usually it's a business or a user racking up their infrastructure costs. But when it's Cloudflare itself, a company known for preventing DDoS, it gains a lot of attention.

This could have happened in any framework. Loss of referential equality on dependencies can cause signals to overexecute as well. But there's a reason this tends not to happen in fine-grained solutions. Many but not all signals, frameworks, have a mechanism for creating deep reactivity. It's an important part of the solution. In solid, we call them stores. They're proxies where each property has the potential of being its own signal. And this has consequences. A signal like state and react is generally immutable.

But a store being nested keeps references for what hasn't changed, so it becomes a mutable object. This is important because you don't want to overnotify when things change. If you update the street number on an address on a user, you don't need to tell the user it's changed. Each field updates independently. It's why the DDoS is less likely to happen, and why when you update the state of a done toggle in our silly to-do app, we don't need to rerun the component or do any diffing. The data can get to the leaves without recalculating everything in between.

Stores are much more important than managing granular updates. Some problems just lend to diffing. You get fresh data from a server. There's no shared references there. If one has to naively just set a single, it would rerun everything. A lot of benchmarks and examples from the early 2010s were like that. Stores give us this ability to automatically diff data and only update what has changed. But as you might have guessed, there's a reason vDOMs diff UI. What if you don't need to diff all the data? Diffing is pretty wasteful. Well, that's what the reactor graph is for.

We know what's being listened to. We don't need to diff all the data. We just need the data that has subscribers. Just picture it. You get fresh data, update from the server, replaces the old data, diffs along the path your app subscribed to, triggers updates in just the things that have changed, and no components rerun. Only exactly what needs to run updates. I've enjoyed working with stores so much over the past few years, I started realizing we're talking about a completely different type of reactivity that hasn't been as readily explored, and made me realize there are gaps. There are problems that require deriving granular data and places where you start from a single source but want to fork or split reactivity.

It's a waste to check every row when you're changing the selected class on a table. But it isn't always practical to include an isSelected on every row, especially when that data is shared in multiple places. Sometimes we just need to project reactive data onto other data without mutating the source. Sometimes we need to be able to create ephemeral extensions of that data, like merge and optimistic changes without committing them. So we developed a new primitive just for that. We call them projections.

And while you may not use them very often, they represent a space that we've never really had a good solution before in front-end frameworks. A primitive that is both granular and derived. Being derived is important because it removes the need for synchronization and using effects to write state. Effects should really be the end of the loop. The exit of the system. It means that mutating it won't mutate the underlying source. Being granular is important as it means we finally have a way to fork reactivity.

Signals converge. Different sources all kind of come together into computed values. Projections expand and split reactivity back into multiple different sources. If that isn't clear to you, that's OK. I will show this off a little bit later. Speaking of reducing the need for most side effects, it can be pretty clear over the last few years that derived signals that you write to are pretty necessary for keeping state without calling effects to set signals. And honestly, we're not the only ones. I believe both Angular and Svelte have added these linked signals I call.

I used to call them writeable memos, but these days I just call them signals because in the next major version of Solid, you'll be able to just drive a signal from something else, like props, by just wrapping it in a function. As you see in the second example, I'm just wrapping the constructor in, and what that means is every time props.names updates, it'll actually reset that signal to that value. No need for use effect. The most important thing to avoid unnecessary effects is having premise in managed async. On to our next topic. It starts with understanding the role of async and UI frameworks. There's a lot of tools to help handle async better, process events or streams, et cetera, but for UI framework, all we really care about is maintaining consistency within what we display. UI frameworks tend to be synchronous to provide these guarantees, so signals make a great choice there. We only care about async at the edge, like how it enters or exits our system.

We need to maintain our synchronous model. It always comes down to consistency. These are all valid options. Even tearing, which is inconsistent. Ever use a typeahead? That's a form of tearing. But each only actually apply in certain scenarios. The truth is, there isn't one size fits all, and all of these as defaults actually have issues. Frameworks have made different choices here in terms of defaults, but all of them actually need to handle all four of these scenarios.

What does it have to do with signals? A UI framework only has responsibilities to UI, and the only thing it needs to block is not having data to render it. This flips the conventional model on its head. Async is about reads, not writes. We're so used to, like, set states, assign value, update, you know, some way of telling the code to update. But async is more like asking the question, can I render this yet, is what I'm showing out of date. Look at the APIs we use, like use or suspense or await. These are reads. You know what else is reads? Obviously, signals.

The way that signals can read independently anywhere in your app, well, that's a superpower. So this starts with introducing your async primitive, a derived async signal, to be precise. It doesn't need to be derived, but its core tracks the sources and reruns and updates while communicating that value isn't ready to the rest of the graph. And this is powerful because it piggybacks on all our fine-grained benefits we've seen. So we're getting into some demos now. Let me... Sorry. All right. So I'm going to pull up a quick code demo to show what I'm talking about. In this example, I've made components appropriately named A, B, and C, and as you can see, they're nested in the UI. A renders B, B renders C, and so on, and C just renders its own text. But each of them fetches its own data. These createAsync calls basically call some helper that I built here that's literally setting a timeout for two seconds, right?

We don't need to block because this effectively can block right here and still render component B, which can also fetch, block here, which renders C. Basically, children become siblings automatically in this model, so we remove client-side waterfalls where the data doesn't depend on itself just by knowing the shape of the reactive graph. But it's more than just being fine-grained. Signals being both push and pull give them an advantage, that being only push-like events, which only knows what has updated, but not how it's used. Or being pull, like a bead-on, which only knows what's being used, but not what is updated without checking everything. Signals give us both of those benefits.

We should be leveraging this knowledge a lot more. I have another example here. This one is a counter. I love the classics. The idea here is we have a signal for a counter, and then we have async here, which is going to get a phrase based on that count. Then we have a derived value, which is the phrase to uppercase, as you can see this is capitalized. Then in our UI, we have a button wrapped in an error boundary and a suspense component. As you see, when we load it in our page, we load it in our phrase.

What makes this interesting is this API likes to error a whole bunch. I have some chance of it erring out. What's interesting about this knowledge of the reactive graph is obviously when we can click the change, we can refetch the data, and it can clear out this error state. What's more interesting of using reactive graph is this retry button. Inside our error boundary, we have a reset. What happens when we call reset is an interesting question. You already can tell you're not in React anymore because our suspense boundary and our error boundaries are in the same component and we're just fetching stuff in the same place. What's interesting is this retry will actually refetch the data. The reason for that is it sees that it's errored, and it traces back up the graph, seeing the errors, until it gets to the async source. Then it goes, oh, I guess it erred out. I should try again. It does all of this. Let's see if I can show this really, really quickly here from the DevTools. If you've noticed, I snuck in rendering inside our phrase counter and inside our message. In this example, we don't actually render the text all the way into down here. We didn't have to change this API so that it took promises or anything.

We didn't have to change this API so that it took promises or anything. Everything signals. It understands the signals. If you see, we rendered the message component. When I click here, it's going to update this without rendering any components. Even the error, when it errors randomly, eventually, come on. Error. Okay. Even when I click this retry, it's still going to be able to do it without re-rendering any of the components again because, in fact, it's just using the data graph to trace it. Hopefully, that is at least visible.

Back to the topic of consistency. As you can see in the last examples, Solid actually errors by default. We didn't go back to suspense every time we clicked the button. It actually showed the updated state. What if we want to walk it in so that we can keep values in the past? Like React, we have transitions. And transitions are... We've had transitions in Solid since... What version was it? It was a while ago. Back in 2020ish. We have a lot of experience with transitions.

What's really cool, and I hope this last example will tie it all together for you, is I've taken an old to-do app. I want to show what it looks like to modernize this into a modern async app. This to-do app... Let's reload it. There we go. To-do MVC. It's classic. We create a store, like I've shown before, and then we have a few functions that add a to-do, remove a to-do, toggle to-do. It's limited.

It's limited. The UI is basically just a loop that does the stuff, and I'm not going to get into how fine-grained rendering is amazing here. But generally speaking, if I go in here and add some code and go, like, hey, you know, it does the thing, right? If we can check these boxes, we can remove it. This is pretty standard application, and it basically, as you expect, you just, like, do some mutations on the store. You add a to-do, filter the to-do, find it, and mark it as completed. This is fairly straightforward.

But now, what if we want to make it async? Now, if I had more time, I'd actually do this live code, but since I don't, I am going to just jump ahead and show the tools we did today with a working demo. So we do a couple things. We now, I've created a server, and the server is just kind of faked. It's just an array in another file with some delays in it. But generally, I've exposed them through this DB thing. So basically, now what we do is we get our data from the server, we go db.get to-dos in our create async. And then we derive our store from this data.

I did one other little thing, which I called this an optimistic store, because I want optimistic updates. If I didn't do this, we wouldn't have the optimistic updates. But I was able to take the exact same code we wrote previously, like the set to-dos, the filter, and keep that in our example. And then just wrap that code in a transition. We support async functions as well, but you have to do this funny thing where you call start transition today, because we don't have async context, if you've ever seen any of the React demos recently. So I'm just going to use the generator form. We're kind of playing with APIs still.

But the idea is, you set your optimistic state, you yield your async, and then you tell your create async function to refresh the data. And what this does is, without changing the logic of our template, without changing even the logic of our store, we get the same kind of immediate thing where we have this working, except it's now persisted to the server with these calls.

As I said, I wish I had more time to actually get into the nuts and bolts of this. But moving from what we're used to, purely client-side, to async involves just wrapping a few actions, and all the rest of logic in your app should stay the same. That's kind of a philosophy I've been following with Solid for a while, like when we added server functions and whatnot.

As I said, this is just the beginning of what happens when you have this knowledge about the graph. I think we're going to see a lot more evolution in this world, because now, for the first time ever, the code you write informs us. It could inform your IDE, it can inform your AI tooling, how the data flows in your app. And I think we're at just the precipice of the next big thing. If you're very interested in this, keep watching the space. I stream regularly. You'll find resources you need off Solidjs.com. Join the Discord, join the discussion. A lot of really cool stuff is happening here. Thank you.

When do you typically stream, by the way? Usually Fridays. I've moved earlier. It used to be Friday nights Pacific, but now it's Friday around 10 a.m. Pacific time. Okay. Cool. Let's see. No questions in yet. Come on. We need your help here.

How long do you stream for? It's funny, because you're usually streaming right at the end, and I see if I can drop a rate on you. Yeah, usually five to six hours, which seems like a lot. But the streams are usually broken up into pieces. Essentially, we talk a lot about... Usually I have a guest or a main topic that we cover for about an hour or two. And then I spend usually about an hour doing research topics.

I kind of build the framework out in the open. And then I kind of wrap up with a This Week in JavaScript, where we talk about current events and stuff. Oh, very fun. Cool. Awesome. Oh, and we got some questions rolling in. A bunch of them. So, the first one here is, how quickly will Solid Start support SolidJS 2.0? There's a plan in place. The roadmap. Attila's posted that. I think they're going to start working on Solid Start 2.0, while Solid 2.0 is still in the beta stages. So I anticipate that it will be fairly quickly. There are some updates to the async primitives, obviously.

There are some updates to the async primitives, obviously. But the biggest thing is, we've been kind of previewing some of the 2.0 async primitives in Solid Start this whole time, just through the router. So I expect that the rollout of Solid Start, after Solid 2.0, will be almost immediate. Awesome. Very cool.

Why do you think React has not adopted signals at the core? It just doesn't fit with their re-render model. They're kind of at odds with each other. Basically, the philosophical idea behind React is that the component or the function is the thing that re-runs. So adding signals just doesn't help them in any sort of way. The problem with that is, they want to look at it and try and do it, because there's been a lot of pressure in the community. But it meant when they did the tests and stuff, they did it in ways that wouldn't make sense from a Signal Library perspective. People should just stop bugging React about it, honestly.

How does the transitions async work with optimistic updates? I showed it briefly there. I wish I actually showed it in, because if I removed the optimistic updates, you wouldn't have seen the updates right away. So I jumped straight to the solution. But the gist of it is that the optimistic updates are these updates that apply immediately, instead of being delayed. Most of the signal sets get held in the past, until the whole thing can do as a single transaction. Optimistic updates updates the stuff immediately, and then when the transition ends, it re-derives it from its source. Most of the time, optimistic updates are actually derived, like that example. Your data is coming from a server. You can fine-grain update the optimistic updates. Just update the one thing, update the one piece in the UI. When the server goes, OK, I've refreshed the data, it'll come in. The optimistic updates will go away, but it'll actually diff the data, and then hopefully nothing's changed, because you did a good optimistic update, it didn't fail, and then no further work is done. It's very powerful that we can keep our fine-grained updates in that kind of model. And then it becomes seamless for the user.

It's very powerful that we can keep our fine-grained updates in that kind of model. And then it becomes seamless for the user. Yeah, exactly.

How do you compare React context to signals? This is kind of like when people try to compare React context to state management libraries. They're kind of different things. Context, at least the way I view it as a container, I know you can use state in React and cause the component to re-render, but that's the most... It's a basic brute force way of using context, and no actual state library in React uses context that way. It's OK for simple things, but it causes a lot of re-render down the tree. So, signals themselves are just a state management solution.

What makes it interesting, like I was trying to say in the talk, is that because the JSX, because every part is aware of the signals, when you pass props through, it just defers the read all the way down to where it eventually gets read. It basically just flattens the whole tree, so nothing needs to re-run except for the points that re-run. This is very different from React which is thinking in this component hierarchy. I think the next question even hints on that.

Are signals easier to debug than top-down re-rendering? It's funny. I wouldn't say either is easier to debug. They just work in the opposite direction, so you approach them the opposite way. Top-down, you're like, OK, I set some state, why is this re-rendering 20 times? You kind of look, and you go, OK, maybe this isn't memoized. You're like, OK, where did I miss? Did I pass an object to make a new object? You're kind of going through this way, kind of moving your way down the system. With signals usually it's like, why did this thing not update? It's the exact opposite.