From Pull To Push? — It’s Time To Talk About Signals

Hi, everyone. I'm Julian, and yes, I do want to talk about signals. Now, JavaScript signals have had their fair share of attention and hype over the last few years. Especially in combination with the current TC39 proposal, I think it becomes more and more important for people to kind of be cross what signals are, how they work, and what problems they're trying to solve. But signals have also been part of, let's say, less positive conversations and discussions, especially in the React ecosystem around React and it not using signals. So I do want to touch on that. Why is React not using signals, what it's doing instead, but also why I think as a React developer, you should still follow the TC39 proposal, and I'm personally still hyped about it. Now, this is not going to be a talk about how signals are right, and if you're not using signals, you're wrong, or vice versa, like React is right, and if you are using signals, you're wrong. For me, this is not a right or wrong situation. So my talk really more aims towards trying to give everyone information about signals and how they work, so that you hopefully can go away and make more informed decisions for yourself and have more informed discussions. But also, and maybe more importantly, I do want to highlight the two different paradigms that have evolved in the JavaScript ecosystem and how we got there. So with all that out of the way, let's dive straight into it and let's talk about signals.

What are signals? Let's start there, just to get everyone on the same page. Signals are the idea of reactive variables in JavaScript, and what that means is we can take a look at a very simple example. We have three variables here, the counter, and then two derived values. So isEven is derived from counter and is true or false, and parity is derived from isEven and just turns it into string, even or odd. Now, whenever I reassign counter, which I can do because it's just a mutable variable, I have to remember to also reassign and recalculate all of those derived values, and that's obviously not great and that's tedious, and the idea of reactive variables is that I don't have to do that. So let's imagine a world, so this is not real JavaScript, this is a thought experiment and it has nothing to do with the signals proposal just yet, but let's imagine a world where we had a new assignment operator. So I chose the dollar equals instead of the normal equals, and that new assignment operator would tell the compiler that these are reactive variables. So we use a for isEven in parity here, counter can stay the same, and what we're telling the compiler is, hey, please, whenever any variables that we use in our calculation, whenever any of those change, please automatically recalculate this variable. That means if we change counter, we don't have to do anything else because the recalculation magically already happens through the compiler. Now, this is the core idea behind signals. Why would we want that?

Most of what we do as front-end developers is dealing with state and turning that state into UI. Now, when I started developing quite a while ago, the main paradigm around that was model view control or MVC, and the idea was that your view should always be a pure function of the model. In more modern terms, you can say your UI should always be the result of a pure function of your state. That sounds probably familiar, and the pure bit is really important here because basically what we want is if we put in the same state, we always want to get the same UI out of it. It just makes it very deterministic and easy to deal with. Now, how do we get from that to signals, which sounds more side-effecting? To understand that, we have to take a quick look at the history of reactivity on the web. Again, we have to start at the very beginning. We start with HTML and some kind of subset language.

I'm choosing PHP here, but it could be any other language. It really doesn't matter. The concept is always the same. You have some form of state. In this case, we have a counter that we get from the URL, and then we have some form of templating that uses the state to render HTML. Then in the browser, whenever the state changes and whenever the URL changes, the browser goes back to the server, fetches a new UI for that new state, and returns that. This is basically the perfect example of what we just described of a pure function that based on the state just renders some HTML. It's what we call the pull approach. Every time the state changes, we're pulling the new UI from the server, and it has all the benefits that we just described as well. It's very predictable, meaning it's very easy to reason about by just looking at the code. It's very hard to get into broken states where we have to deal with inconsistent UIs. But it has a major drawback, and that's performance. It's obviously not very efficient to have to go to the server and fetch the whole HTML again every time any small state changes, especially in modern applications where we have a lot of state that's floating around.

So when JavaScript became a thing, especially when jQuery became a thing, and then we got AJAX, which allowed us to network requests even after the initial load is finished, we started playing with ideas to improve this pattern. The idea was basically, okay, we know the state changed, and we probably have a good idea of which parts of the UI relied on that state. So instead of fetching the whole HTML, let's just fetch subparts of that HTML, the parts that we know matters. So we're still going back to the server, but now we're much more selective, and we're only fetching smaller parts from the server, which means the server response is hopefully faster. So this is still a pull approach, but I would call it an improved pull approach because we're reducing the scope and helping with the performance problem. We're introducing the potential for inconsistencies now. If you don't remember that another part of the UI needs to update when the state changes, suddenly your UI could be inconsistent and out of sync.

