WTF Are Signals And Why Is Everyone So Hot On Them All Of The Sudden?

Monday. Monday. Monday.

Open wide dev fans, get ready to stuff your face with JavaScript, CSS, node modules, barbecue tips, get workflows, breakdancing, soft skill, web development, the hastiest, the craziest, the tastiest TS Webb development treats coming in hot. Here is Wes, Barracuda, Boss, and Scott

key.

Welcome to Syntax.

On this Monday, hasty treat. We're gonna be talking about signals.

And signals are something that you may have seen pop up in the JavaScript space somewhat recently here. People have been talking about them with a new crop of frameworks using them as their default reactive model.

And we actually got a question in from our hot luck saying that WTF our signals and why is everyone so hot on them all of a sudden. So we will be talking about exactly that. My name is Scott Talinski. I'm a developer from Denver, and with me as always is Wes, the, signal boss. I don't know. I was trying come up with something. Couldn't come up with anything out on the spot. The bat I don't know. There's some probably something with bat signal there or or similar.

It's gotta be something. Wes, how's it going, my man? It's going pretty good. Just had a pretty nice weekend working on the gym at our house. We're almost done. I'm so close to be doing it. It's funny. I've been chipping away at it for like an hour, hour and a half every night. Well, not every night, but 5 or 5 nights a week, and it's amazing how much progress you can get done in just in like an hour, an hour and a half a night. And I think that the same goes for web development as well. People are always like, I have no time to do anything. And it's it's like, well, It's taking up a lot of my life right now. But if you just devote 3 months

of an hour or 2 a day, It's amazing how much progress you can get done. Yeah. It totally I I'm, like, stalled out on our gym because it's it's so usable and good enough that it's hard to get to the the next step. We're like the next step for me is I have to pull pull the stall bars off the walls. I have to, cut and and remove all the carpet. I need to do the flooring, which I know is gonna be a pain. Yeah. And then I have to paint and then redo the stall bars onto the wall. So it's like, I have to tear it down a bit right now, and it's like, it's so usable that Yeah. I don't want to do that, But I know I have to. Usable is the

like, especially, like, once you're in it, it's just like well, I always give the example of, like, putting switch plates light switches.

Like, once you get the light switches on and the room is painted, I take forever to put the light switch on, the cover on.

It works. You know? And then you, like, learn to live with it. But Totally. And web projects are the same way. It's always like your your 10% edge cases or whatever that are goofing you up. Totally.

You you also you kinda have to just wait for some of that little momentum. You know? Do a big spurt when you're really excited. Get it to a spot where you're happy with, enjoy it, and at some point in time, you're gonna say, I should redo my website. And that's the point where you should seize the day.

Seize the day. Let that energy ride in. Well, let's, let this energy ride us into signals here as we talk about what the heck these things are, why people talk about them now, you know, maybe, what are some of the libraries and use cases around them? But I think with signals, the best way to approach any of these topics that you hear about as being trendy on web dev, Twitter, Reddit, or anything Is that you you wanna take an approach. It's like, what is the the core concept here? What is the reason why we're here? And with signals, the name, just like a lot of things, is a clue. Right? Signal. Like, what do you think of when you think of a signal? You think of, like, a radio signal or something. Right? Somebody being something being beamed from one spot to another spot, those types of ideas.

And kind of just like that, signals are basically a message from one part of your app to another part of your app.

And the signal Concept overall is a general concept and not necessarily a specific tech because different libraries and different frameworks are going to implement signals in different ways.

But you really have to think about signals as simply just being a message from 1 app to another part of your app. When a message is received, the app will know what to do in another part. Right? You click the button. It sends a signal.

Now elsewhere, a signal is received and it does a thing.

It's event driven. Right? So, like, you could think about, like, you got 2 kids with walkie talkies, and they're gonna go, like, pull a prank on dad. Right? There you got 1 kid. He's, like, checking dad to make sure dad's on the couch, and he's, like, dad's on the couch. And the other kid's, like, roger that. Signal received. Let me go, let me go do something. Let me go dump a bucket of water on dad or something. Who knows what they're doing? Kids. Crazy. Right? So that's basically signals as a concept.

Yeah. Exactly. I've been I've been a big fan of these because they remind me a lot of something else we have in the browsers, which is event listeners. Right? In the browser, at the very basic, you can listen for things like a click or a submit.

You can have a form in one spot and you can have some code in another spot. And you want to say, all right, well, when this form is submitted or when this button is clicked, I want to do something with that. And they don't have to be.

It's probably good if they are co located, but sometimes you just need to be able to Literally fire something in the air and say, hey.

