875: JavaScript Signals Explained

JavaScript is missing a built-in way to make variables reactive—but Signals might change that. Scott and Wes break down what Signals are, how they compare to React state, and how different frameworks like Preact, Solid, Vue, and Qwik are already using them. Show Notes 00:00 Welcome to Syntax! 01:49 Brought to you by Sentry.io. 02:28 Why JavaScript needs reactive variables. 03:16 What exactly are signals? Signals Proposal. 04:02 Understanding computed state. 04:59 How signals differ from React state. 06:12 How different frameworks handle reactivity. 07:09 DOM Parts. Pull Request. 07:26 HTML Template Instantiation. Template Instantiation. 09:10 Comparing signals across frameworks: Preact, Solid.js, Vue, and more. PreactJS Signals. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Wes Bos?

  Welcome to Syntax. Today we have that episode on JavaScript Signals Explained. This is something, a concept that has been implemented in, I think, all of the frameworks out there. And there's currently a proposal. It's pretty early on, so don't get too excited. But there's a proposal to add signals to JavaScript. And I thought, like, let's do a quick little explainer episode explaining what signals are and why they're useful and sort of the couple of ideas behind them. My name is Wes Boss Devolber from Canada. With me as always is Scott Tolinski. Sup Scott?

• 0:38Scott Tolinski?

  Oh, man. Not much, not much. Just hanging out. I, for those of you who heard about my finger injury, it's on the mend. Oh, good. Yeah, I got it down to just a little Band-Aid now and I can actually type with it. So progress. Believe it or not, the doctor told me that thing's going to heal fast. I said, there's no way that's true. And it's healed pretty fast. So I'm pretty stoked about that.

• 1:01Wes Bos?

  Hands are, yeah, hands are one of the thing that like, like bounce back as quickly as possible because you use them so often. So you're lucky.

• 1:09Scott Tolinski?

  That's what he was like. He told me to take off the splint and use it because it's a, otherwise it's just, just going to heal stiff or whatever. And I didn't damage.

• 1:18Wes Bos?

  Split and use it. That's my favorite Blink-182 album, actually.

• 1:21Scott Tolinski?

  Oh, yeah. Take, take off your splint and use it. I used to have a T-shirt that said, "Take off your pants." And on the back, it just said, "And jacket." And I'm sure my mom was just like, "What the hell?"

• 1:32Wes Bos?

  Oh, man.

• 1:33Scott Tolinski?

  Yeah, it was just big.

• 1:33Wes Bos?

  I don't even know that I understood what that was for the longest time.

• 1:37Scott Tolinski?

  Yeah.

• 1:37Wes Bos?

  I didn't get the joke.

• 1:39Scott Tolinski?

  I understood it, but I was too like, like, you know, whatever. Nobody else will get it, you know? Yeah. Teen stuff. Yeah. Yeah, I saw them on that tour. A lot of fun.

• 1:49Wes Bos?

  Real quick, you should use Sentry. If you are using JavaScript or using any programming language, Sentry is going to give you insights into why your app is slow, insights into why your app is erroring out, insights into what happened in leading up to an error, video playback, all kinds of really good information about what went wrong and help you solve those bugs. Check it out. Sentry.io/Syntax.

• 2:16Scott Tolinski?

  Yeah, Sentry allows you to take on your app and hack it.

• 2:28Wes Bos?

  All right, enough of that. One thing that is missing from JavaScript is this idea of reactive variables. We have reactive variables in all of the frameworks, meaning that you can store data in a variable. And when that variable changes, you want to react to it, right? You might want to display it. You might want to throw it into the DOM. You might want to compute some data based on that. So for example, you have an array of items in your cart and you want to calculate how much your cart total is. Or you might also want to to update something, right? You want to send some data over a web socket. You might want to update the title tag of the website. When data changes, you want to do things. That's kind of the

• 3:13Wes Bos?

  whole idea of of web development. So this idea of of signals is a signal is a like a piece of data that may change over time. It's a piece of state. And if you want to react to that data, or compute data when that data changes, you can use this idea of a signal.

• 3:37Scott Tolinski?

  Yeah. And so typically, when you're watching, you're often seeing that being described as an effect, or people you say it's a side effect. When this thing happens, the side effect is something else happens, right? And sometimes, people think like, all right, I'm going to listen for this variable to change. And then I'm going to update another signal based on whenever this one changes. But the the better way to handle that situation is to use something called computed state, like you just mentioned, where with computed state, it's exactly doing that. It's saying, whenever this changes, the new value of this state will be computed by the current value of the state that's changing. So you

• 4:22Scott Tolinski?

  see this in all kinds of these both signals implementations and libraries under potentially different names, whether that is computed in Svelte, it's derived.

• 4:33Scott Tolinski?

  Things listed as all kinds of things, but the idea is, is that one bit of state is derived from the other. So when one changes, they both change. They're attached.