For whatever reason, from that point, we went full on JavaScript. We went, what if we didn't go to the server at all, but instead just mutated the HTML on the fly in JavaScript on the client? While this might still look very similar because it's jQuery, the paradigm completely flipped. So now it's not a pull, it's more of a push approach. So whenever an action occurs, instead of fetching the new UI from the server, we're going straight to the DOM and pushing the new state into it. That obviously loses all the benefits of the pull approach. So now it's much less predictable, harder to reason about, and easier to get into inconsistent states. It's also pretty messy. So this is unfortunately why jQuery is still remembered as the spaghetti code error. To unspaghettify it, we introduced application frameworks. I'm choosing Knockout here because it's the first one that I've worked with.

You might have worked with Angular, which came out at a similar time, or other frameworks. They all have the same principles. They work with three layers. One is for your state management, which here is the view model. We define our state and our actions in there. Then we have the templating where we define the HTML that we want to render. And then most importantly, we have that layer that combines those two, which we call the data binding layer, which allows us to access our state and our actions within our template.

So what that does is, while it's still a push approach, so underneath the hood, Knockout will still mutate the DOM. It gives you a developer experience that's closer to a pull approach. We still have a feeling of being in full control of what's being rendered at any given time. The other thing that Knockout introduced, which helps with that, is the concept of observables. Observables are essentially what we'll later call signals. It's the concept of the framework can keep track of those variables that we're assigning and can keep track of when they change.

With Knockout computed, we can define derived values. Again, they automatically recalculate whenever any observables within them change. That allowed Knockout to have that feeling of like, okay, I just need to update an observable, and the framework figures out which parts of the UI I need to update based on that. This is where the JavaScript ecosystem split into two, like I mentioned in the very beginning. I'll get into that in a bit, but let's focus on the path that's going into the signals first. So basically, observables are the early introduction into something that you could call signals. The idea just stuck. We have plenty of other frameworks that follow very similar patterns.

In Vue, we had data and computed in the beginning. Computed just being again, derived values. Those are all exposed to the template. In later versions, or in more modern versions, we have refs in Vue, which I believe, again, are the same concept. Svelte. You wouldn't see it in the beginning because it was hidden behind a compiler, but in 2019, they removed that and introduced Runes, and then you can see it's explicitly, again, the same pattern. We have an explicit function that allows us to create state and derived state, and it will recalculate them for us. Solid famously was the one that coined the term signals, or at least they get all the credit for it. Again, they were very similar. I have a create signal and a create computed function, and allow you to access those in your template. I could go on and on.

Angular famously adopted signals end of last year. Plenty of frameworks are starting to converge in that direction. Now, let's talk about the elephant in the room. What is it about the other path? The path that React took. So, why is React not using signals? Fundamentally, React is embracing the pull approach. What that means is it's saying that to build dynamic applications, especially large-scale dynamic applications, the pull approach just has so many benefits of being able to predictably and consistently render the UI that it's worth sticking to that pull approach and instead finding ways to deal with the performance problems that come with it. What that means in React particular is that we can see that whenever state and a component changes, the whole component will be rendered. So, that's, again, the pull, like, we just redo the whole thing every time state changes kind of approach.

There's a really good talk that I highly recommend everyone watching from 2014, so very early days, where the React team actually explains why they came up with Flux as their state flow and React as their UI library to solve problems, especially in the Facebook application. And they go very deep into examples for major drivers that were, like, inconsistent UI states. So, highly recommend watching that. They also keep doubling down on that, saying the React approach, they believe, is just a better way to write a reliable UI code. But they do acknowledge the performance thing. So, again, the way React deals with it is just trying to find ways to make performance better while keeping the pull approach. And it's doing it in multiple ways. For one, the component architecture itself helps a lot because you don't have to re-render the whole application. You just need to re-render underneath, wherever the state changed. React introduced the concept of virtual DOM, which allows React to kind of calculate what the new DOM would look like, compared to the existing DOM, and only update what needs to be updated.

React introduced the concept of virtual DOM, which allows React to kind of calculate what the new DOM would look like, compared to the existing DOM, and only update what needs to be updated. So, it prevents unnecessary re-renders for stuff where the UI actually didn't change. And then there's a lot of memorizations. So, if you use React, you will know useMemo, useCallback are basically everywhere. That's basically, again, to prevent unnecessary computation and re-rendering in your application. They're going further with that. The new React compiler aims to do that in the compiler itself. So, you don't even need to remember to use useMemo. It's just doing that for you at build time.

It's also worth noting, and again, another talk that I highly recommend watching, at this year's React Conf, the React team kind of showcased a bunch of experiments and benchmarks that they've run. They've even experimented with signals or signal-like implementations to see if that would speed up React's rendering with the paradigm that they have. And it turns out it didn't really. But they found other ways that are inspired by that, that are very promising. It's called React Fir. I don't know if that's the final name, but it's worth looking out for what's coming there. The React team actively works on improving the performance while maintaining the pull approach.

