DEV Community

Vani Shivanand
Vani Shivanand

Posted on • Updated on

Svelte Needs A Virtual DOM

For decades, we were working without a Virtual DOM and it was accepted widely in the last decade soon after it was introduced mainly because the benefits were seen. If we think that it is not needed, we need to do a lot more performance tests before we decide. Before the performance tests, here is an attempt to understand it through the basics.

Let's consider the code,
let number = 1;
number++;
number=+2;
number=+3;

*This is only for the simplified illustration purpose. Please not to consider it as continued four updates. It intends to say four random DOM updates

And HTML(or html alternative) being
<div>{number}</div>

The javascript engine & the browser engine communicate with each other four times as we are updating the number four times. This is in the case of Angularjs & Svelte.

But in the case of Reactjs or Vuejs or any framework with Virtual DOM, the javascript engine & the browser engine communicates only once(which means only one DOM update) and the Virtual DOM is altered four times.

Coming to the user experience, Rich Harris in his video "Rethinking reactivity" shows a text input and demonstrates user typing experience in an input field. It looks great as there is no lag in Svelte. It's mostly perceived performance is spoken about but not real performance. Not exactly like chrome but it can be somewhere compared to chrome which uses most of the resources to perform better.

In Angularjs & Svelte we need to optimize the above code again as below,

let displayNumber = number

And HTML part as,

<div>{displayNumber}</div>

After this optimization, Angularjs & Svelte also have communication between two engines only once. Because every time the variable that's bound to the output is changed, both the engines need to communicate. When we change the bound variable only once as in displayNumber, we have fixed the problem.

Well, we can't have lint rules to watch this. So, this will be difficult to maintain without Virtual DOM.

Back to the user experience as shown in Rich Harris video, while typing letters, the engines communicate on every keystroke without Virtual DOM. But he is right that the user needs to feel that smooth feel of GUI update. The frustration meter metrics should be considered.

The solution may be, the Virtual DOM frameworks should provide an optional entity to update a particular DOM element if anyone wishes to force-update the DOM directly for the chosen blocks. This way is a lot better than not using Virtual DOM at all.

For the point "DOM is not slow", it is not just DOM but it is also about CSSOM which runs after every DOM update. In the case of Virtual DOM, CSSOM never runs unless the DOM is updated.

In the end, it is nothing against Svelte or Angularjs. They are great frameworks with unique features. For lightweight products, one may use them but there is a need to re-think how the product is going to grow before we decide to choose.

What I don't agree with him is when he said, "The only way to speed up your code is to get rid of it". There are obviously a lot many ways to speed up our code and that's why we are observing and working consistently.
Alt Text

Also, please refer to the post that explains Virtual DOM with a very simple example Virtual DOM - A Simplified Example

And I plan to make the next post with performance screenshots with different code blocks on both the ways.

A comment on the above reading would be a lot helpful for me to improve my writings further. Thanks for the time!

Top comments (24)

Collapse
 
khrome83 profile image
Zane Milakovic

I feel like you are looking at this wrong...

There are two things that matter.

  1. Bundle Size
  2. Performance that is realistic to your app

We say everything needs a virtual dom, then we build a website with React that does not need reactivity. Looking at almost every marketing site ever.

So I choose svelte because of the lower bundle size.

Then we say it performs better, the virtual dom. Well, most performance tests I have seen show the opposite. That svelte out performs virtual dom libraries.

For this argument I look too scale. The stress cases have thousands and thousands of things being updated. My web app does not, so this does not seem to matter much.

So once again, back to bundle size, and I choose svelte.

I appreciate the technical argument and the debate. But we all seem to forget that most of the web is Wordpress and jQuery still. That vanilla HTML, CSS and JS solve most of our issues and we are debating developer experience not user experience.

Start with the user experience, you won’t go wrong. But don’t claim performance issues without a actual user context and impact. And don’t sacrifice bundle size for a few extra frames a user can’t decern because you think it’s neat, or want to defend your technology choices.

