¶ Welcome to DejaVue
Alexander LichterHey Everybody, and welcome back to DejaVue.
Michael ThiessenIt's your favorite Vue podcast. You just don't know it yet. I'm here with Alex.
Alexander LichterHey, everybody. What's going on? I'm Alexander Lichter. I'm a web engineering consultant, part of the Nuxt team, and, also do a little bit of content here on YouTube and Twitch about Vue, Nuxt, and, JavaScript and front end, and super curious to talk today with Michael Thiessen. How are you doing, Michael?
Michael ThiessenI'm doing pretty good. And, for those of you who don't know, I do Vue content creation and all that good stuff. Today, we're gonna talk to you about signals. So our last episode was on Reactivity in Vue. In this one, we're gonna go a little bit broader and talk about signals and how that relates to Vue and web development and all of that.
Alexander LichterAs we as we mentioned, right, we mentioned we're gonna do a signals episode, and here we are. So maybe maybe to start with maybe to start with signals in that way. Like, I think it's some kind of a hype word has been around to come to how this looks like in the general web landscape as you said.
¶ Signals and Reactivity
And before that, maybe you should start with what signals are in a bit of history, let's say, because the concept is not as new as the hype suggests.
Michael ThiessenYeah. I think that's true for for a lot of things that there's always like this hype cycle, things come and go. It's trendy now, but it was trendy 10 years ago and, you know, we go through the cycle all the time, but reactivity and signals are very much linked. In fact, when I first was seeing this hype around signals, I was like, I don't really know what this is. I started to dig into it and I thought, wait, isn't that just reactivity in Vue?
Like what what's all this hype about? And I would say that the simple answer is, yeah, it's basically the same thing. The idea of instead of having to explicitly update state and then do something with that new updated state signals, let us write in a reactive way. And it's it's hard to it's hard to describe signals without using the word reactive because I think that's the for me, at least, that's the way that I understand it the best. But this idea is actually pretty old.
It comes I think, even in the eighties or nineties when it started was it was called reactive functional programming. So started with a bunch of researchers trying to figure out better ways of building software. So they came up with this system that uses functional programming languages like Haskell or, you know, pick your pick your favorite functional language and added on this idea of reactivity. Now they did this because UIs, as we all know, it's usually we are reacting to things that are happening around us. It's different than lots of other software, like, I don't know, embedded systems and and so on.
But we're we're dealing with lots of reactive events. You know, the the user clicks on something, they turn a dial, they you know, something like that, and we wanna react to that input. So they came up with this way of basically describing the relationship between an input or an event and how that changes a variable over time. And so instead of writing all of this code that says, you know, like have an event handler and then, oh, we gotta update this thing. And then instead of writing that all out in an imperative way, we get this more declarative.
Oh, this value here is directly tied to the position of the mouse. And we can just say there's like we don't even have to say when the most position updates update this value. We can just say, oh, this value is equal to the position of the mouse. And it does some fancy stuff underneath the hood, and it all works together very much in the same way that we're used to with writing Vue.
Alexander LichterSo that means when you remember about the reactivity episode, we talked about that there is no reactivity natively in JavaScript. And with with singles, that that might come to language, which we'll discuss in a bit. But that really sounds like a uniform way, let's say, to describe reactivity in in a certain language or like as we have in a framework.
¶ Functional Programming
But why does the whole hype come up now? Do you have any idea why why it certainly caused some traction and maybe some frameworks who who, like, use signals a lot, and and yeah. Why why why now?
Michael ThiessenYeah. So I was looking at the history of this, and I don't know if they're exactly what caused this shift into web development, but I know you're familiar with the RX JS library that has this idea of observables. I believe that started in Java for building applications. And then eventually that became a JavaScript library. But there were along the way, there were different frameworks and libraries that started to use this.
I think Knockout was maybe one of the first ones that had this signals based idea or reactivity or however I'm not sure what what term they were using for that.
Alexander LichterI think like fine grain reactivity or fine grain signals, something like that. Yeah.
Michael ThiessenYeah. Yeah. And I I've never actually used knockout JS myself, so I'm not even that familiar with it. But then I do remember that around the same time that React came out, I guess, and was starting to gain all this popularity. There was another framework called Elm, which basically was this reactive functional programming idea, but applied to web applications and it compiled to JavaScript and you could use JavaScript libraries with it.
But, it was harder. It's harder to use. It's still around. I don't know how actively it's being being worked on, but
Alexander LichterI've seen it every now and then mentioned for sure. Yeah.
Michael ThiessenYeah. Yeah. And it I think it was a functional language. It was based on Haskell, if I'm correct with that. And, I would guess that the reason it didn't gain as much popularity is because, first of all, Haskell is a little bit harder to understand. It's, like, very functional and a little bit harder to wrap your head around because of because of that.
Alexander LichterIt's like a very different concept, like functional programming in general. Like, once once you get started with it, it's lots of fun though. Like, as soon as you as soon as clicks, it's you wonder maybe why ever doing OOP or something like that.
Michael ThiessenYeah. It's yeah. It's a lot of fun. It's it forces you to think about the problems you're solving in a completely different way. So if if you've never tried functional programming, I would suggest it just just as, like, a fun thing. There's, like, Lisp or, you know, a whole host of these different
Alexander LichterOh, camels, which should be really fun, I heard. Yeah.
Michael ThiessenYeah. OCaml.
Alexander LichterFor for, like, what I tried, I really liked, which is also a bit more web developer centric, let's say, but not only is Elixir. Based based on, like, the Erlang, VM. And, like, Elixir is a proper functional programming languages. Also, like, immutable types. This is super fast, reliable. So can can highly recommend you to give it a try.
Michael ThiessenYeah. And there are a lot of applications built with these things, but they're just, like more specialized in some ways. So my guess would be Elm didn't get popular because of 1, it's functional and people are less comfortable with that. And 2, it's strongly typed, and I think so like TypeScript would be it's got, like, this type system. And I think it was before type systems were really, like, mainstream and people were comfortable with that. And so it's development. Yeah. Yeah. For sure. Yeah.
In web development specifically. And so I think those two things sort of made it, like, well, with JavaScript, you can just, like, start writing stuff and like hack things together. But with Elm, you have to really think through, okay, if I'm doing it functionally, I gotta like, think about it in this way. Oh, but then I also have to figure out the types that I'm using and you can't just like throw an any on there like you can with TypeScript. So you had to like really think through this stuff.
And so it's more of like a, more of a challenge to like, get this hello world or a to do list app built. But for me, at least, that was a major point along this signals journey. I don't know how much Elm inspired things that came after it, but that's something that I that I remember playing around with at that time.
Alexander LichterYeah. Totally makes sense. And another point of the the functional part is the whole, like, side effects part. It's like, okay, everything should be pure ideally, and then you have some, like, impure parts. And I I really like the pattern, but it's it can be really tedious to work with, especially in web development where ideally, sure, you would have everything strongly typed, but, you know, how how often we used any in TypeScript?
Often we well, back in JavaScript, we had nothing, and and still works in a way. And and sometimes you also simply don't know. Right? Like where we have, like, Zod and valibot right now for parsing, we could just tell TypeScript, hey, this is that, which we'll never know because it's like an API response. We can't possibly foresee what actual the type will be.
We need some some runtime validation if we really wanna make sure. Of course, these problems are solved in a way, but I think it's way more to use to get into the concepts than just say, okay, I'll just write that or write in any and that's fine. So I think the functional programming adaption, especially for for like front end development, it's really comes down to convenience to a certain degree.
Michael ThiessenYeah. And I think there's already so much knowledge and like other packages and things that are built in a different way that it's harder to, like, I feel like these things have to evolve slowly over time. Like we have TypeScript now, which is sort of like an evolution of JavaScript. It's not an entirely different thing. And so I think that makes a big difference.
¶ Signals in Modern Frameworks
Alexander LichterDefinitely. And well, now we we slowly come from the the part of its history to to moving towards the present. So what's the next stop on on the signal history?
Michael ThiessenWell, I think chronologically, Vue was one of the first of these more modern frameworks to use a reactivity system. And then after that come Svelte and Solid, which we're more familiar with today. They're still they're still around. They're still being worked on and and people are using them. And I think it's funny to me because like this whole conversation around signals, it seems at least at the beginning, seemed to leave out the fact that Vue had this.
And then it was like, oh, it's this new, this new thing. And then here I am thinking, but wait, is it new?
¶ How Signals look like in other Frameworks
Alexander LichterMaybe, maybe that's a good point to, get into details, like, just explaining for our listeners and and audience in general, like, how signals look like in most other frameworks except Vue and how to compute. Maybe more understand why it's less obvious for people. So commonly, for example, Solid.js, if if we hear signals nowadays, you usually think of, like, Ryan Carniato, someone who's very, very performance focused. I feel like I mentioned this in the Evan, in the Evan You episode already, and he he's really he'd really pushed signals forward, also in the in the matter of general availability with, proposal, which we'll come to in a bit. And so the idea is you can have a function that's just called, let's say, createSignal, and you can give it a default value for that signal.
So let's say you have a simple counter and say, createSignal(0). And what's the return will be, that depends a bit from framework to framework, but usually you have 2 things. You have like a getter and a setter. So you have one method that just gives you back the count. So you can invoke that count function and you get back exactly this, your counts.
And then you have a set count function, which basically you can invoke. And in there, you define your own function and say, okay, get the previous value and do something with the previous value, like the value plus 1 or just set it to a certain new value. And as soon as you invoke set counts, then the value of counts will actually update because, yeah, we have signals, we have reactivity, so that will change. And for everybody thinking like, wait, this sounds like a more complicated way to describe what we have with ref right now, just without the functions. Exactly.
That's the thing. Like in in in solid and preact and Svelte with ruins, it's also a bit different, but in Angualr, all having signals, We all have these concept of of a getter function instead of function. It's slightly different here and there, but we we don't have them in Vue at all. We just said like, okay, we have a ref and then we're good. We could build own signals in Vue.
I actually also did it in one of the videos, which is also linked below, with with the help of shadow ref because commonly signals are not deeply reactive. They're just, reactive on top level. You have that setter function and wherever that setter is invoked, the thing will update, which means you always replace the value. With ref's in Vue, don't you have to do you have, the whole like deeply nested reactivity. You can also do this technically with signals by nesting them, but, that's also a whole other story and depends a bit on framework to framework.
¶ Signals in Vue
But that's also more or less the reason why they're not that big of a hype word in Vue because we have implicit signals. Right? We don't have them as explicitly. They're just there.
Michael ThiessenInstead of calling these functions, oh, I'm gonna get the value for this. Oh, I'm gonna set the value. We just we just get the value. When we set the value, it's more like it's invisible. Like there's this sort of like, we don't have to think about it as much because it just happens.
And I think that's some people may view that as a bad thing because they want these extra things to be explicit and like, oh, okay. You are using signals in this part of the code. I understand that. Whereas with Vue, it's like, okay, you know, it's a Vue application. So you know that there's reactivity there. And that's, that's why you know that you can do dot value equals this and it'll just update or if it's reactive, you can just update the properties if you want.
¶ Signals vs. refs?
Alexander LichterExactly. I think one of the strengths of signals, and that's why it's usually compared to ref as well, is that you can you can pass the signal, around anyway. Right? We can pass the the getter further, only the getter, for example, or only the setter. With refs, you can't really do that. You can't really say, okay, I pass the getter and the setter around. You could have, computed with a getter and a setter and
Michael ThiessenRight.
Alexander LichterThen you might have a chance. But even there, like separating that is a little bit more effort, which means, okay, sure. You can expose the ref as readonly and then a method updating the ref. So you you you find your way around it, but signals, as you said, they're a bit more explicit and also what you can share with other components, and whatnot. So in signals, it's separated by default, with with fused refs.
You have to do it on your own if you really need to. But I also don't think it's inconvenient. It's actually the opposite. I think that level of abstraction and developer experience saves a lot of nerves, at least for me.
Michael ThiessenSo, like, what kind of benefits would we get from being able to pass just the getter or just the setter? You'd mentioned, like, a read only thing. You could pass in just the getter to some other function, and all it can do then is get the value.
Alexander LichterExactly. But Not, like, write on it. Yeah. So more of a separation of, like, of of capabilities. That common component can only read the value and not not change it.
Michael ThiessenYeah. Okay. But I guess in Vue, we have a readonly utility that helps us do that. And I guess, would there be values that are write only?
Alexander LichterWell, I don't know if we have writeonly, then probably you would have just a function that's like I don't know. Let's say user is a ref, and you pass down ref as read only user, They have set user, which takes any value that just does user that value is equals to the new value. That's commonly how I abstracted in some composables away because I don't want people to, like, mutate the user directly because maybe, I I want to have a watcher on that as well that does something or, like, I have some other side effects where I shouldn't just do it directly. And the logic into mutating that part should also be part of the the composable and not just, like, scattered around the application just to have a bit more more capsulation there. Yeah.
So in the end, I would say, like, that's probably why why nobody in the Vue community is, like, hyped around around signals in a way because we we have them already. They are included, in in the framework, in the reactivity system that you, as you said in the last episode, also can use anywhere in your own applications that are not Vue as well.
¶ A Standard for Signals
So I think one last point to to touch on could be pretty interesting is, that that signals will eventually become part of the ECMAScript standard, which mean they they will hopefully, be part of the language at some point.
Michael ThiessenYeah. There's this, TC 39 proposal for them, And it looks very similar to like what we were discussing with the get method, the set method. It's less magical, which would make sense because, yeah, it's less like what Vue has, where we just update things. And I think that makes a lot of sense because it's an addition to the language, not everyone's gonna wanna use reactivity or have it be reactive by default. And so it's like more of an opt in as opposed to just like a default thing.
And so I think that makes a lot of sense. I haven't, dug into this proposal, quite a lot yet, but, I mean, it's there if you wanna check it out.
Alexander LichterYeah. It's it's definitely worth taking a look at that and seeing how it is in a way similar. You have like still computed things and signals, which make sense, things depending on our things. We have effects all with which we talked in our activity episode. And it's also very nice to see that people from the different, let's say bubbles, the different ecosystems worked on it.
Like people of major frameworks, not only, for example, Ryan mentioned before who's reading to signals, but also of course, Evan took a look at it as well. Eduardo is listed in the contributors, for example, for the proposal. And there there are quite some people having eyes on it, weighing in and discussing what's in the end fits all needs in in the JavaScript ecosystem, but also doesn't benefit a certain framework over it. So more or less the best of of both worlds or all worlds even.
Michael ThiessenYeah. And I like, I like that this idea of having it baked into browsers and like a common system that all these different libraries can use? Because to me, it seems pretty clear that using signals or reactivity is like the right way to build UIs. And it's, it's interesting to think about, web development and I guess UI development too, as like in terms of the history of software development. And it's fairly new, but we're still in a way trying to figure out how to use JavaScript, how to build web apps.
And to me, this is something that is like, okay, components. That's something that we, we like, we'll keep that. And signals is also like one of those core things that I don't know, moving forward. I don't see a world where we stop building applications with signals or suddenly decide that it's a bad idea. Maybe there's like an evolution or like a new version of it that we'll see 10 years from now.
I don't know. But it seems like, oh, like the last 10 years ish, we've like really been figuring this out and it works great and it's here to stay.
Alexander LichterYeah. I also think, like, signals, won't go anywhere as soon as they are standardized because it's important to mention that the proposal, right now is, I think, in at stage 1. I think moved to stage 2 at some point. But if I see the repository correctly here, it is still stage 1. So it might take a little bit to actually make that standard, in into the language.
But in a way, it's also good because you don't wanna break the web. You can't change what's in there. And then having a signals too would be like it would be a bit, a bit tricky. So, like, it's it's fine that the frameworks have their own implementations and that the the general, like, the general implementations for for everyone that might take some time. And it's great that people pioneered that work, like, from from Lockout earlier on as we discussed and now all the frameworks using it.
¶ Benefits of Signals in the language
And eventually, we we get quite some benefits, but
Michael ThiessenMhmm.
Alexander LichterProbably for for you, dear dear listener, dear dear person in front of the screen or driving a car that's in the podcast or whatever, you probably will not use a lot of the native signals. Let's say if you work with Vue. Js, like directly, you will probably not say like new signal dot computer. You don't have to learn a new reactivity API.
The idea is that Vue and all the other frameworks, they will use signals under the hood with the goal to benefit on their memory usage, on their design, and in the end, get more performance. Thanks to that. But there's also one more thing. We talked about, VueUse in a few episodes ago or quite a few, but still. And we talked about it.
Vue use is working as composable. Right? We have, like, all the composables and you use, they are based on reactivity. And what if we could make Vue use, but for for all the people, for all the frameworks, because they all use signals. A VueUse would be based on signals, and then you have like your Vue composable and then your solid signal for that or your Angular signal, preact, quick, whatever.
So having a way for a global framework utility library that just works with all frameworks, if you have that little bit of integration, that would be pretty sweet. No?
Michael ThiessenThat's the the most interesting part of this for me is that the potential for that collaboration between the different frameworks and, like, it seems like there are fewer and fewer places where we can have framework agnostic packages, like, you know, a fetch library. Okay. Or validating user input. Okay. But even then it's like, okay, it's like tied to the specific framework in a lot of ways.
But then with the signals thing you can write, you could then write reactive composables that are framework agnostic. And if you want to switch between different frameworks, that's that's a lot easier in the future. And now if you use library, that's just like signals use library. I don't know.
Alexander LichterCould be fun. And I also think, like, even though we have probably a little bit of integration work to do with the frameworks, it's way less effort than rewriting that like we have it now. We have, like, React Hooks, like, a library for that. We have our VueUse and probably the same things exist for all the other, the other frameworks or will.
So, yeah, we can dedicate time for something more meaningful once again than like reinventing the wheel while we could all just collaborating at the same thing. I'm I'm really curious for that.
And, yeah, I think these are the the most important parts also why it's probably not that relevant for a framework developer to know like the signals API inside out. It still would be really fun to use when you have vanilla JavaScript and write your to do list, for example, because then you can actually get rid of lots of imperative code and just like, okay, If there is something changing, then please set that new value as, like, inner text or inner HTML, and you're good. That's also what's in the proposal as as like an example where you can see even totally vanilla to just create a counter Mhmm.
Will be a bit easier than just all that's manual DOM API work.
Michael ThiessenYeah. Well, I'm looking forward to it. And in the meantime, we can just keep using Vue and, get that reactivity and enjoy, using it.
¶ Vue.JS DE Conf 2024
Alexander LichterExactly. And if you're also enjoying Vue and, maybe it would, meet a few like minded people, go to a very awesome conference, then, the Vue.js DE Conference. So the conference in Germany for Vue. Js, in Bonn, this year in early October is right around the corner. So if you want to, there's a discount code. It's pretty simple. It's just DEJAVUE for some tickets. I'll be there. Some other people from the episodes like Daniel, for example, will be there.
There's live Q and A with Evan. It it would be lovely to to meet you all there. So definitely, have a look. And if you're interested, then, snag your nice discount and, join join a conference.
Michael ThiessenAnd if you want to keep listening or watching some Vue and Nuxt content that we've got, We've got a bunch of great past episodes you can check out. So do that wherever you're listening to this right now. Subscribe. That also helps us out and we'll catch you in the next one.
Alexander LichterExactly. See you soon folks.