• 4:41Wes Bos?

  The other part of signals is you also are, have the ability to update that piece of data. And that is really nice because you can simply create a, a piece of state and then you can import it and export it in and out of your, your different files and then update it. The, the one, we'll get into frameworks in just a second, but that's, that's not the way that React works by default. React state is, is top down. It's, it's uni, uni directional, meaning that if you want data, state or updater functions in somewhere else, you must pass them on down. Whereas with signals, they can simply, they can go anywhere, right? You can define them lower and, and import it at

• 5:26Wes Bos?

  a higher level or, or vice versa. And that's just, React is very much about the whole top down, but you still can get this whole signals thing in React land. We'll talk about how in just a sec.

• 5:38Scott Tolinski?

  Yeah. And that's one of the things that people hit in React is they're updating some bit of state and that bit of state's being passed down through props. It's causing components to re-render all the way down. It's a potential issue with how, how people work with state. It's one of the reasons why I think state and, and React re-rendering has kind of been a little bit of a, an issue for some people in terms of performance wise, where in Solid JS, in Svelte, these types of things that use signals out of the box, you're more or less, values are changing, things are rendering based on when values are changing. Yeah.

• 6:11Wes Bos?

  The way that a lot of these frameworks work, not, not React, React has this idea called a virtual DOM, but the way that most of these other frameworks work is that you have a signal, a piece of state, and you are putting that piece of state into a template. And then something like Svelte or Solid JS, they will simply just watch or observe that state. And when that changes, it will simply just update. It, it knows exactly where those pieces of state are and it will, it will update them on that DOM node. Rather than having to, with React, there's a virtual DOM and it will sort of diff it and figure out which parts of the, the DOM need to be updated. So just different approaches, but the whole idea of

• 6:58Wes Bos?

  Like reactive templates that we have in all these frameworks is being discussed right now to add to HTML. So there's kind of two things being worked on right now. The first one is DOM parts, which will sort of bring this whole idea of like templating that we're used to in all of these frameworks, straight to JavaScript. There's a pull request open for that, as well as HTML template instantiation is another spec that's being worked on, which will also let us put that in. So imagine how awesome that will be when

• 7:38Wes Bos?

  we're able to put variables in our DOM elements. And if it's a signal, then that signal will simply just re-render itself. Sorry, that DOM partial will re-render itself when it's needed.

• 7:54Scott Tolinski?

  Yeah. Anytime I get one of these web components pull requests or anything like that, it makes me realize how unequipped I am to really understand the challenges and things with web components. Because I always look at this stuff like, oh, this looks great. This looks fine. And then I hear afterwards, no, this sucks because of these following reasons. And you're like, all right. So I gotta dive into these PRs a little bit and really get some ideas about if this stuff is actually going to solve the problems or not. Because like with anything in web components, it always feels like, even if it seems like it solves the problem, there's always like nuance that it might not. So interesting to see. But the cool news is, is that anything that comes to the platform can trickle down into frameworks that use the platform. And if your framework uses the platform, you

• 8:37Scott Tolinski?

  get that for free. Your framework gets lighter and yeah, your code just works. So I love that.

• 8:43Wes Bos?

  And like more memory efficient, you know, like if they're doing it at a browser level, that's much better than.

• 8:50Wes Bos?

  Us doing it in JavaScript land, right? There's a so the the side effects or the watching of variables to change. That, of course, also all has to happen in JavaScript land right now. But imagine if the browser could tell you when a variable is updated, then you you have it's faster. There's less memory, all those good things.

• 9:10Scott Tolinski?

  Yeah, totally. So let's talk about other implementations while things you can use while you're waiting for this to come to the browser. The big one that a lot of people use in the React world is preact JS signals. And this, the repo for this is fairly straightforward in terms of the use case. Like when sometimes you see like concepts like this, they feel like big ideas or big anything. But the the signals and the preacc signals is really just a couple of, you know, a couple of functions. You're either creating a signal, which is you're creating a bit of state. You're accessing that that value. You're using computed to derive values from that value. There's an effect function that you can import that runs when the value has changed.

• 9:51Scott Tolinski?

  So you're not having to wait for or pass in a dependency array to tell it when to update. Right? It's based on when the signal changes. There's also a batch function, which allows you to combine multiple signal writes into one single update. So that's neat.

• 10:06Wes Bos?

  And That that one's important for like rendering performance, because if you update six or seven things.

• 10:12Scott Tolinski?

  At least in React, right?

• 10:13Wes Bos?

  You can you can batch them all at once so that the well, even like pretty, it could be for anything as well. Because if you're updating the DOM six or seven times versus once, it doesn't matter what framework you're using. That's that's going to be a little bit slower, especially if it's triggering animations or transitions or anything like that.

• 10:31Scott Tolinski?

  Yeah, but if it's triggering a re-render of five components, that's worse than just updating the DOM five different places.

• 10:38Wes Bos?

  Yes, yes, totally.

• 10:40Scott Tolinski?

  Yeah.