Collapse
 
svaani profile image
Vani Shivanand • Edited

Svelte performs a lot better when the app is small. Imagine a live updating website or Facebook being developed in svelte.

Bundle size does matter but as the application grows, all the functionalities in it are a need.

Collapse
 
khrome83 profile image
Zane Milakovic

Where do you see proof that svelte can’t handle something like Facebook. That is just assumptions. Facebook was built without a virtual dom long before it had one.

And the difference is the size the JavaScript is to perform the same actions for the user. You can’t claim that it’s ok to have a larger bundle size and it’s justified because of react because of functionality svelte or even just HTML, css, and JS can’t do. React isn’t magic.

Also, once again most websites are not the size of Facebook. So it’s about your needs.

I would also argue it’s about how the developers work offline, the component architecture, that makes these frameworks valuable. Not the user experience. Nothing a SPA, svelte or react, does is something a standard site can’t do from a users point of view.

Collapse
 
ryansolid profile image
Ryan Carniato

You are talking about a batching mechanism that has nothing to do with the virtual DOM. Like look at MobX which uses the concept of actions to batch changes. The only reason the Virtual DOM doesn't update in this case is default behavior is to batch. But if you wanted it to change independently you could. And with most reactive libraries (I can't speak for Svelte) you can batch changes. Has nothing to do with the Virtual DOM. Virtual DOM can be very fast so I don't want people to buy into the Svelte hype. There are way faster VDOM libraries than Svelte. There are compiled reactive libraries way faster than those too. But React isn't even close.

Don't confuse batching with the Virtual DOM.

Collapse
 
svaani profile image
Vani Shivanand • Edited

Thanks for the comment.

I didn't mean one line update in the latter example. It's supposed to be this

let number = 1;
number++;
number=+2;
number=+3;
let displayNumber = number

So, the empty comparison doesn't hold good.

Trying new ways to speed up is good. Svelte is an awesome framework. But react is a lot mature and handles more scenarios to optimize performance.

I could see layout taking a lot more time in Svelte which is also a major concern.

I will also make more study on the same and update the same on data basis next time.

Collapse
 
khrome83 profile image
Zane Milakovic • Edited

React does not handle more scenarios.

React exposes more hooks or states so you can inform it how to be more performant.

ShouldComponentUpdate, ShouldComponentMount, or what have you. It’s been a while.

The reality is, you should not need those, if it was not for a systemic performance issue. Look at 2016 articles of optimizing React before react 16. Sure it got better since, but so has our devices, internet and browsers.

Run that code in a nexus 5 with a 3G connection in Puerto Rico inside a Facebook webview.

Thread Thread
 
svaani profile image
Vani Shivanand

Sorry to differ it does handle more scenarios. One of them is, it compares the dom and then updates. A read is much faster than the write as write has to alter the entire dom tree.

Thread Thread
 
khrome83 profile image
Zane Milakovic

Your missing my point.

It does not matter the library does more work. What matters is the speed for the user. It’s great they do that. But you are downloading a much larger bundle size to get that benefit. And in 95 percent of SPA sites, it’s not needed.

When we talk about performance, we have a habit of saying “this is faster” or “this updates more elements” or “it’s smarter about how it does it”.

The reality is, touching the DOM is not bad. And in most cases the added benefit of a virtual DOM is not felt. And Svelte performance actually shows its faster without the virtual DOM than react is with it.

This will keep going back and forth as both libraries keep optimizing. The big thing here, is to understand that a virtual dom is not a requirement for a fast experience. And the cost of it, is a larger bundle size.

When you remove the developer experience, and your look at the performance realistically (perception and what is needed) your left with bundle size. And react can’t touch svelte on that.

Thread Thread
 
svaani profile image
Vani Shivanand

The whole point is updating the Dom is 100% slower. Please have a look at the results here, dev.to/svaani/is-virtual-dom-neede...

