Svelte Needs A Virtual DOM
Tags: react, svelte, vue, javascript
Published: 2020-01-09 11:49:27

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](https://thepracticaldev.s3.amazonaws.com/i/dibzh2xoovkn4619kx4e.png)

Also, please refer to the post that explains Virtual DOM with a very simple example [Virtual DOM - A Simplified Example](https://dev.to/svaani/is-virtual-dom-needed-1lo7)

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!*