👋 Hey there! Welcome to the exciting world of web development! Today, we're going to explore a fascinating concept that is revolutionizing the way ...
For further actions, you may consider blocking this person and/or reporting abuse
Can you help me understand something in this? I can't quite envisage a scenario where in Svelte the same property of a DOM object is changed more than once as a result of some atomic operation - i.e. during the same event. As I can't think what this would be, my initial reaction is that a VDOM is going to be a big overhead. If I update the VDOM it still has to be synched to the DOM, so the DOM write is going to happen anyway.
Can you give me an example of where you would be updating the same DOM property multiple times? I guess if it was stopping a case where the same value was being written back then I'd understand it, but I don't think that's a common case.
Hello, thank you for your comment. I’m happy you are interested in Svelte and how it compares to other frameworks. Svelte does not use a VDOM because it creates JavaScript code that directly updates the DOM. This way, it ensures that only the necessary updates are made and nothing more. A scenario where a VDOM would prevent multiple updates to the same property is when you have a list of items that can be sorted or filtered by different criteria. In that case, a VDOM would enable you to update the order or visibility of the items in the VDOM first, and then apply the changes to the DOM in one go. Another example is when you have a complex UI with many nested components that depend on each other’s state. If you use a VDOM, you can update the state of one component and let the VDOM handle the propagation of the changes to the other components. This way, you avoid manually updating each component and triggering multiple reflows and repaints in the browser. I hope this explains your question 😊
Thanks, I've multiple projects live using Svelte, Vue and React so I understand both the reactive vaniallaJS and the VDOM models. I'm still struggling a little with your example, in Svelte if I had a list then I could key that list, it would still only write to the DOM elements that changed, and it would only write the changed properties, append or remove from the list etc. I'm not getting how a VDOM is anything except overhead, sure you'd change those properties on something that didn't cause a reflow, but then synchronisation would cause a reflow. Are you suggesting that Svelte changing 4 properties as part of an atomic interaction would cause more reflows than the VDOM sync? That wasn't my understanding.
Actually in svelte reactivity on Arrays and Objects are bit different. The DOM updates are triggered on the basis of variable assignment not by the individual mutations. For example, I have a list of students in a class with their scores. I store the data as array and iterate through that data and display the UI in svelte. after rendering to the DOM if I add(push) some other student it won't update the DOM reactively. If you want to achieve reactivity then you have to reassign that array with this newly updated one which results in the unnecessary re-rendering of the entire list. This won't be much for a list of 50 students or something. But definitely a worst-case if we have hundreds and thousands of students. But if the same thing is done with VDOM. we will update the entire list of students in the VDOM first, then with the help of DOM-Diffing we will only update the minimal possible DOM mutations to apply the change.
@efpage This would be a convincing example.
Reference: learn.svelte.dev/tutorial/updating...
Are you sure, what about this: svelte.dev/tutorial/keyed-each-blocks? I believe it's being smart enough here not to regenerate the entire list, but to only affect the elements.
To test this I used the example above and modified the code so it uses thing.id as a key. I then used Dev tools to set a random property on the last dom element (in my case I set a property called
testingto be equal tobanana. I then clicked the button to remove the first element, regenerating the list, and confirmed that my property still existed, demonstrating that Svelte is not regenerating the entire DOM.Your point it correct. we can use keyed each block for these kind of issues. I tested this method but the problem with this way is if we have multiple mutations in a single list there is a high chance for key collisions. When i was trying with the REPL it throw errors. in that case I think VDOM does better job than svelte. That is because of the maturity of VDOM libraries is much more vast than svelte at this point
I don't follow you here, do you mind sharing your REPL example?
If keyed each can't handle multiple mutation then it's a bug that should be fixed.
The VDom was created to make life simpler. You just describe the new state of te UI and the VDom manages the state changes. Managing state transitions may be challenging, especially for larger apps tha are created by big teams.
But this does not mean, a VDom is faster. Dom-diffing may take a lot of ressources, and you need to build you UI in a way, that each element can be identified. Otherwise the VDom does not know, if an element was changed or not.
Svelte uses a compiler to implement the routines that manage the state changes. So you get the same comfort with less tradeoff. Implementing a VDom for Svelte is like you have a sportscar and want to have the option to pull it with a horse...
Thank you for your comment. I agree that the VDOM has some drawbacks and that Svelte has some advantages over it. However, I think that the VDOM is more compatible with other libraries and frameworks. For example, if we have DOM diffing we can easily and efficiently achieve SPA Page(View) transitions like
Could you please share your thoughts on these aspects?
We schould first talk about the task to solve. Should we stop riding bikes because cars are faster?
Yeah. I am agreeing with you. This is only optimal for very rare and specific use cases. Thats why this post is on optional VDOM, not disturbing the actual svelte mottos, but enables developers to enjoy the features of VDOM as well.
Definitely we can't stop using 2-wheelers or 4-wheelers for each others best. But in this world they co-exists and even there are some 3-wheelers too.
According to svelte.dev, Objects and Arrays will trigger reactivity only if reassignment rather than mutations happen on them.
Say we are building Twitter, we will have all of our tweets as an array of tweets where each of the tweets will be an object having data like content, impressions_count , likes_count, retweet_count, comments_count, author, id. Among those data, impressions_count, retweet_count, likes_count and comments_count are changing in realtime. Since they are stored as an object and the changes are received as objects only, consider what happens after initial rendering. We have to update the likes_count. Since we cant update the like count alone, we have to re-render the entire tweets as the tweet object is within the array. This makes svelte more inefficient even though it is more performant and capable. If we use VDOM within svelte, its too obvious that even if we re-render everything in VDOM (more cheaper operation) in the actual DOM only the likes_count of that particular tweet will be changed. Yeah, same can be achieved in svelte too but we have to use more complex approach on state management and our implementation.
I hope this would help and makes things more clear.
@miketalbot This example will also suits well
If you read the post from Rich-Harris: The truth about Svelte, incrementally adopting Svelte into your existing ecosystem should be possible. I´m not sure about React, but in theory, adopting VUE incrementally should be possible also. Running both in the same application should be possible. So, if your target is to use existing libraries, this should be possible too.
If your target ist do do more efficient state managent, then maybe you should try this on a higher level to prevent unnecessary rerendering. The browser can easily handle a single element update, so your task is siply to prevent your app from doing unneceesary things on the DOM.
Yes, We can use many frontend frameworks and libraries in a same app. we have astro and incase of react and svelte we have github.com/Rich-Harris/react-svelte But the concern with this approach is that if we have to tangle between each of their concepts. like we have concepts like composition in vue which doesn't in svelte or react. this might increase the developer complexity.
Thats the problem if it is baked into the svelte itself then we can make use of svelte's conciseness without many tradeoffs. Again, this is just an imagination not an actual proposal for svelte's proposal.
You are not re-rendering the entire array, the equal sign is needed to trigger reactivity because the compiler looks for equal signs but that doesn’t mean a new array is created
Yeah you were correct but in few edge cases we use keyed each statements, which is not effective enough to handle key collisions in case of heavy mutations on arrays and objects.