JavaScript Signals Explained

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. Yeah. 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 and why they're useful and sort of the, couple of ideas behind them. My name is Wes Bos, developer from Canada. With me JS always is Scott Tolinski.

Sup? Up, Scott?

Oh, man. Node not much. Not much. Just hanging out. I, those of you, heard about my finger injury, it's on the mend.

Oh, good. So, 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 gonna heal fast. I said, there's no way that's true. And it's healed pretty fast, so I'm, I'm pretty stoked about that. It's nice to have a working pain. Yeah. Hands are one of the thing that, like, like, bounce back as as quickly as possible because you use them so often. So you're you're lucky. That's what he was like. He told me to take off the splint and use it, because it's, otherwise, it's just just going to heal stiff or whatever. And I didn't finish it. Splint and use it. That's my favorite Blink one eighty two album, actually. Oh, yeah. Take take off your splint and use it. I used to have a T shirt that said, take off your Sanity, and then on the back, it just said and jacket. And I'm sure my mom was just like, what the hell? Like Oh, man. Yeah. It was just big bowl Node underwear. Understood what that was for the longest time. Yeah. I think I understood the joke. I understood it, but I 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.

Real quick. You should use Sanity. If you are using JavaScript or using any programming language. Sentry JS 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.i0

forward slash syntax. Yeah. Sentry allows you to take on your app and hack it.

Alright. 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 wanna display it. You might wanna 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. You and you wanna calculate how much your cart total is. Mhmm. Or you might also want to to update something. Right? You wanna send some data over a WebSocket. You might wanna update the title tag of the website.

When data changes, you want to do things. That's kind of the 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.

Yeah. And Scott, typically, when you're watching, you're often seeing that being described as an effect or people, you know, say it's a side effect. When this thing happens, the side effect is something else happens. Right? And sometimes, people think, like, alright. I'm gonna listen for this variable to change, and then I'm gonna 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 the state will be computed by the current value of the state that's changing. So you 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.

So you see these things listed as all kinds of thing. 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. 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 unidirectional, meaning that if you want data Scott 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 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. 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 pops. It's causing components to rerender 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 rerendering has kind of been a little bit of, 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.

The way that a lot of these frameworks work, not not React. React has this idea called the virtual DOM, but the way that most of these other frameworks work is that, you have a signal, a a piece of Scott, and you are putting that piece of state into a template.

And then something like Svelte or SolidJS, 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, like, reactive templates that we have in in all these frameworks is is being discussed right now to add to 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 to JavaScript. There's a there's a pull request open, for that JS well as, HTML template instantiation is another spec that's being worked on, which will also let us put the put that in. So imagine how awesome that will be when we're able to put variables in our DOM elements.

And if it's a signal, then that signal will simply just rerender itself. Sorry. That DOM partial will rerender itself when it's, when it's needed.

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, alright. 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 get that for free. Your framework gets lighter and, weekly. Yeah. Your code just works. So I love that. Like, more memory efficient. You Node? Like, if the brow if they're doing it at a browser level, that's much better than

Totally. Us doing it in JavaScript land. Right? So the the side effects or the watching of variables to change, that, of course, all all has to happen in

JavaScript land right now. But Yeah. 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. Yeah. Totally. So let's talk about other implementations, so all 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 the Preact JS signals.

And this the, repo for this is fairly straightforward in terms of the use case. Like, when when sometimes you see, like, concepts like this, they feel like big ideas or big anything.

But the the signals and the pre act signals is really just a 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 a value has changed, so you're not having to wait for or pass in a a dependency array. Just tell it when to update. Right? It's based on the when the signal changes.

There's also a batch function, which allows you to combine multiple signal rights into one single update.

So that's neat. And, That that one's important for, like, rendering performance because if you update six or seven things At least in React. Right? Yeah. 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. Yeah. But if it's triggering a rerender of five components, that's worse than just updating the DOM five different places. Yes. You know what I mean? Totally. Yeah.

Preact JS signals is really cool because it of course, it works with 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 or document dot create element or simply just inner 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 because, like, I 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, I 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 code Bos, and I was like, it's kinda kinda interesting how how they went about it.

Sick. Yeah. Yes.

Yeah. Well, other, 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 Yeah. And I do find SolidJS'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, Solid is way closer to signals, in Svelte, which the Svelte state is signals. So it was much more of a, okay, how are you doing this with signals rather than, man, the React implementation was having to call these, like, weird sync state functions that I'm not familiar with and stuff. So, definitely a a good approach. And I I think in general, one that a lot of people have copied, you Node, because it feels like react state where it's create signal. You get set, you know, set value in 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.

In the the Svelte blog post Wes they're announcing runes, they're it's kinda interesting because they are crediting knockout JS, which Wes 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 it's PubSub is is similar, in the idea. Not exactly the same, but, that was very popular. I mean, like, man, we kinda had this Yeah.

Way back then. Yeah. We kinda had this. You know what? Knockout JS one of the ones I never used. I used, Backbone Marionette. But, man, Knockout, what a blast from the past this website is. Yeah. I never used Knockout either. They got Sunburst. Oh my gosh.

We should build a build an app in Knockout.

Yeah. I remember this is one of those things. There was a 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?

What else do 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.

Sure. Yeah. Tell me. Better bet they're gonna 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 wanna make sure we get it right. Yeah. No kidding. Yeah. And then when they do get it right, when they do edit, maybe your favorite framework or library will just use that under the hood, and Node saving you some KBs. That 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. I don't think they'll change it now. Node change it at all. But, like, the they they're built in a way so that if we ever do get native signals, it'd be a easy swap out for the devs. Yeah. And that was intentional on their part.

They 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 kinda the way Scott is. So for me, it's just the way state is. So, shout out to anybody who's been on signals for a long time. Shout out to knockout JS for, dang, really seeing the future here. So, yeah, that's all I have. Do you have anything additional?

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