You either completely missed the magic part that makes this so much more performant or you just didn't show it in the video (for some reason, though I can't think why you wouldn't). If you go back to the playground, and bring up JS tab, you will see the lines that says `_renderEffect()` This acts like a watcher, for selectively updating the dom directly, with no vdom. You will see in the non-vapor mode, the component outputs a `h()` function, which is your render function for the component.. This is the thing that updates the virtual dom. Which then goes through the virtual dom and updates the real dom.. But, it runs the h() for anything that updates in the component. This part is now GONE... Now its SUPER selective... 1 computed changes, it runs ONLY the code to change the Dom element that receives that value.. The rest of the component is left alone.. THIS IS GREAT NEWS... Though, I suspect a lot of people will realise they have some badly wrote components because of this.. Currently, it's possible to write a bunch of data to some non-reactive variables, and guess what happens? Nothing, as you expect... But the moment you write something to a reactive/ref, the whole component render function gets re-run and this includes reading from the non-reactive variables.. And the whole component is made "uptodate".. Now, with Vapor this WONT happen... If you data is non-reactive, then it's NON-REACTIVE.. END OF.. When you write a value to a reactive/ref, it will ONLY update the part of the DOM that deals with that reactive/ref.. I can tell you, I have taken advantage of this in the past, and I know a few of my co-workers have accidently made this mistake in the past but other things caused the component to update also, so the problem was missed.. So, I think some people will find some bugs in their code because of this, but blame Vapor for not understanding correctly..
As a freelancer I work with multiple vue versions, one is 2.6 with options api, all others are composition api, some are 2.7, some are 3.x and most are with script setup and Typescript of course. Having to work with options api is so restricted and relies on so much "IDE magic" to make sense, it feels like a time-travel back 10 years. Still better than jQuery but way worse than even 2.7 with composition API + script setup. If I had any choice, I would never ever go back to options API. I only do it, because of the strict dogma of that project (heck, you could just update that one to 2.7 and just start using composition API, but the frontend boss would rip all our heads off...).
Yes any time a component changes vue has to go down the tree hierarchy from the component that changed & lower to check if it needs to rerender any of the sub components. So the walking of the tree is eliminated. With vapor mode it has subscribers & it knows exactly what components where it needs to to change rather than having doing a diff on every node in the entire subtree.Its not only more performant it also has memory improvements. Its not only similar to svelete but also very similar to the way solidjs works. I'm exicted.
And soon we are close the circle and return from vDom (stupid) idea to local DOM templates. At rising of AJAX technology, we are already having small libraries for this task to use addressed templates at html source, but who care - use Backbone, use Angular, use React instead - its looks like solid solutions, like other boilerplates in Java. So, in my (wrong) opinion Java devs do all of this mess. Perfectly designed totally unnecessary overengineered mess.
I've been subscriber for couple of years. Unsubbed bc cannot look at this preview images anymore, just can't... Looking for some quality content, not teenage dramas content.
@@radekmvm lol they’re cheesy for sure but it ain’t that serious that I would unsub. He’s got great content. I just hate that he has to resort to this kind of stuff, it feels so demeaning
You either completely missed the magic part that makes this so much more performant or you just didn't show it in the video (for some reason, though I can't think why you wouldn't).
If you go back to the playground, and bring up JS tab, you will see the lines that says `_renderEffect()` This acts like a watcher, for selectively updating the dom directly, with no vdom.
You will see in the non-vapor mode, the component outputs a `h()` function, which is your render function for the component.. This is the thing that updates the virtual dom. Which then goes through the virtual dom and updates the real dom.. But, it runs the h() for anything that updates in the component.
This part is now GONE... Now its SUPER selective... 1 computed changes, it runs ONLY the code to change the Dom element that receives that value.. The rest of the component is left alone..
THIS IS GREAT NEWS... Though, I suspect a lot of people will realise they have some badly wrote components because of this..
Currently, it's possible to write a bunch of data to some non-reactive variables, and guess what happens? Nothing, as you expect... But the moment you write something to a reactive/ref, the whole component render function gets re-run and this includes reading from the non-reactive variables.. And the whole component is made "uptodate"..
Now, with Vapor this WONT happen... If you data is non-reactive, then it's NON-REACTIVE.. END OF.. When you write a value to a reactive/ref, it will ONLY update the part of the DOM that deals with that reactive/ref..
I can tell you, I have taken advantage of this in the past, and I know a few of my co-workers have accidently made this mistake in the past but other things caused the component to update also, so the problem was missed..
So, I think some people will find some bugs in their code because of this, but blame Vapor for not understanding correctly..
Thanks for the detailed explanation!
The Vue 4 foundation. Remember this moment.
Still Vue supports vue-ui to manage Vue projects? I mean creating project, adding or removing dependencies and so on...
vue3 has been around for a bit, an options vs composition vote would be interesting.
options api makes you gay
As a freelancer I work with multiple vue versions, one is 2.6 with options api, all others are composition api, some are 2.7, some are 3.x and most are with script setup and Typescript of course. Having to work with options api is so restricted and relies on so much "IDE magic" to make sense, it feels like a time-travel back 10 years. Still better than jQuery but way worse than even 2.7 with composition API + script setup. If I had any choice, I would never ever go back to options API. I only do it, because of the strict dogma of that project (heck, you could just update that one to 2.7 and just start using composition API, but the frontend boss would rip all our heads off...).
is this the mode which makes DOM operations more efficient? that's the main point?
Yes, in short
And no vdom
performance benefits?
the browser doesnt need to download the Vue library, it compiles to pure JS
Yes any time a component changes vue has to go down the tree hierarchy from the component that changed & lower to check if it needs to rerender any of the sub components. So the walking of the tree is eliminated. With vapor mode it has subscribers & it knows exactly what components where it needs to to change rather than having doing a diff on every node in the entire subtree.Its not only more performant it also has memory improvements. Its not only similar to svelete but also very similar to the way solidjs works. I'm exicted.
@@RockTheCage55 great explanation, thanks!
is vapor mode work with option API ?
Nope.
And soon we are close the circle and return from vDom (stupid) idea to local DOM templates. At rising of AJAX technology, we are already having small libraries for this task to use addressed templates at html source, but who care - use Backbone, use Angular, use React instead - its looks like solid solutions, like other boilerplates in Java. So, in my (wrong) opinion Java devs do all of this mess. Perfectly designed totally unnecessary overengineered mess.
加点中文字幕
dude, you have good content, quit with these corny ass preview images
That’s what TH-camrs have to do to stand out unfortunately. I’m sure he hates making them
Haha ! It works though lol
Erik's kids gotta eat man
I've been subscriber for couple of years. Unsubbed bc cannot look at this preview images anymore, just can't... Looking for some quality content, not teenage dramas content.
@@radekmvm lol they’re cheesy for sure but it ain’t that serious that I would unsub. He’s got great content. I just hate that he has to resort to this kind of stuff, it feels so demeaning