Anyone who cares, I just click the button, and then anyone who cares is the event listeners. Right? And signals are very similar to that where you could say, hey, anyone who cares, I now have changed my value or I have some state that has changed. And if anybody wants to update themselves, sure. But My job here is done. I I let everybody know. Yeah. My job is done.

I have I have alerted. I I've let everybody know what's going on. I've sent the signal.

So oftentimes, you you know, you think about signals. You you might fire up a Google machine and start looking around and maybe context and code examples and see exactly, you know, what these things look like. And it it looks like oftentimes and I don't wanna say every time, but oftentimes, it kinda looks like React hook hooks in many ways. Right? You have the, like, these the signals implementation inside of Solid.

Feels very much just like you're using, like, a use state kind of system within, React. Right? You you're, you have your set function. You have your actual value of the state itself.

But signals themselves are not necessarily like a state management solution.

It's just a concept for for alerting people that something has changed. Right? It's event. It's alerting for events.

So even though that you have an API oftentimes that feels very much like React set state, They're not that similar in many ways because, really, what it's doing is it's like, how can we pull this out of an individual component that has its own state in the setting it stated. Maybe we're passing that function around, But you're more or less saying, here's a here's a value, and here's a change to the value off in the ether. And we can now access this wherever we want outside of the whole parent child, reactivity model that we're so used to inside of

React, so to say. Honestly, that's that's one of the biggest pains in my side in the React world is that You either have to put your state high enough that everybody else can sprinkle down because like React can only go down, right? And that can be really frustrating. I've given examples in the past where the syntax website, The audio element is in the player, and that is a sibling to other things that care about what's happening in the audio element. So you have to be able to move it out of the player component, which doesn't make sense because that's where the audio element should go.

Right. But if I want to be able to share it with things, literally the element, the component that is right beside it. It's not really possible. It has to be shared with things that are nested inside of it.

And then something super refreshing in, like, Svelte Svelte world is that you can just I know Svelte doesn't use signals, but the idea of being able to create a store, export that, and literally import that into any other part of your application or listen for a signal in any other part of your application is a,

is so much easier. Yeah. So, I mean, you did say that the the Svelte store's walnut signals. It it is really similar in a lot of ways. So this This is something that I've been trying to figure out is, like, where do the boundaries where where are the boundaries on these types of things? Like, what is signals? What's not signals? And and, really, what I've I've learned is that, you know, signals can be implemented in a pubsub style pattern, like what Meteor did, where you're publishing and subscribing to specific types of data. It can also be the observer pattern, RxJS observers and those types of things.

But, in in actual practice, again, it's just mostly about the event specific stuff, and they can be in that same sort of way. So, According to, like, the direct, definitions of all this stuff, Svelte stores not a direct signals implementation, but, things like deriving and subscribing to data are very signals like, so that they can provide a very similar experience to working in signals overall.

But either way, I've been doing state like this even in React for a while with Zuestand or some of these other React ones. And and it always bugged me when we get so, you know, tightened down into, like, this is the React way of doing things or this is the specific way of doing things. And, I I do like this types of implementations because to me, it makes so much more sense that when you have your application tree.

The state should live outside of the application tree, and the state can control the application tree but still remain separate from the tree. I I guess that's like a way that it's always made sense to me. Okay. So signals are not explicitly tied to state, but they could mean state or could just be events. The way you're seeing it mostly being done right now is via, like, state. So it feels very much like it's a state thing, but it's really all about events. So why are they getting so hot? It was a big question. People were wondering why why so hot now.

It's really just because I think a lot of these newer frameworks are coming out with signals as their default state implementation.

So solid, quick, and people are are liking it. They're they're moving outside of their React bubble, which I think tends to happen in this industry a lot. We we get into our little react bubble.

We're a little bubble of how we do things. And then once you you see outside of it, you can see, oh, wait. People are doing these things in all sorts of different ways, and Maybe that is a little bit more interesting or exciting. You you know, Angular has implemented signals as well inside of their package called zone, which I thought that was it. Zone was kind of interesting, when I was pulling through it today, because I I you know, Angular, huge blind spot for me, But prying through this zone implementation, it says it was inspired by Dart, which I I remember Dart having these concepts.

Again, I didn't work at Dart, so it's it's not something I I can but I remember that being like a selling point of Dart.

So either way, it's called Zone. Zone is Angular's implementation of this. So you have quick, you have Angular, you have Solid.

And, You know, it seems like a lot of people for general usage of signals pick up the Preact signals package.

I know you were you were checking out a vanilla JS example with that. Yeah. The