• 10:41Wes Bos?

  Preact JS Signals is really cool because it, of course, it works with React, but it also works with vanilla JavaScript. And I've used it several times in vanilla JavaScript. And it's, it's, if you ever want, like you're just doing something vanilla JavaScript, you're just using like template tags or document dot create element, or simply just enter HTML with some variables inside of some HTML. The Preact JS is very lightweight. It's, it's 800 lines of code for the entire Signals library. And quite honestly, some of the best code I've ever written of, in terms of being enlightened.

• 11:20Wes Bos?

  Because like, I was always wondering, like, how do they figure out what variables are being used in a specific thing? Because the way that an effect in Preact Signals works is that you can just pass it, like a function that uses a signal, and it figures out what signals are being used and what signals to track. And I always wondered, like, and I'm not, not passing it like a dependency array or anything like that. It just figures it out. And then I like, I read through the entire codebase and I was like, ah, it's kind of, kind of interesting how, how they went about it.

• 12:01Scott Tolinski?

  Sick. Yeah.

• 12:02Wes Bos?

  Yes.

• 12:03Scott Tolinski?

  Yeah. Well, other, um, you know, I feel like Solid JS doesn't get enough credit. Maybe they do, but Solid JS doesn't get enough credit for really bringing Signals to everyone in a way that they're like, oh, this is actually neat. This is actually something I need. So, uh, and I do find Solid JS's Signals implementation to be really nice. I had to dive pretty deep into that when I was writing my Zero Sync Svelte package, because the examples that existed were React Zero and Solid Zero. And between the two of those, um, Solid is way closer to Signals, uh, in Svelte, which the salt state is Signals. So it was much more of a, okay, how are you doing this with Signals?

• 12:48Scott Tolinski?

  Rather than, man, the React implementation was having to call all these like weird sync state functions that I'm not familiar with and stuff. So, um, definitely a good approach. And I think in general, uh, one that a lot of people have copied, you know? Because it feels like React State where it's create signal, you get set, you know, set value and the value itself. But in the same regard, like it's familiar enough to feel like React State, but in the same regard, it is using Signal. So it's, it's nice.

• 13:16Wes Bos?

  In the, the Svelte blog post, when they're announcing runes, it's kind of interesting because they are crediting Knockout JS, which was from like 2010 as like the first. I, I remember this time when Knockout came along and the whole idea of like PubSub was also, PubSub is, is similar in the idea, not exactly the same, but that was a very popular, and we're like, man, we kind of had this.

• 13:43Scott Tolinski?

  Yeah.

• 13:44Wes Bos?

  Way back then.

• 13:45Scott Tolinski?

  Yeah. We kind of had this. You know what? Knockout is one of the ones I never used. I used Backbone, Marionette, but man, Knockout, what a blast from the past this website is.

• 13:54Wes Bos?

  Yeah, I never used Knockout either.

• 13:56Scott Tolinski?

  They got the Sunburst. Oh my gosh.

• 13:59Wes Bos?

  We should build a, build an app in Knockout.

• 14:02Scott Tolinski?

  Yeah, I remember this was one of those things. There were so few, a few packages that came out and I was so green at the time. It was like just using jQuery and seeing all this stuff and being like, that feels like a lot of work to do the same thing I'm already doing, you know? They just didn't get it, right? But now I get it, which means either I got smarter or I just like things more complex. So who knows?

• 14:26Wes Bos?

  What else we have here? Quick, Vue, Angular, all have their, the implementation of Signals as well. So probably a lot of you know what Signals are, but we thought we would just approach it from, explaining it from the proposed Signals. It'd be interesting to see over the next year or so, how the specification moves. It's currently only in, in stage one, so there's quite a bit more to go. And also, this is a, a major, major browser primitive.

• 14:55Scott Tolinski?

  Sure.

• 14:56Wes Bos?

  So you better bet they're going to take their time making sure that these things are done right, because like we got one, one shot to, to implement Signals as a primitive into the language. So certainly I don't mind them taking an extra year or two versus maybe some of these other APIs, because I want to make sure we get it. Right?

• 15:19Scott Tolinski?

  Yeah, no kidding. Yeah. And then when they do get it right, when they do add it, maybe your favorite framework or library will just use that under the hood and now saving you some KBs.

• 15:27Wes Bos?

  That's the whole idea with like, if you take a look at Svelte, like, I don't think the API would change very much.

• 15:34Scott Tolinski?

  I don't think they'll change it at all.

• 15:35Wes Bos?

  Not change it at all, but like the, they, they're built in a way so that if we ever do get native signals, it would be an easy swap out for the devs.

• 15:45Scott Tolinski?

  Yeah. And that was intentional on their part. Uh, they built that with the intention that once it's native, that it will just be there. So yeah, love this stuff. And you know, once you get used to it, it's just kind of the way state is. So for me, it's just the way state is. So, uh, shout out to anybody who's been on signals for a long time. Shout out to Knockout JS for dang, uh, really seeing the future here. So yeah, um, that's all I have. Do you have anything additional?

• 16:11Wes Bos?

  That's it. Thanks, everybody for tuning in. We'll catch you later. Peace.

• 16:15Scott Tolinski?

  Peace.