DejaVue

It was teased in the last episode already and here it - Michael and Alex talk about the current hype in the front end development community: Signals. But if you as a Vue developer don't feel hyped around it and maybe even didn't hear much around it, fear no more - that is normal and will be explained in the episode too.

Join the two Vue experts covering the history of Signals, what's behind the term and how they work in Vue.js and other major frameworks.
And of course, the TC39 proposal to add Signals to the language itself wasn't forgotten either.

Enjoy the episode! 

Chapters

  • (00:00) - Welcome to DejaVue
  • (01:06) - Signals and Reactivity
  • (04:41) - Functional Programming
  • (10:51) - Signals in Modern Frameworks
  • (11:48) - How Signals look like in other Frameworks
  • (14:20) - Signals in Vue
  • (15:20) - Signals vs. refs?
  • (17:51) - A Standard for Signals
  • (21:54) - Benefits of Signals in the language
  • (25:16) - Vue.JS DE Conf 2024

Links and Resources



Links marked with * are affiliate links. We get a small commission when you register for the service through our link. This helps us to keep the podcast running. We only include affiliate links for services mentioned in the episode or that we use ourselves.

Creators & Guests

Host
Alexander Lichter
Web Engineering Consultant • Founder • Nuxt team • Speaker
Host
Michael Thiessen
Full-time Vue educator
Editor
Niki Brandner
Sound Engineer

What is DejaVue?

Welcome to DejaVue, the Vue podcast you didn't know you needed until now! Join Michael Thiessen and Alexander Lichter on a thrilling journey through the world of Vue and Nuxt.

Get ready for weekly episodes packed with insights, updates, and deep dives into everything Vue-related. From component libraries to best practices, and beyond, they've got you covered.

Alexander Lichter:

Hey Everybody, and welcome back to DejaVue.

Michael Thiessen:

It's your favorite Vue podcast. You just don't know it yet. I'm here with Alex.

Alexander Lichter:

Hey, 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 Thiessen:

I'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 Lichter:

As 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.

Alexander Lichter:

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 Thiessen:

Yeah. 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?

Michael Thiessen:

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.

Michael Thiessen:

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.

Michael Thiessen:

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.

Michael Thiessen:

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 Lichter:

So 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.

Alexander Lichter:

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.

Alexander Lichter:

Why why why now?

Michael Thiessen:

Yeah. 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.

Michael Thiessen:

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 Lichter:

I think like fine grain reactivity or fine grain signals, something like that. Yeah.

Michael Thiessen:

Yeah. 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.

Michael Thiessen:

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 Lichter:

I've seen it every now and then mentioned for sure. Yeah.

Michael Thiessen:

Yeah. 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.

Michael Thiessen:

It's, like, very functional and a little bit harder to wrap your head around because of because of that.

Alexander Lichter:

It'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 Thiessen:

Yeah. 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.

Michael Thiessen:

There's, like, Lisp or, you know, a whole host of these different

Alexander Lichter:

Oh, camels, which should be really fun, I heard. Yeah.

Michael Thiessen:

Yeah. OCaml.

Alexander Lichter:

For 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.

Alexander Lichter:

So can can highly recommend you to give it a try.

Michael Thiessen:

Yeah. 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.

Michael Thiessen:

And so it's development. Yeah. Yeah. For sure. Yeah.

Michael Thiessen:

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.

Michael Thiessen:

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 Lichter:

Yeah. 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?

Alexander Lichter:

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.

Alexander Lichter:

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 Thiessen:

Yeah. 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.

Alexander Lichter:

Definitely. 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 Thiessen:

Well, 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.

Michael Thiessen:

And then it was like, oh, it's this new, this new thing. And then here I am thinking, but wait, is it new?

Alexander Lichter:

Maybe, 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.

Alexander Lichter:

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.

Alexander Lichter:

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.

Alexander Lichter:

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.

Alexander Lichter:

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.

Alexander Lichter:

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 Thiessen:

Instead 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.

Michael Thiessen:

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.

Michael Thiessen:

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.

Alexander Lichter:

Exactly. 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.

Alexander Lichter:

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 Thiessen:

Right.

Alexander Lichter:

Then 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.

Alexander Lichter:

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 Thiessen:

So, 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 Lichter:

Exactly. 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 Thiessen:

Yeah. 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 Lichter:

Well, 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.

Alexander Lichter:

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.

Alexander Lichter:

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 Thiessen:

Yeah. 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.

Michael Thiessen:

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 Lichter:

Yeah. 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.

Alexander Lichter:

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 Thiessen:

Yeah. 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.

Michael Thiessen:

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.

Michael Thiessen:

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 Lichter:

Yeah. 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.

Alexander Lichter:

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.

Alexander Lichter:

And eventually, we we get quite some benefits, but

Michael Thiessen:

Mhmm.

Alexander Lichter:

Probably 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.

Alexander Lichter:

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.

Alexander Lichter:

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.

Alexander Lichter:

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 Thiessen:

That'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.

Michael Thiessen:

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 Lichter:

Could 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.

Alexander Lichter:

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.

Alexander Lichter:

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.

Alexander Lichter:

Will be a bit easier than just all that's manual DOM API work.

Michael Thiessen:

Yeah. 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.

Alexander Lichter:

Exactly. 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.

Alexander Lichter:

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.

Alexander Lichter:

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 Thiessen:

And 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 Lichter:

Exactly. See you soon folks.