Make writing a habit together! This is the 13th day of my participation in the “Gold Digging Day New Plan · April More Text Challenge”. Click here for more details.

Type: comprehensive question, open question

⭐ ⭐

A:

Working with native JS performs better for the following reasons:

Because it’s a step further from manipulating native JS, the virtual DOM needs to find the difference before and after the page has been updated, and it still needs to manipulate native JS when the page has been modified.

Suppose the performance cost of modifying page elements is defined as A, and the performance cost of finding differences in page elements is defined as B

  • The performance cost of manipulating the virtual DOM is A + B
  • Modifying page elements directly has A performance cost of A

A + B > A, obviously using native JS is better than the virtual DOM.

Consider an example of a div whose text is ‘hello’ :

<div id='app'>hello</div>
Copy the code

Now you need to change the text content of the div to ‘hello1’, which you can do with native JS.

const div = document.getElementById('app')
div.textContent = 'hello1'
Copy the code

Is there a better way to do this than with the code above? The answer is, no, and that’s the simplest, best-performing way to do it.

If I use Vue to implement this function:

<template>
  <div> hello </div>
</template>Instead of<template>
  <div> hello1 </div>
</template>
Copy the code

What looks like a one-character difference is actually doing a lot of things inside Vue, such as parsing template strings, creating a virtual DOM, comparing with diff algorithms, and so on, which is a performance loss.

So why do people say that virtual DOM performance is better than native JS?

That’s because when many people refer to manipulating the DOM with native JS, they mean using native JS incorrectly, such as:

  • Update only a few elements, but destroy all the old nodes and create all the new ones.
  • Replace the node with innerHTML.

Remember this conclusion: it’s not that native JS is bad, it’s that native JS is the best, it’s that native JS is not performing well.

Using innerHTML as an example, let’s take a closer look at why using the virtual DOM performs better than using poorly manipulated native JS.

<ul id="list"></ul>
Copy the code
const htmlStr = ` 
  • item1
    •  
  • item2
    •  
  • item3
    •  
  • item4
    •  `    

const ul = document.getElementById('list')
ul.innerHTML = htmlStr
Copy the code

    As shown in the code above, the element is created by assigning an HTML string to it.

    Because the innerHTML can only be reset with an assignment, if you need to change an element, such as changing item1 above to Item11, or even just one character, you need to destroy all the old DOM elements and create a new DOM element entirely.

    Here is a concept to understand: the computation performance of the JS layer is much better than that of the DOM layer. The test code and results are as follows:

    console.time('js')
const arr = []
for(let i = 0; i < 100000; i++) {
  const div = {
    tag: 'div'
  }
  arr.push(div)
}
console.timeEnd('js')

console.time('dom')
const element = document.getElementById('element')
for(let i = 0; i < 100000; i++) {
  const div = document.createElement('div')
  element.appendChild(div)
}
console.timeEnd('dom')
Copy the code

    With that in mind, we use a table to compare the performance of the virtual DOM and innerHTML when updated:

    Virtual DOM innerHTML
    Pure JS operation Create a new VNode object + diff Render HTML Strings
    DOM operation Update the DOM with changes Destroy all the old DOM and create all the new DOM elements
    Performance factors It’s related to the amount of change in data Is related to the template size

    Using the virtual DOM, there will be a performance loss of diff algorithm at the JS level. However, it is only JS level calculation after all, and will not take too much time.

    At the DOM level, however, the virtual DOM only updates the changed DOM, whereas the innerHTML needs to be fully updated, and the performance benefits of the virtual DOM come into play.

    And with the virtual DOM, no matter how big the page is, only the changed content is updated, whereas with innerHTML, the larger the page, the greater the performance cost.

    As a result, the performance of a poorly handled native JS is much lower than that of a virtual DOM.

    At the end

    To sum up, using the virtual DOM is far superior to using native JS in terms of maintainability and mental burden, and far superior to poorly handled native JS in terms of performance.

    Alin level is limited, the article if there are mistakes or improper expression of the place, very welcome to point out in the comment area, thanks ~

    If my article is helpful to you, your 👍 is my biggest support ^_^

    You can also follow the front End Daily Question column in case you lose contact

    I’m Allyn, export insight technology, goodbye!

    This article refers to: vue.js design and implementation

    The last:

    Front End Daily Question (49) what are imperative and declarative frameworks?