it's pretty awesome. So Preact has released their own signals package that works with React, Preact, or they also have the base of it works straight up in vanilla JavaScript, which is amazing. So the way that it works is you simply let's say you have a piece of state like a number. Counter is the example everybody does. You say const counter equals instead of setting it to 1, you set it to signal. That's a method. You pass your default value of 1.

Now you have a variable called counter.

And what you can do is if you want to stick that into the Dom, you select your element and then you would say like counter.textcontent equals Or sorry. Counter element dot text content equals the actual counter, which is our signal. So that's setting it. However, the kind of cool thing about it. And this is the sort of the downside to vanilla right now is that when those variables update, you have to explicitly go and update your Dom for yourself. And the magic here is that you simply just wrap your updating logic in an effect function, and it will figure out which variables or sorry, which signals are being used inside of it. And it will watch for those to change, and then it will rerun your updater function. So it's amazing. In, like, 11 lines of code, I had reactive variables in vanilla JavaScript. I was like, Oh, this is awesome. But like, is this just another framework? Like, am I hyped that this is, Like, I'm just including an entire framework. And the answer is no. I bundled it and it was a one k larger Mhmm. Than with without importing it. So I took my 11 lines of code. I I compiled it, and then I took my 11 lines of code with the re pre act signals imported, and it was 1 k larger, which one k is a 1,000 characters.

Right? The the transcript to the sentence that I'm saying right now is longer than that. It's so neat,

because it is. It's it's like reactive code without a framework, in that same sort of way. So those are all options, and and I actually really love that That's available to you in Vanilla JS because that feels like superpowers in Vanilla JS. Honestly, I

I would hope that we will get that in like we have I guess MutationObserver, which is the DOM side of things, but we don't have that really in Vanilla JavaScript unless you create a class and you have custom getters and setters, and it's probably what it's doing under the hood. But I would love some sort of vanilla JavaScript API for reactive variables and maybe even something that plays into, What is it? The, DOM fragments API. So in the vanilla JavaScript, you can create HTML with text and you pass that to Dom fragment. And what that will do is it will turn it from just like a string of paragraph tags and whatnot into an actual Dom node called the Dom fragment.

You can add event listeners before it's actually dumped into the Dom. So wouldn't it be cool if the Dom fragment had a signal in it, then it would know to update itself on the page. Then you wouldn't even need any of these. Select this value

and update it here. Yeah. Yeah. It's, it's it's fascinating.

And, like you said, nice and tiny, so it's not like you have to feel, like, crazy about using it. Now, when wouldn't you want to use signals? And for the most part, it seems like signals are a great way to Utilize some sort of event driven state in in most types of applications Yeah. Except for when the platform kind of already has their own version of PubSub or observable state already. So Vue and Svelte specifically have been doing state really well for a long time.

So Vue and Svelte, you probably do not need to pick up a signals implementation because they already have state models that exist outside of the componentry in the same sort of PubSub way that, you know, me personally, they're they're already event driven and and memoized automatically and all the stuff they gotta do with React anyway. So

view and Svelte users, Fear not. You probably do not need to go that nuts on signals here. Yeah. It's pretty cool that they're built into those types of frameworks or not necessarily built in, but This is not even something you need to think about when you are using those frameworks.

Yeah. Yeah. Because they've they've mostly figured it out in in a similar kind of wave. Cool. Well, that's it for signals. I hope this broke it down for you. It was you know, it's one of those things.

A lot of these topics In in our space, it feels like big topics. Right? They feel like a big thing. People are talking about them like signals are going to change everything.

Everything is now different because we're using a slightly different model of reactivity here. And It's important to know that many of these concepts are are smaller concepts than they they may seem, or they're just that. They're just a concept, rather than some, like, crazy new tech that is is going to totally blow us all away. So signals, they seem like a great option for anybody who's looking to pull their state out of their state tree and do it in an event driven way. The fact that many of these new frameworks are picking them up is fantastic.

Does that mean you gotta rip out your state implementation or how you're working with the event driven state right now in your application? No. Now, you know, if it's working, it's working.

If you're using something like ZOOSTAND, even less of a reason because that's, you know, Pub Sub in the same kind of way. So, yeah, check it out. Signals, if you're interested in having some reactivity and some state there that's event driven outside of your application structure. It's a good option to pick, and that pre act state library we'll link in the show notes is the one that people seem to really be using for most things in the React world. So, that's all I got on signals. Wes, anything else? That's good for me. Thanks for tuning in. Catch you later. Poof. Peace.

Head on over to syntax.fm for a full archive of all of our shows, And don't forget to subscribe in your podcast player or drop a review if you like this show.