Thread Thread
 
khrome83 profile image
Zane Milakovic

Ok at this point your not really reading or consuming other viewpoints.

Tests I have seen that are not yours have shown otherwise, but please read everything else I said about performance.

Thread Thread
 
svaani profile image
Vani Shivanand • Edited

I would also say the same, you are not reading all the points that I say.

Yes svelte is a lot better for not complex apps.

If you say 95% of the websites don't need that, we must see most percent of websites are wordpress without a thought on optimization.

Anyway, please have a look at this.

dev.to/svaani/svelte-vs-reactjs-pe...

Thread Thread
 
nordquist profile image
Marcus Nordquist

Look, what you are doing in your comparison here; dev.to/svaani/is-virtual-dom-neede..., is just bad practice - it is really not even related to Svelte. You are comparing apples and oranges and like someone else already stated, you can do batch updates to the DOM with Svelte without having it continuously update on every fired event.

I have rebuilt complex UIs from React to Svelte that way outperforms the previous version in React, but you need to have a good understanding of what you are doing and how you structure your code.

Also, note that Svelte compiles on component level, not holistically, which means that you do not or should not build your complex UI the same way you would with React.

Collapse
 
thgh profile image
Thomas Ghysels

Hi Vani, Svelte will check what changed in the next microtask and only then apply DOM updates. So Svelte will update the DOM just once, not four times. You could look at the generated code on svelte.dev/repl

Collapse
 
svaani profile image
Vani Shivanand • Edited

Yes, but the four times is used for the simplified explanation. It's about updating large chunks of data. May be I was not very clear in my explaination. I shall re-quote it with better examples or better words.

Collapse
 
bernhardwebstudio profile image
Bernhard Webstudio

I am really curious to see actual data, because the arguments you list here seem wrong (svelte does not update 4 times either, as I see it) or do not convince me. In contrast, I perceive the virtual DOM for most tasks an unnecessary overhead. Only the really big/intensive applications like Fakebook, where you have hundrets of scripts all loading and modifying the DOM simultaneously seem like a valid use case to me.

Collapse
 
svaani profile image
Vani Shivanand

Yes, it was for the simplified illustration. May be, I wasn't clear in my words. I meant to say if "four changes" happen. I will upload the reports for the actual data.

Collapse
 
atlemagnussen profile image
Atle Magnussen

virtual dom diffing gets more and more slow as your application grows, for some scenarios it's too big a price to pay.

I'd rather say the React needs an alternative to the virtual dom to stay relevant.

Collapse
 
andrewtrefethen profile image
AndrewTrefethen

Both Svelte and React end up making the exact same number of changes to the DOM. Even for large data changes. The only difference is that react reconciles the changes by using the virtual DOM first. Svelte updates the DOM based on what was changed usinh the compile time knowledge of how to make said change. The only place react might be faster is adding a huge number of nodes in a very short time as it could decide to use something like innerHTML to get all the elements on screen and then hydrate them next tick. If you're adding 50+ nodes in a single cycle on a regular basis, then you probably have a problem. Even Facebook doesn't update that many things at once, why? Because it's bad practice and you should be focused on reacting to user interactions.

Collapse
 
shershen08 profile image
Mikhail Kuznetcov

Angularjs is still big due to all the legacy's apps. In 2020 I would not use it as a comparison

Collapse
 
juancarlospaco profile image
Juan Carlos

Svelte with VirtualDOM = Nim

Collapse
 
thepeoplesbourgeois profile image
Josh

Svelte is a statically-typed systems programming language? O_o

Collapse
 
juancarlospaco profile image
Juan Carlos
Collapse
 
starryfire profile image
Kartik Sharma • Edited

Hi any updates on the real data showing the performance comparisons between react and svelt? @svaani

Collapse
 
svaani profile image
Vani Shivanand

Yes that's right. But I am speaking about large chunks of data. Here it was only for the simplified example, I used four times update.