Cool. I hope that gave everyone a rough idea of what the different approaches are, pull versus push, and how we got into the push approach where signals come into play. Now, let's focus on how signals actually work. How does that magic actually happen of it knowing when to recalculate and everything else? For that, let's actually write a little bit of code. Let's implement signals ourselves in a very dumb, very simplified form. It still gives us a good idea of how it actually happens. We have a demo application here. It's just a simple counter button. And then I'm rendering the parity underneath it. What I want is to be able to click on the button, increase the counter, and update the parity based on that. Now, in plain JavaScript, what I would probably do is have an event listener that takes the current counter from the DOM, then increases the counter, and then updates the DOM based on the new counter. If we say that, that does exactly what we want. So, this is the push approach where we're just mutating based on actions.

So, this is the push approach where we're just mutating based on actions. Now, the scope changed a little bit and we have a second counter now. So, now, we need to deal with two counter values, first of all, and create a new sum. Let's use that. And then use the new sum in the parity as well. If we do that, this still works. But the new counter also needs to be hooked up. So, we need to duplicate that. It's slightly different. We increased counter 2 now, instead of counter 1. But the rest is still very similar. And if we do that, cool. Both counters work now. But you can already see this is very bloated and it's slightly different. So, we can't just easily pull it out into a single function. Also, now, the PM comes and says, hey, I want the third button that increases both counters at the same time. And again, we have to go in and say, cool, we have now a third button. And we do the same thing. We get the counters. Now, we increase both of them, sum them up, and update the DOM again. And while this works, there's nothing fundamentally wrong with it. You can hopefully see how this gets out of hand pretty quickly, complexity-wise.

So, what if we had a magical signal implementation that we could use to simplify things? The best thing we want to simplify is just extracting, okay, how do we keep track of our state? This very easily declares, these are the two signals that we have and the computed values that we have. And then we can think, again, about our actions. And all we want to do in our actions now is actually increase the signals, those counter signals. So, for button one, we want to increase counter one, for button two, counter two. So, we're much more focused on how do we actually want to update our state. And then in the third step, we want to deal with the effects of what do we actually want to do to the DOM whenever the state changes or whatever else your application actually wants to do. And so, in this case, we, again, very easily want to say, cool, whenever counter one changes, rerun this and update the inner text of value one and same for two and then the sum and the parity. So, this already looks much easier to deal with.

Obviously, it doesn't do anything yet because we haven't implemented the signals yet. So, that's the next step. Let's actually implement this. And again, this is a very oversimplified basic version of signals. And it's not very helpful. So, we have the value and all we really want is a getter that returns the value and a setter that sets the value to the new value that we're passing in. And for computers, they only need a getter because, by definition, you would never set a value, a computed value, only ever describing how it's calculated. And for effects, for now, it's the same. We just run the function that we're being passed.

And it's still not doing anything because we're missing that critical part, right, where signals magically know when something needs to be recalculated. And for that, we need to know who's using the signals in the first place. So, there's two things we need to keep track of, the current effect, and then we need to have a concept of subscribers. So, for the current effect, we just set the current effect whenever an effect runs. That allows us to know which effect actually uses certain signals. So, whenever we read a signal, we add the current effect to the subscribers. And then after updating any signal, we notify all subscribers that the signal has been updated. So, you can actually think about signals as just very tiny event emitters that just broadcast to everyone who's using them, hey, I changed and you need to redo something.

Again, this is an oversimplified implementation, but what this gives us is a functional example in our case. And it's only 30 lines of JavaScript. We managed to clean up a lot of the application side implementation of things. And hopefully shows that while it's magic, there's actually not too much happening. Now, like I mentioned several times, I'm oversimplifying things. So, there are still challenges that you have to deal with when you implement signals. And this is where the evolution from where we came from with Knockout to nowadays is very important, because that's what happened in those years. And I don't have time to go into any of these challenges too deep, but I want to mention a few of them just to give you a feel for it. So, we call them glitches. And there's a few of them. The popular ones are that the order of recalculation matters. So, whenever a signal changes, the order in which I recalculate computed values matters. If I do that in a random order, I can get into states where these values are actually not true.

It's important to batch signals or signal updates. In this case, we haven't increased both. And we update two signals individually. If we don't batch them, we could get into a state where the intermittent state after the first signal update flashes in before the second update runs. So, modern frameworks batch the signals.

There are a lot of optimizations that signal implementations have done to keep track of which values actually change, whether or not the signal needs to recalculate based on its dependence, even if the root signal has changed. Signals can often skip recalculations more easily. Lazy execution is introduced, where computed values are marked as dirty and recalculated only when read.

The TC39 proposal aims to standardize signal implementation in JavaScript, making it a first-class citizen in the language itself. This standardization would allow frameworks to use signals without reinventing them. It's exciting for the evolution of front-end frameworks and offers the potential for runtime optimizations and performance improvements, similar to the impact of just-in-time compilation in Node.js and browsers.