Join Alex and Michael on a talk about a key topic in Vue.js - the reactivity system. Before diving into how it works in Vue 3, reactivity in Vanilla JS is covered. Then, the differences between the major Vue versions are discussed, showing an astonishing evolution in terms of DX but also performance when it comes to reactivity. Of course, the ref vs reactive topic can’t be left out, and neither can signals and vapor mode. Sounds interesting? Then tune in!
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.
Chapters
Welcome to DejaVue
What is Reactivity in general?
Reactivity in JavaScript?
Reactivity in Vue 1
Changes to reactivity in Vue 2
Reactivity system and caveats in Vue 2
Vue 3 Reactivity with Proxies
No IE11 support
Ref and Reactive in Vue
shallowRef, triggerRef and more
Why not shallowRef by default?
Vue's reactivity system as a standalone package
Vapor Mode
Wrapping Up
Join Alex and Michael on a talk about a key topic in Vue.js - the reactivity system. Before diving into how it works in Vue 3, reactivity in Vanilla JS is covered. Then, the differences between the major Vue versions are discussed, showing an astonishing evolution in terms of DX but also performance when it comes to reactivity. Of course, the ref vs reactive topic can’t be left out, and neither can signals and vapor mode. Sounds interesting? Then tune in!
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
Audio Engineer and Video Editor
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, welcome to DejaVue.
Michael Thiessen:
It's your favorite Vue podcast. You just don't know it yet. I am Michael Thiessen, and I'm a full time Vue educator, creating content and courses and books and all that great stuff to teach you about Vue and Nuxt. And I'm here with Alex, my wonderful cohost.
Alexander Lichter:
Thank you so much. Yeah. I'm Alexander Lichter. I am a Nuxt team member, a web engineering consultant by day, and also creating content around Vue, Nuxt, on YouTube, streaming every now and then, as Michael is also doing, by the way. Definitely check that out.
Alexander Lichter:
And today, we want to talk about one of, I would say, one of the characteristics of Vue, very typical, even though they have frameworks, they're named similarly and not not that much like the word reactivity in Vue.
Michael Thiessen:
Yes.
Alexander Lichter:
So Yes. It's it's a lovely topic. I think reactivity, when I started with Vue, was one of the things back in the in the Vue 2 times that really started clicking with me where I don't have to think about, oh, when does the component rerender and how to I don't know. There was not that much mental overhead. It it just worked magically.
Michael Thiessen:
Yeah. And just the right level of magic. I think there's always this tension in between how much magic and, you know, background things are going on in a framework. And sometimes if you have too much, it can be confusing because you're like, wait, how, how does this even work? Well, I don't understand what's going on, but the way that views reactivity system works, it sort of just feels like like this is how programming should work.
Michael Thiessen:
Like, I feel like even beginner programmers don't often realize that programming isn't reactive by default.
Alexander Lichter:
That's true.
Michael Thiessen:
You know?
Alexander Lichter:
Maybe maybe that's a good point to start on, like, not even focusing on you, but taking a step back and talk about what reactivity is and how it works in, let's say, quote, unquote, JavaScript.
Michael Thiessen:
Yeah. So reactivity, it's actually more common than you might think. If you think about spreadsheets like Excel or Google Sheet or whatever, those are really they're reactive because when you update one cell, it will trigger updates in all the other cells that use it. And so it's a familiar idea and it's a familiar concept. And when it comes to programming, we are basically trying to figure out when this variable updates or this object updates, we want to execute another function.
Michael Thiessen:
That's like at its most simplistic way description. That's, that's how I would describe it. When this value updates, execute this function. And we call these functions that get executed, They're typically called effects because they're sort of like a side effect. As you're going in the code, they they're sort of off somewhere else being run and executed, and you don't have to worry about them.
Michael Thiessen:
They're just sort of happening. And so that's what any good reactivity system or any reactivity system at all, it, it keeps track of that for you. It puts together, okay, when this value updates, I got to run this thing and I got to rerun that thing, and it's going to try and collect it all in a way that makes sense and optimizes it so we're not rerunning things extra and and all of that. But that's at its core, that's what reactivity is.
Alexander Lichter:
That totally makes sense. And I wonder, like, I don't know. If you have, like, JavaScript now and we define a variable, be it let or const, whatever people choose right now and the the current Twitter drama is about, like, how can we how can we make it reactive in a way?
Alexander Lichter:
Because I think lots of people struggle with with that in in JavaScript. Okay.
Alexander Lichter:
How do how do we add reactivity there?
Michael Thiessen:
Well, I think we're gonna touch on this a little bit later, but the easy answer is to use the, standalone package that Vue provides.
Alexander Lichter:
Fair.
Alexander Lichter:
Because there because there is no no way in playing JavaScript, like, to JavaScript doesn't offer reactivity out of the box, like, part of its paradigms in the language.
Michael Thiessen:
No. It does not. So you have to build that yourself, and we've already got it in Vue, so just, you know, stick with that. That's what I suggest
Alexander Lichter:
That totally makes sense. And I I think very often, like, people I don't know. Once again, like, vanilla JavaScript is a it's a great example. If you've ever built, I mean, you did, but probably some of our listeners didn't or maybe did this, like, to do list in plain JavaScript or any other, like, tiny thing with DOM updates here and changing things. Sometimes you would probably just wish, oh, if that variable updates, can you just update that part of the HTML, like what we have in Vue with everything, like class bindings, computer properties, the whole template.
Alexander Lichter:
And it it doesn't work. You have to do it manually. And you have, like, maybe you have listeners on a certain event, like, click and do something on that, or with with variables. You have to somehow somehow change them, do all the manual labor, and that's that's very unfortunate because the code itself, it doesn't really look pretty. It looks very imperative.
Alexander Lichter:
It's basically computer do this exactly what I tell you, not what what the logic behind it is. Like, the the idea behind it is really the, well, low level operations. And that's that's very often lots of boilerplate and overhead, not nice to read and not very declarative and descriptive.
Michael Thiessen:
Yeah. So for for those of you listening or watching who started with Vue maybe, or didn't have the, the opportunity to enjoy jQuery or writing these these web apps like this. Basically, like so if you have a to do list and you want to so in Vue, if you select something, you would have a selected class that you might want to put on there to change the styling to show, okay, yeah, you selected this in the UI. And in Vue, that's pretty obvious or pretty easy. We can just have a variable, we put it into the template, and then whenever that selected ref or however you're defining that, if that becomes true, then, oh, it's gonna apply that class and then the styling updates and it's straightforward and it's simple.
Michael Thiessen:
But before reactivity and all of this, we would have to bind to that button or the the checkbox or however you're doing your, your selection. And then you say, okay, you gotta handle that click. When that click happens, then you gotta update the list of selected items. Okay. Now you've got a new list of selected items.
Michael Thiessen:
You have to go through every single one of these items, and you either have to remove the selected class from the the Dom elements that are no longer selected. And then add back in that selected class to the ones that are now selected. So you have to do this all manually yourself. You have to traverse the DOM and go through each element and update things. And if the text changes, you have to do the same kind of thing.
Michael Thiessen:
You have to find the element that changed and redo the text. And it's just like a headache because there's so many opportunities for errors and bugs, and it's just really tedious. Exactly. Even describing that was tedious to me.
Alexander Lichter:
That's also what I what I just realized. Like, even the description of it sounds like a giant pain. But, yeah, luckily, we we don't have we don't have to do that anymore because when we use a a modern framework, almost all of them come with reactivity built in in a way or maybe using another framework's reactivity. Also, we'll touch on later on that. But when we when we take a look at Vue exactly, we could look a little bit back to the good old times of Vue 1.
Alexander Lichter:
It was probably before both of our times
Alexander Lichter:
I mean, at least I started with Vue 2. You also started with Vue 2. Right?
Michael Thiessen:
Yeah. I started with Vue 2.
Alexander Lichter:
So we we both didn't use Vue 1, but recently, we talked with Evan You. Yeah. You might might know the guy. Maybe you heard the episode already in episode 15, And he mentioned, a little bit about Vue one and reactivity there.
Alexander Lichter:
So the idea there was, like, Vue 1 had no compiler. Right? So there was some kind of reactivity system, but the idea was that the the frameworks of you was going through the whole DOM to, like, scan for things, like, walk the DOM and then execute the reactive changes. So there was no not not not too much magic behind us, like, we will see in the the next major versions of you. And, actually, there's still a a a very similar implementation, available nowadays, which is in Petite Vue.
Alexander Lichter:
So in that tiny, made for progressive enhancements, package that's basically a very tiny version of Vue, hence the French name, Petite Vue, that you can use. And that's, based on Vue's reactivity system, but how to actually apply the change, same idea. It would just walk through the DOM. But what won't work with this is things like server side rendering. And performance wise, if you have lots of lots of lots of items, it's also not super practical.
Alexander Lichter:
But luckily, that, yeah, that changed in Vue 2. Right?
Michael Thiessen:
Yeah. So, like, the Vue the Vue 1 implementation basically just takes away that tedious aspect from you without any extra modifications. But Vue 2, we have a more mature optimized version. The, the compiler was introduced so we can have this Virtual DOM. So what Vue 2 does is instead of going through the entire DOM, all of the elements that are rendered to the page, it has this virtual representation of what's actually being rendered.
Michael Thiessen:
And when it needs to do an update, it first, it updates the virtual version and then compares the old version with the new one. So it knows exactly what has changed. And so it can just target those specific spots without having to go through the whole thing and can just, yeah, zero in on on those exact places that need to be updated.
Alexander Lichter:
Exactly. And especially if you're a single file component. So if you like build your whole front end in Vue, have a build step, then of course, the compiler can optimize things where it knows, like, okay. This will this will never change even with, like, a runtime template. You you can say, okay.
Alexander Lichter:
Here is, like, the the double, curly brackets here is is like an insertion or, like, string interpolation, and this part is just plain HTML that will never change. So that's that's a a really good way, that Vue two with its virtual DOM, improve things. Especially when when the virtual DOM was introduced back in time, the browser DOM was not really that fast. That's also why other frameworks, relied on virtual DOM because it was simply easier to do the calculations on your own than just letting the browser check all the things because it was simply not optimized for that.
Michael Thiessen:
Another change that not a change between Vue 1 and Vue 2, but between 2 and 3 was how the actual reactivity system itself was done. So the original implementation of Vue's reactivity system relied on this Object.defineProperty, and that method basically lets you set or modify an existing property on an object. And so essentially what what was going on is when you put things in that data block in your your component, if you're using the, like, the options API, which is what we had back in Vue 2, then it would take that data object and for every single property that you've got defined on there, it would basically redefine that and wrap it in a custom getter and a custom setter, and using that could track the dependencies and know, okay, the, this value depends on, on this and, and it could figure that all out. But there were a few issues with that implementation.
Alexander Lichter:
Yeah. There were there were quite some caveats, especially if you let's say, you have just a new Vue(), for for everybody still, knowing Vue 2 had, like, this new Vue(), and then you could pass in, like, whatever the the component definition might be, like, the the parts the options of that that instance. And they could say, okay. Let's, let's just pass in for for data, an object, and you can just set, like, I don't know, name and set it to a name. And now that object and with that key value pair name and a string, that's that's reactive.
Alexander Lichter:
But if you would then and you can do it in JavaScript. Right? Just like add another key value pair to that, like, age, for example, that isn't reactive then anymore. So all the keys, even if you might not use them straight away and the key the values, they have to be present in the beginning. And, also same idea for arrays.
Alexander Lichter:
Like, it there were a few caveats that really made you program in a certain way to not run into them. I also would say it's in a way a good idea to ensure that all the keys are present, especially in times of TypeScript as well. But back in Vue 2, TypeScript support was well, we had class components and the rest was trickier, let's say.
Michael Thiessen:
Mhmm.
Alexander Lichter:
So, most of the times, the caveats weren't that that tricky, if you had, like, a a nice and clean way of programming, but we all know that we we don't always go for the cleanest and best way. And sometimes even I remember I was wondering, like, okay. Is this my logic that's buggy? Is that because I run into a a reactivity issue? Because, like, sometimes you had the fluent rules to to check them, but not all of them were easily to to discover.
Alexander Lichter:
So every now and then, it was also a little bit of a headache if you don't choose, like, an elegant way to program.
Michael Thiessen:
Yeah. And I I wrote a really long article on debugging reactivity and most of it is from Vue 2 because of these inherent issues and Vue 3, there's not really a lot of reactivity, like funniness that you can get into. And I remember many times I've I've even set, like, in that data portion, just setting a value to undefined because if it existed when the component was created, then it would be made reactive.
Alexander Lichter:
Then it's safe.
Michael Thiessen:
And Yeah. And then it's safe and you're like, okay, good. And then you can keep going. Or, yeah. Are there like with arrays, you have to like, you can't just push things into an array because this getter and setter wouldn't detect it in the same kind of way.
Michael Thiessen:
You had to like add these extra methods to, like Yeah. Or or Didn't there's a lot
Alexander Lichter:
Didn't push work? And, like, if you if you, like, access an index directly, it didn't work? Like, adding, I don't know, like, array 100 or something when you feel like a gap in between? There were some there were some weird caveats for sure. If you're lucky, though.
Michael Thiessen:
There was something yeah. Or, like, setting oftentimes when you're working with arrays, you might wanna, like, set it to an empty array, and then all of a sudden Yeah. That will also lose reactivity.
Alexander Lichter:
Exactly. Yeah.
Michael Thiessen:
Yeah. It was it was a confusing time, and I think I've forgotten a lot of, like, the the caveats because
Alexander Lichter:
Which is good.
Michael Thiessen:
Yeah. I don't need to remember them Exactly. Which is
Alexander Lichter:
Also fantastic. The link to the article, from Michael, of course, it's in the in the show notes or in the description if you watch that on YouTube. So don't forget to check it out if you're still using Vue. Or are you like, hey. Wait.
Alexander Lichter:
Caveats? Never heard of that. Let's check how it was back in the good old times, and how it's now in the better times. Well, luckily, Vue 3's reactivity, it's it's not based on that, let's say, hacky workaround that, Evan came up with, like, hacking around with object defined property and, like, using getters and setters because we don't have, a disk anymore in, like, the composition API. Well, we we can still use the options API in v three, but now the whole system is is based on proxies.
Alexander Lichter:
So how does that exactly work?
Michael Thiessen:
Proxies are are an interesting JavaScript feature, which let you do some some fun stuff. So basically, a proxy is like you can think of it as like the special object in a way. And with this proxy, you can take an existing object and wrap this proxy around it. And this proxy will let you intercept any time that you want to access a property or set a new property on this object. It also lets you do some other things which are probably less less useful.
Michael Thiessen:
But basically, anytime you go object dot and then access some property, that proxy will be triggered first. So instead of in Vue 2, where we had this, defined property that was wrapping with a custom getter and setter, we can actually do this dynamically on the fly. So when you add a new when you're going to set a new property on an object, it will trigger the, the set function in this proxy. And so then we don't have all these, caveats because it'll, it'll do it on the fly. And even as you access like nested properties and things like that, it will track that reactivity down because we've accessed it on on the root object.
Alexander Lichter:
Yeah. That's that's pretty sweet. Like, I remember when I when I teach about proxies usually in one of my JavaScript workshops, then I do, like, hey, implement the the dot notations. You could have, like, a very nested object and you could do, like, a dot b dot c and get the value from, like, exactly that. That's always a a fun case so you can see what power proxies and, like, the whole meta programming he has.
Michael Thiessen:
I think one time to to try and understand proxies better, I I implemented an immutable library. So like
Alexander Lichter:
That's cool.
Michael Thiessen:
It would you you would use a proxy to wrap an object and it would make that entire object immutable. So you couldn't change the values. But the the really, like inefficient way of doing this would be to do it for an entire nested object and like recursively go down through the entire object. But you actually don't need to do that with proxies because you've got this get that you can intercept and you can just say, well, if you get a nested value, well then, when I return that to you, I'm just gonna dynamically wrap that in a proxy and make that immutable. So it like as you access things, it makes them immutable.
Michael Thiessen:
And when you try and set it, it will just return a new immutable object. And so you can, like, yeah, do you can do all sorts of fun, interesting things.
Alexander Lichter:
That's pretty cool. And on on that note, also, I wanna highlight this vlog. I'll also link for that in in the description slash show notes, which is from, Mark Backes, who was also on the show a few episodes ago, and he built a time machine, with proxies. So that's also fun talk to visualize. Oh, yeah.
Alexander Lichter:
Definitely definitely check that out. And, yeah, with with proxies, all the the caveats of of Vue 2 reactivity are gone. There's only one new caveat that came with that, which means no support for IE 11. Shocking. I mean, luckily, most of us don't need to support IE 11 anymore, all of those out there.
Alexander Lichter:
If you still need to, first, leave a comment, and second, our condolences, thoughts, and prayers because Yes. That's tough. That's tough. All the cool features, you sadly have to miss out. But I think also on that note, the ecosystem really changed with so many frameworks deciding to drop IE 11, not supporting it anymore.
Alexander Lichter:
For example, Vue wants to bring, like, a a legacy build that still supports it, but it's almost just like, yeah. No. Let's let's just not do it anymore because it's it's not worth the effort.
Michael Thiessen:
Yeah. I I remember being lucky enough that I think well before most things were dropping support for IE, then I was yeah. The place that I worked at was like, you know what? We're just not gonna worry about it. So sorry.
Michael Thiessen:
Sorry everyone who who's using that.
Alexander Lichter:
And, yeah, I mean, I think now it's like below 0.1% or something. I mean, like, can I can I use, we'll tell you, when you listen to the episode? Also, think think for that in the notes if you really wanna know how many people use it. But it's it's usually not significant except you work for, like, oh, yeah. Certified government systems that only have these and these browsers and a hard to update, which is a super edge case.
Alexander Lichter:
It might be the case, but, yeah, then it's it's tough.
Michael Thiessen:
So the next thing we wanna talk about before we, keep going here is ref and reactive and how they work in Vue 3. So basically, these are the ways that we, in the composition API, define reactive values. And there's some confusion between, oh, do I should I use ref? Should I use reactive? And actually, like, if you look at the implementation in Vue's source code, they actually are using the same code, really.
Michael Thiessen:
So if you pass an object to ref, it's, it's the same as passing an object to reactive. I forget which way it works if ref calls reactive
Alexander Lichter:
Yeah. Ref calls reactive under the hood.
Michael Thiessen:
Yeah. Right. Okay. So if you, yeah, if you pass an object to ref, then it's actually just going to call reactive. So don't worry about that too much. The main differences there are whether you're able to just access the property straight up or if you have to do the dot value syntax.
Michael Thiessen:
Those are the that's really the main gist of it. I wrote a very long in-depth article on this, if you want to, like, dive into it.
Alexander Lichter:
I mean, the the shorthand also is reactive doesn't work for all data types. Right? If you just have a string, you can't just do, like, reactive and then Michael, for example. You have to have an object that holds something. And if you now think you have reactive, then you have an, like, an object in there and you say, how what's could the the key name be value maybe?
Alexander Lichter:
And then you say, okay. The value is the string Michael. It kinda looks like ref already. So, you you can somehow reproduce the structure there too, but I think most people in the community, and I think that's also what, was mentioned in your in your article, they prefer ref over Reactive. I've even seen some people voicing opinions saying like, oh, yeah.
Alexander Lichter:
Maybe we should deprecate Reactive. And I I don't think that's a necessary way to go because it's still super helpful if you have things you wanna group together, like form states, for example, or if you just wanna say, hey. I want to reproduce what Vue 2 or, like, the options API in V2 did with data, or the good old Vue 2 observable, which we didn't even mention, which was it's basically like data but stand alone. So it still serves a purpose, but I personally also am a big fan of, deciding whether I want to use the the reactive reference. So, like, okay.
Alexander Lichter:
Here is something holding a reactive value, let's say, a string, or I pass the value directly. So I am in control whether I say, okay. Do I want to work with with the proxy that will track reactivity and continue changing when something changes? Or do I just wanna say, okay. I take the string from here on, and I'm good.
Alexander Lichter:
While in reactive, you really can't do that because you don't see if a value is reactive. If you define it by reactive, you don't have, like, a dot value or something. It doesn't give you extra type. It's, like, really under the hood and subtle, and I like this expressiveness in the code there.
Michael Thiessen:
And one interesting thing about reactive, which I think not a lot of people maybe understand. And I think I learned this from Eduardo, who I I forget exactly where, but he was wrapping a set or a map object in reactive. And then that it just, because of the proxies, it just works. And like you can have these reactive objects. They don't have to be just like plain old JavaScript objects.
Michael Thiessen:
You can wrap other things in them. And I haven't tested this, but I, I would expect that, like, if you have other, like, non reactive libraries that you're using and you need to get them to be reactive, you might get pretty far by just, you know, checking it inside of a reactive and, seeing how that goes. Although there might be some edge cases that you might wanna There might.
Alexander Lichter:
Yeah. Same with, like, classes. Like, it works with directivity API, but there are some caveats. So also there, use use them with caution. But that's true.
Alexander Lichter:
That's the beauty of of reactive that you can pass in maps and sets, and, it will it will just work, which is which is pretty lovely. So also there, I there is no necessarily black and white. I still think it's it's a good recommendation to say use ref unless you have a good reason not to. Like, oh, yeah. I want to group form state together, and, I I want to deal with a map or a set, for example.
Alexander Lichter:
So that's that's all totally totally valid. But I think also in a as I said, the expressiveness and being able to say, okay. This is definitely reactive versus it's not anymore compared to, oh, yeah. We don't really know because TypeScript can't tell and our code may not. That's a big benefit and big plus for ref in this case.
Michael Thiessen:
Yeah. And with ref, we also get a shallow version, which can be really useful for performance optimization. And, in Nuxt has been making changes to how the data fetching work works to shift to using the shallow ref by default. Yeah. So can you explain how that that works?
Alexander Lichter:
Absolutely. I already did in in one of her videos, which is also linked below as usual, but, a a very quick summary. The idea is right now, ref is deeply necessary active. So if I have have, like, a big object, let's say, I don't know, a kilobyte of JSON and then represent it in JavaScript object. And then if something changes there, maybe if you refetch data, that's a perfect example, then, well, Vue has to go through everything and and check if something deep down changed or not.
Alexander Lichter:
And very often, there are cases like data fetching where you don't want that deeply necessary activity because, okay, if I fetch data, fine, I get the new response. I can just replace the whole content of that ref. And then if I fetch it again, say, maybe just replace it. I rarely have to edit things, like, in place. Sometimes I do maybe a computer property based on the ref and then say, okay, this is like, I don't know, the user's pet name or whatever.
Alexander Lichter:
And I don't change things in there straight away. So whenever you have that case, another scenario is, for example, integrating, third party state libraries, like immutability and things, then, okay, there's a new state. I don't want to edit it in place. I just want to take the new value and use it. ShallowRef is is the way to go.
Alexander Lichter:
And there's also a shallowReactive for that, by the way. So we have the the equivalents for both. And, yeah, commonly, it's it's a really good scenario for performance optimization when you have big data structures. Otherwise, I probably wouldn't bother, to change things around. So it's it's really more like a, it's it's a low cost change.
Alexander Lichter:
Just have to keep in mind that you cannot like, the the ref doesn't automatically sorry. The shallow ref doesn't automatically update when you change things, only when you replace the whole thing. There's one thing, though. There is another function called trigger ref, which will basically trigger an update for ref, which you can also use with a shell or if you say, like, okay. Maybe I edited something here and I just wanna trigger an update because, I don't know, your state library does something weird or you have a certain case where you wanna do that.
Alexander Lichter:
That's totally fine. Then you can combine these 2 as well.
Michael Thiessen:
Right. So you can have that full control over it so that it won't update unless you have like a very specific situation. Yeah.
Alexander Lichter:
Exactly.
Michael Thiessen:
And I would agree with you on the on the, not using it by default. I don't know if I've ever used it because I haven't run into a, like, a performance issue where I needed to to, you know, prevent some rendering or whatever updates. And so, yeah, I thinking about it, I would worry that if you just use shell ref by default everywhere, then you might get confused because you're trying to update something and it's not working and you're like, wait, what's going on? And it's probably just better to use ref, by default.
Alexander Lichter:
Yeah. I would say so too. Even though some people argue that, like, oh, yeah. Why don't you shallow ref by default, not only ref if you need, like, nested reactivity, especially the people coming from other frameworks where it's not that common to have that deeply nested, like, tracking based productivity out of the box, they thought, okay. This is this is super strange to me.
Alexander Lichter:
Like, why is it not that way around? And in the end, I think it's first, it's about teaching it. And, I mean, ref has been the main, API for for a while. And having that convenience out of the box and switching to the more performance oriented solution is, my opinion, a better way than saying, oh, we want to optimize everything by default and then maybe lose on DX because maybe then people are not aware of of ref, but it would be of shallow ref, or maybe it would be named differently. I don't know, deep ref and ref, and people are like, what's a deep ref?
Alexander Lichter:
So, in in on that case, I I really think it's it's it was a good idea to choose ref and reactive and not, the the shallow versions, like the not deeply reactive ones by default, which also aligns with what the composition API gave us, also deeply Nesta's reactive to
Michael Thiessen:
you. I have this, sort of rule that I or like rule of thumb where sometimes you see something like this, where it's like, oh, shallow ref is more performant. And so then the next thought is, well, if it's more performant, why isn't it the default Mhmm. All the time? And if it's not the default, then there's usually a good reason why it's not the default.
Michael Thiessen:
And there's there's trade offs there that the people implementing it have thought through. And maybe it's just it could be as simple as it would be a break and change. That could be one good reason, but there are often trade offs. And if you think about it a little bit more and like dig in a little deeper, then you realize, oh, okay. It actually makes more sense that the more performant version is not the default.
Michael Thiessen:
And like, because because otherwise it would, they would just make it the default. Like, why would you make it slower by default?
Alexander Lichter:
Yeah. I mean, also in that way, like, probably writing, assembler is faster than writing, I don't know, c plus plus and still most people write c plus plus or, like, Rust or whatever.
Michael Thiessen:
Yeah.
Alexander Lichter:
It's always, like, also, like, an abstraction thing and convenience. So True. We have all this abstraction on top for for exactly that reason too. And the good part is I mean, if we take just JavaScript, we also say, like, we don't write, like, a for loop with, like, an actual, like, for that I equals 0 and so on. We rarely do that nowadays because it's it might be more performant than, like, a for each or, like, a a for off loop.
Alexander Lichter:
Not sure in the latter one, though, but for each definitely is a bit less performant. But does it matter? Very often not. And if it does, then why not refactoring the code saying, hey. Okay.
Alexander Lichter:
This needs to be fast. This needs to process, like, millions or billions of records. And that this hot part is optimized, to to the fullest extent. There you go.
Michael Thiessen:
So I did mention it earlier, but, I want to make sure that we point out that Vue's reactivity system is available as a standalone package. So Alpine JS uses this internally to have reactivity and you can implement, or you can use it yourself on whatever kind of project you want. If you want to make your own front end library, then you want to get that reactivity. You could just, you know, put it in. And there are no external dependency that works great. And...
Alexander Lichter:
It is tested, that is very important.
Michael Thiessen:
...It's very yeah. It's very well tested and, you know, used all over the place because this is what Vue uses internally. And yeah, it's a great way. I'm glad that Vue 3 switched to this very modular package based system with like all the different, pieces separated out so that we get this reactivity system separated out. So if you want to write some node application that has reactivity in there, or, you know, I have I have no idea.
Alexander Lichter:
If you've used the back end.
Michael Thiessen:
Do it.
Alexander Lichter:
Yeah. That's that's true. Or you can even use it in your current, I don't know, jQuery. I mean, they can also just, like, use petite Vue or of you directly. Or let's let's think about it now.
Alexander Lichter:
You have a a React app that you wanna convert to Vue at some point. It's not with reactivity or even saying, like, no. I don't wanna convert, but I I really enjoy that reactivity pattern. So why not using it? It works.
Alexander Lichter:
It's it's totally fine. And, yeah, Michael, as you mentioned, there are also other, like, tiny, like, front end, like, libraries using it. Petit Vue also earlier one of them. And, besides Alpine, also Arrow JS from, Justin Schroeder, FormKit author, is also using user reactivity under the hood. So, yep, definitely play around with it.
Alexander Lichter:
You get, like, the computers, the watch, the ref and reactive, and the shallow versions, and, a couple more things like a few utilities here and there. And it's worth it if you just say, like, I don't wanna need a full blown framework or just gonna build a tiny thing on my own. And Vue's, Vue's reactivity system, I think, is is super accessible to people because you don't have to learn about, all, like, I don't know, all these these fancy things. You basically go with, like, okay. This is a ref, or or reactive.
Alexander Lichter:
You have these these two choices. You can just use ref, and it's fine. And then you can, like, have a computer property based on that. You can watch things. You can, and then do even more advanced things.
Alexander Lichter:
But in the end, it's also interesting that this is, well, one of the first modern frameworks that has, like, a signal based approach with this composition API. But, yeah, we we make a a separate episodes in signals and why there there is no, let's say, quote, unquote signals and Vue directly. Just wanted to mention it there. So if you haven't heard about signals yet, you probably can just look it up. Also take a look at the current proposal and check out the episode when it's coming out.
Michael Thiessen:
Yeah. So the last topic we've got for today is vapor mode coming in the future, near future, perhaps to Vue, a more performant way of compiling and, rendering your your apps, your components. And it comes with some changes to how reactivity works.
Alexander Lichter:
Exactly. So then we take a look at the template part. Like, before we we talked about the script part of it, we talked about template part with the virtual DOM, which is not that relevant for the script part. I mean, they work together in the end. But, yeah, vapor mode, the script part stays as it is as long as it's composition API or the script setup part because, otherwise, vapor mode is, not not working.
Alexander Lichter:
It only supports that at the beginning. Maybe will support options API at some point, but that's, that's not on the list right now because as Michael has just said, it's it's a work in progress. There are there are some really, really nice commits, and there's some really good, efforts there in the repository. You can try it out already. And the whole idea is that, okay, Vue has a virtual DOM.
Alexander Lichter:
And as mentioned before, it worked pretty well when the browser DOM was pretty, let's say, slow. And then frameworks came around saying, okay. We don't need a virtual DOM. Svelte came around and said, hey. I I just compiled myself away.
Alexander Lichter:
I'm just gone. It was faster. And then on top of that, Solid came around, and, Ryan Carniato, who is amazing in terms of performance, found out that there's an a pretty amazing way using signals, to basically also declare effects for each part of your component, of your template, and make it extremely fast. So, also, there, the idea of Vapor mode is to have, like, a solid like architecture. It's not 1 by 1 the same thing, but also using the power of of signals and these tiny effects, so reactivity everywhere, to make sure that the DOM is, updated even even faster.
Alexander Lichter:
And even though very often the bottleneck is rarely the framework as in, oh, yeah, if you render these 10 items, then probably the API call will take longer than the framework renderer. But what if you have, like, a big data grids or, like, data visualization, also very important, where it's really necessary to, like, transform these SVG elements or create all these new tiny nodes? Then there is a big difference for sure. So web remote, which we'll definitely also talk separate when it comes closer and closer to the release. Once again, you can try it out already, and it's working pretty well.
Alexander Lichter:
That that will be another thing for DejaVue. Did you already try it out, Michael? Did you already had a look at the at the REPL?
Michael Thiessen:
I have not, tried it out, but there's this the the playground where you can see you can write some view code and then see what it gets compiled to, in in vapor mode. And it's really interesting to try to see and and understand how it actually works.
Alexander Lichter:
That's definitely the case. And I'm I'm very I'm very happy to see that vapor mode is coming as a response to okay. You you it's opt in. You don't have to use it for your whole application. You can if you want to.
Alexander Lichter:
You can use it for components that that need that benefit, which is also great. Like, you can, decide, oh, this component, I render it 2,000 times. Perfect. This should be
Michael Thiessen:
Mhmm.
Alexander Lichter:
A component, we use the vapor mode and maybe the component's running a component, but the rest of the app can stay as is, which also makes possible migration easier. Think about you have options API everywhere, vapor mode only composition API or script setup. So then you just have to convert 2 components and stay as the rest can stay as it is. So I really like that progressive approach there. That's once again a core identity of of the Vue framework.
Alexander Lichter:
And I also like to see that, well, even after more than 10 years, there's still innovation and, there's still modernness coming in.
Michael Thiessen:
Yeah. And to tie it back into the reactivity talk that we were having before. So if we go back to that to do list, where before Vue and reactivity, we were needing to like manually update everything in the DOM ourselves. Well, imagine that we, we don't get the template stuff from Vue, but we get the standalone reactivity package that Vue has.
Michael Thiessen:
Now, if we took all of the variables that can update and we actually wrap them in a watch or a watch effect, and inside of that, we write our vanilla JS that goes into the DOM and updates the classes as necessary or updates the text for the different nodes. That's essentially how vapor mode is working. I think that's a maybe a good, good way of thinking about it. It's got like each little update to the DOM is wrapped in this effect so that it knows, okay, when this variable updates, I need to update the class name here. When this variable updates, I need to go and change the text on this DOM element here.
Michael Thiessen:
And so instead of doing it all as one big thing with the template and the the vNode, the virtual DOM and all that kind of stuff. It's as as Alex was mentioning, it's like this fine grained, very tiny, little reactive updates kind of sprinkled all over Exactly.
Alexander Lichter:
And that allows, like, even further optimizations because then you know exactly what will be updated and what won't because it's it's not very common that, like, your whole component, like, straightaway, every tiny piece changes. It's more like, okay. Maybe one part of it will change. The rest will stay the same. So, then you don't have to go through the VDOM and check what what will stay and what will not stay.
Alexander Lichter:
You just have to execute the functions, the, like, the the f acts, so to say Yeah. That will change. And, of course, then we also have to add the compiler into that. So the compiler can optimize a lot of things, which is I think what the the Vapor team is on right now, also what what Evan said a couple episodes before. That's then as soon as the the feature parity, with with the basics are are there, then, it's performance time.
Alexander Lichter:
And
Michael Thiessen:
Mhmm.
Alexander Lichter:
I'm I'm really curious to see the benchmarks on that because, also there, I I think with the Vue compiler and its power, vapor mode and the fine grain reactivity, we will see a big jump there. And, again, in certain parts, it will make no difference for application. And in certain part, it's it might be a huge one. I'm especially curious how it will be with server side rendering, how that will change there, if
Alexander Lichter:
that will be, like, a bigger overhead, it will be faster. Probably the second, but, yeah, we'll we'll see.
Michael Thiessen:
Yep. And I think that's the end of our episode here on reactivity. If you have any questions about reactivity or wanna know more, please drop a comment on YouTube or wherever you're at on Twitter. We're watching and reading those comments, and so your feedback is greatly valued.
Alexander Lichter:
Absolutely. And, yeah, let us know, if if you like something, especially about views for activity system or if, like, oh, there is this one thing. I wish it would be different. Please let us know. Maybe, one day it will be changed or at least, we we can cover it and say why it is so horrible.
Alexander Lichter:
I'm kidding. But still let us know. We're we're really, interested in in all of that. Of course, check out the episodes before because, I mean, we had 2 amazing episodes with Evan You. We had amazing other guests as well.
Alexander Lichter:
So please listen to all of them, all of these episodes. Check out, Michael's YouTube, Michael's website, and take a look. Maybe it's a a stream or a a video in the description. And with that, I hope you see you for the next episode or some before. Wish you a good day.
