Original talk "Seeking the Balance in Framework Design" by Evan You creator of Vue.js at JSConf.Asia 2019 in Singapore. Find it at • Evan You on Vue.js: Se...
@@starscream320 Svelte takes this idea and runs with it. Svelte does no diffing and instead overloads the semantics of the assignment operator to detect reassignments and re-render only affected elements. This also allows it to ship much less js, making sites lighter and faster to process.
Vue already performs better than React in all cases and Svelte in some cases, just with VDOM optimizations. But later this year (2023) Vue will soon have a compiler too, just as Svelte’s called Vapor Mode. Dropping the VDOM completely and having a performance similar to that of SolidJS
Haven’t seen the whole video, but this is a very contrived example. In the real world, the component tree would be filled with hundreds of dynamic elements.
It is the exact same. He’s using the same markup as an example to distinguish how the vdom diffing algo needs to go through each tag compared to vue templates
No, you can't, as this will be yet another library. Vue does a lot more, starting from SSR and all the way to very cool features that make you productive. Don't focus on runtime
Templating doesn't inherently support reactivity, although you can always add the effect of reactivity with just js. The frameworks add the semantic layer that makes it easy and scalable.
@@chaost11 the problem comes from making large, complex websites. Its unfortunate, but this kind of problem is a bandage for shit design, shit UX and/or feature creep gone too far. And the problem usually just does not start in the frontend, but from the data side altogether. In all my time working across the stack in a variety of companies, the ones that actually spend time designing and thinking end up making simple websites. Then your users will actually maybe use the thing.
Sorry guys, but I’m new to programming and starting to grasp the idea of code structures and it’s expectations. Do you guys feel that following simple code rules are a good way to exercise algorithm implementation, or should I go into this understanding with a bit more of a challenging approach? I ask this because I sometimes am quick to refer to documentation rather than pushing my own ideals into a program and “seeing what happens” kind of behavior. I honestly find it good to take either route but with all the tools in the world, it’s easy to make an approach. But with the reality of time and limitations towards learning, I feel It’s risky to make wrong turns and take up too much time going in the wrong direction, so that’s something I feel I wanted clarification on.
It would also not be a proper comparison though a proper comparison would be to write the same large app considering : - how much you understand the framework's internal stuff, - how much you optimises it, - within a limited timespan, - with one or many teams - with automated tests - the efficiency of each developer to release features - ... so you just keep some small comparisons like this because the "true" comparison would be impossible
@@Apeuda From my experience, you should only use a class name when there are going to be multiple elements which rely on the same underying layout. Edit: Not for every single element throughout the entire application.
Vue (budget react) monkey patching in features already invented by other libraries. If you want performance use solid or qwik. If you want full vdom capabilities use react. End of story
@@icarusgk the guy in the video is talking about compiler understanding your coding intentions -_- how is it hard to understand that compilers just convert your code into bytecode (and check if the code even builds first). They don't understand your 'intentions'.
His point is that if you have no constraints you need to constantly work with and traverse the entire DOM which quickly becomes slow and expensive, whereas a limited template makes the necessary DOM actions predictable and lets you avoid a lot of of unnecessary checks/traversals.
@@rosux5540 Yes exactly. What it improves (i.e. where you gain speed) is essentially that it has "pre-calculated" a lot of DOM paths and element locations (but not just that) meaning it can better manipulate the DOM via the browser api without running costly functions like querySelectorAll()/getElementById()/etc. (There's a bit more to it, but basically that's the gist of it.)
Unless it's not able to because of its constraints? What was the point of this comment after again? Pretty sure that guy explained it pretty clearly, I'm not that smart and even I understood it
There's no code that runs faster than that which doesn't even exist. Virtual DOM can only play catch up to pre optimized, and therefore pre pruned code.
Just one short to distinguish between React and Vue :o
@@darthvader4899 can you elaborate more on svelte in contrast to react or vue or both?
@@starscream320 svelte is already a compiler which compiles your .svelte files into vanilla javascript
@@starscream320 Svelte takes this idea and runs with it. Svelte does no diffing and instead overloads the semantics of the assignment operator to detect reassignments and re-render only affected elements. This also allows it to ship much less js, making sites lighter and faster to process.
react do same using keys
Or react and sycamore
So next version of Vue will do direct dom update like Svelte?
There is a proposal for vapour mode
they say that they will take the solidjs approch of doing things
Very difficult to debug a vite/vue /typescript program in the browser. Source maps are not accurate.
Somebody stopped generating his sourcemaps
Just use vue cdn, no need compile and sourcemaps bullshit. If you cant use js framework via cdn, it's trash.
Vue already performs better than React in all cases and Svelte in some cases, just with VDOM optimizations.
But later this year (2023) Vue will soon have a compiler too, just as Svelte’s called Vapor Mode.
Dropping the VDOM completely and having a performance similar to that of SolidJS
Vue has a compiler :)
@@phoenix-tt yup, I meant a compiler as in vDOM less compiler hehe
Haven’t seen the whole video, but this is a very contrived example. In the real world, the component tree would be filled with hundreds of dynamic elements.
Svelte, solidjs Qwik : 🤓
Latest benchmarks show Vue3 as faster by a margin than svelte in total.
all of these have basically no ecosystem
Is it just me, or the code at the beginning and at the end is exactly fooking same?
It is the exact same. He’s using the same markup as an example to distinguish how the vdom diffing algo needs to go through each tag compared to vue templates
@@shivanshsharma7422 maybe I'm just stupid or this explanation is misleading.
@@anj000 i think itd be better to watch the whole talk where it has his explanation on how vue tracks updates or whatever. Anyways, svelte ftw!
would the static way to do this result in an instruction that uses a simple xpath?
or you add an unique key to each p tag.
unique key can just speed up the process of diff at the same level, Block tree can hoist all VDoms :)
Evan es mi pastor
I prefer raw WASM just to flex
Isn't this how other programming language like Python (Jinja, Mako, DTL), PHP, Ruby on Rails, Go, Rust have been?
what is original video of this shorts?
in short, vue using virtual DOM
*coughs in svelte*
*coughs in Vapor mode*
Vapor mode wil change everything in terms of speed etc
Coughs in knockout
Good luck in finding svelte job
@@yourivanmill Will it change the speed in which Nuxt3 released?
Svelte is pioneer of this
Pioneer of something vue has been doing since 2015?
Svelte released November 2016, Vue released February 2014. Unless Svelte also pioneered time travel your comment is a lie.
Knockout did it first my friend lol, just not with a compiler.
Or you can just build a simpler framework that uses just javascript as templating language and let the browser do the optimization for you 🤷♀️
No, you can't, as this will be yet another library. Vue does a lot more, starting from SSR and all the way to very cool features that make you productive.
Don't focus on runtime
Vue/nuxt just does everything slightly worse and uglier than react/next
@@und0 and they do it bad already
Can i get a full video
Sure here you have 📼
@@angelsv he wants to study. Give him a link
@@nonicknameee Nah mate, user username checks out.
@@nonicknameee he's lazy , why u care 🤣
Original Video:
ruclips.net/video/ANtSWq-zI0s/видео.html&ab_channel=JSConf
Why does he say recursively? Isn’t it iteratively that you progress through the DOM?
The algorithm to traverse a tree with nodes can be recursive.
Why not just add an id? Maybe I'm not getting what he is saying.
So basically what is Svelte is doing from the start
Svelte appeared after Vue so I don't get your point here. It sounds as if you want to say that Svelte invented that before Vue did which is not true
@@DarkzarichV2 Svelte is doing that beofre Vue implements it. VueJs version 1 and 2 doesnt have that. What are you saying that VueJS invented that.
@@Gol_D_Roger_The_Pirate_Kingand solid implemented it before svelte, and knockout before solid…
Pair that with Inertia and Laravel and you gonna be a happy developer.
What about AOT, cd already knows where is the exact location to change it right?
Or you can just use EHTML and map your data on template
Someone simplify this for me please
Svelte: 👀
let's go
solidjs
@@arson5304 this
Vue already performs better than Svelte in some cases just with VDOM optimizations like this one
Vue is the king ! Evan is the techlead!
Why does it feel like we haven’t really done better than php
Isn’t this basically also how MillionJS works?
My computer has a conscious. Dun dun dunnnn
Nuxt 3 is great
🚀
so many classes
I think you meant iterative not recursion.
Angular ❤
I'm feeling stupid but I don't see the difference between the two code fragments lol
He is just explaining how the compiler driven development will give more performance than by implementing vdom.
perf wise vue is most likely quicker but I hate the DX and prefer react personally
Nextjs
That's why Svelte doesn't use vdom lol
P class NP complete process point.
didn't make sense to me.
Yall ever heard about old school template? Like the ones we used to write in php? 🤔
Templating doesn't inherently support reactivity, although you can always add the effect of reactivity with just js. The frameworks add the semantic layer that makes it easy and scalable.
@@ccgarciab its the reason why the internet is a sucky experience
Still just talk and no walk
Maybe dont use node
Key
Isn't it just creating a hash table of the "virtual dom" to have instant lookup and replace?
It’s not
@@azizsafudin sad
it looks like boiler plate to me but i am not a web dev
Template
It's obvious to me
imagine obsessing over these nonproblems.
What??? That's a big, big problem for large, complex websites
This is the problem in the web. Our hardware is insane nowadays but somehow the web is always as slow and bloated...
@@chaost11 the problem comes from making large, complex websites. Its unfortunate, but this kind of problem is a bandage for shit design, shit UX and/or feature creep gone too far. And the problem usually just does not start in the frontend, but from the data side altogether.
In all my time working across the stack in a variety of companies, the ones that actually spend time designing and thinking end up making simple websites. Then your users will actually maybe use the thing.
Sorry guys, but I’m new to programming and starting to grasp the idea of code structures and it’s expectations. Do you guys feel that following simple code rules are a good way to exercise algorithm implementation, or should I go into this understanding with a bit more of a challenging approach? I ask this because I sometimes am quick to refer to documentation rather than pushing my own ideals into a program and “seeing what happens” kind of behavior. I honestly find it good to take either route but with all the tools in the world, it’s easy to make an approach. But with the reality of time and limitations towards learning, I feel It’s risky to make wrong turns and take up too much time going in the wrong direction, so that’s something I feel I wanted clarification on.
*Promo sm*
frontend problems:
Write an entire application to find out which is better. This is not a proper comparison.
It would also not be a proper comparison though
a proper comparison would be to write the same large app considering :
- how much you understand the framework's internal stuff,
- how much you optimises it,
- within a limited timespan,
- with one or many teams
- with automated tests
- the efficiency of each developer to release features
- ...
so you just keep some small comparisons like this because the "true" comparison would be impossible
React: why don't you provide me keys and I will optimise this for you.. 😊
The best solution would be to throw out JS and replace it with a programming language.
Or don't write JavaScript and avoid all JavaScript problems :)
Solution for people who use the same class name for every element, lmao.
0/10
but you're supposed to use a class name on multiple elements
@@Apeuda From my experience, you should only use a class name when there are going to be multiple elements which rely on the same underying layout.
Edit: Not for every single element throughout the entire application.
Vue (budget react) monkey patching in features already invented by other libraries. If you want performance use solid or qwik. If you want full vdom capabilities use react. End of story
brother whats your beef with vue lol
Angular is better
This genius is comparing a compiler to an AGI and talking about intentions
WHAT??
@@icarusgk what do you mean what? It's not hard to understand what I wrote.
@@SahilP2648 In what point what AI mentioned in the vid? I don't get the AGI point
@@icarusgk the guy in the video is talking about compiler understanding your coding intentions -_- how is it hard to understand that compilers just convert your code into bytecode (and check if the code even builds first). They don't understand your 'intentions'.
@@SahilP2648 You're taking what Evan You said too literal
Isn't this just the concept of a pure component?
doesnt it all just use the browser dom api?
His point is that if you have no constraints you need to constantly work with and traverse the entire DOM which quickly becomes slow and expensive, whereas a limited template makes the necessary DOM actions predictable and lets you avoid a lot of of unnecessary checks/traversals.
@@CurseTheVulgar so its a sort of api between the virtual dom and real dom? and using the "api" thing is faster?
@@rosux5540 Yes exactly. What it improves (i.e. where you gain speed) is essentially that it has "pre-calculated" a lot of DOM paths and element locations (but not just that) meaning it can better manipulate the DOM via the browser api without running costly functions like querySelectorAll()/getElementById()/etc. (There's a bit more to it, but basically that's the gist of it.)
💩ing on the virtual dom is only effective until the virtual dom makes a similar optimization.
Unless it's not able to because of its constraints?
What was the point of this comment after again?
Pretty sure that guy explained it pretty clearly, I'm not that smart and even I understood it
There's no code that runs faster than that which doesn't even exist. Virtual DOM can only play catch up to pre optimized, and therefore pre pruned code.