本文翻译自：Why is React's concept of Virtual DOM said to be more performant than dirty model checking?

I saw a React dev talk at ( Pete Hunt: React: Rethinking best practices -- JSConf EU 2013 ) and the speaker mentioned that dirty-checking of the model can be slow. 我在（ Pete Hunt：React：重新思考最佳实践 - JSConf EU 2013 ）中看到了React dev的演讲，并且发言人提到模型的脏检查可能很慢。 But isn't calculating the diff between virtual DOMs actually even less performant since the virtual DOM, in most of the cases, should be bigger than model? 但是，由于虚拟DOM在大多数情况下应该比模型更大，所以虚拟DOM之间的差异实际上并不是很差。

I really like the potential power of the Virtual DOM (especially server-side rendering) but I would like to know all the pros and cons. 我非常喜欢Virtual DOM的潜在力量（特别是服务器端渲染），但我想知道所有的优点和缺点。

---

#1楼

参考：https://stackoom.com/question/1QZVZ/为什么React的Virtual-DOM概念被认为比脏模型检查更具性能

---

#2楼

I recently read a detailed article about React's diff algorithm here: http://calendar.perfplanet.com/2013/diff/ . 我最近在这里阅读了一篇关于React的diff算法的详细文章： http ： //calendar.perfplanet.com/2013/diff/ 。 From what I understand, what makes React fast is: 根据我的理解，React的快速之处在于：

• Batched DOM read/write operations. 批量DOM读/写操作。
• Efficient update of sub-tree only. 仅有效地更新子树。

Compared to dirty-check, the key differences IMO are: 与脏检查相比，IMO的主要区别是：

1. Model dirty-checking : React component is explicitly set as dirty whenever setState is called, so there's no comparison (of the data) needed here. 模型脏检查 ：每当调用setState时，React组件都显式设置为脏，因此这里不需要比较（数据）。 For dirty-checking, the comparison (of the models) always happen each digest loop. 对于脏检查，（每个模型）的比较总是发生在每个摘要循环中。

2. DOM updating : DOM operations are very expensive because modifying the DOM will also apply and calculate CSS styles, layouts. DOM更新 ：DOM操作非常昂贵，因为修改DOM也会应用和计算CSS样式，布局。 The saved time from unnecessary DOM modification can be longer than the time spent diffing the virtual DOM. 从不必要的DOM修改中节省的时间可能比传播虚拟DOM所花费的时间长。

The second point is even more important for non-trivial models such as one with huge amount of fields or large list. 第二点对于非平凡模型更为重要，例如具有大量字段或大型列表的模型。 One field change of complex model will result in only the operations needed for DOM elements involving that field, instead of the whole view/template. 复杂模型的一个字段更改将仅导致涉及该字段的DOM元素所需的操作，而不是整个视图/模板。

---

#3楼

Here's a comment by React team member Sebastian Markbåge which sheds some light: 以下是React团队成员SebastianMarkbåge的评论，其中有一些说明：

React does the diffing on the output (which is a known serializable format, DOM attributes). React对输出进行区分（这是一种已知的可序列化格式，DOM属性）。 This means that the source data can be of any format. 这意味着源数据可以是任何格式。 It can be immutable data structures and state inside of closures. 它可以是不可变的数据结构和闭包内的状态。

The Angular model doesn't preserve referential transparency and therefore is inherently mutable. Angular模型不保留引用透明性，因此本质上是可变的。 You mutate the existing model to track changes. 您改变现有模型以跟踪更改。 What if your data source is immutable data or a new data structure every time (such as a JSON response)? 如果您的数据源每次都是不可变数据或新数据结构（例如JSON响应），该怎么办？

Dirty checking and Object.observe does not work on closure scope state. 脏检查和Object.observe对闭包范围状态不起作用。

These two things are very limiting to functional patterns obviously. 这两件事显然对功能模式非常有限。

Additionally, when your model complexity grows, it becomes increasingly expensive to do dirty tracking. 此外，当您的模型复杂性增加时，进行脏跟踪变得越来越昂贵。 However, if you only do diffing on the visual tree, like React, then it doesn't grow as much since the amount of data you're able to show on the screen at any given point is limited by UIs. 但是，如果你只在视觉树上进行差异化，比如React，那么它就不会增长太多，因为你能够在任何给定点上在屏幕上显示的数据量受到UI的限制。 Pete's link above covers more of the perf benefits. Pete上面的链接涵盖了更多的性能优势。

https://news.ycombinator.com/item?id=6937668 https://news.ycombinator.com/item?id=6937668

---

#4楼

I'm the primary author of a virtual-dom module, so I might be able to answer your questions. 我是虚拟dom模块的主要作者，所以我或许可以回答你的问题。 There are in fact 2 problems that need to be solved here 事实上，这里有两个问题需要解决

1. When do I re-render? 我什么时候重新渲染？ Answer: When I observe that the data is dirty. 答：当我发现数据很脏时。
2. How do I re-render efficiently? 如何有效地重新渲染？ Answer: Using a virtual DOM to generate a real DOM patch 答：使用虚拟DOM生成真正的DOM补丁

In React, each of your components have a state. 在React中，每个组件都有一个状态。 This state is like an observable you might find in knockout or other MVVM style libraries. 这种状态就像你可能在淘汰赛或其他MVVM风格的库中找到的一个可观察的状态。 Essentially, React knows when to re-render the scene because it is able to observe when this data changes. 本质上，React知道何时重新渲染场景，因为它能够观察到此数据何时发生变化。 Dirty checking is slower than observables because you must poll the data at a regular interval and check all of the values in the data structure recursively. 脏检查比可观察的慢，因为您必须定期轮询数据并以递归方式检查数据结构中的所有值。 By comparison, setting a value on the state will signal to a listener that some state has changed, so React can simply listen for change events on the state and queue up re-rendering. 相比之下，在状态上设置值将向侦听器发出某个状态已更改的信号，因此React可以简单地侦听状态上的更改事件并排队重新呈现。

The virtual DOM is used for efficient re-rendering of the DOM. 虚拟DOM用于有效地重新呈现DOM。 This isn't really related to dirty checking your data. 这与脏检查数据无关。 You could re-render using a virtual DOM with or without dirty checking. 您可以使用带有或不带脏检查的虚拟DOM重新渲染。 You're right in that there is some overhead in computing the diff between two virtual trees, but the virtual DOM diff is about understanding what needs updating in the DOM and not whether or not your data has changed. 你是对的，计算两个虚拟树之间的差异有一些开销，但虚拟DOM差异是关于理解DOM中需要更新的内容，而不是你的数据是否发生了变化。 In fact, the diff algorithm is a dirty checker itself but it is used to see if the DOM is dirty instead. 事实上， diff算法本身就是一个脏检查器，但它用于查看DOM是否是脏的。

We aim to re-render the virtual tree only when the state changes. 我们的目标是仅在状态发生变化时重新渲染虚拟树。 So using an observable to check if the state has changed is an efficient way to prevent unnecessary re-renders, which would cause lots of unnecessary tree diffs. 因此，使用observable检查状态是否已更改是防止不必要的重新渲染的有效方法，这会导致大量不必要的树差异。 If nothing has changed, we do nothing. 如果什么都没有改变，我们什么都不做。

A virtual DOM is nice because it lets us write our code as if we were re-rendering the entire scene. 虚拟DOM很不错，因为它让我们编写代码就好像我们重新渲染整个场景一样。 Behind the scenes we want to compute a patch operation that updates the DOM to look how we expect. 在幕后我们想要计算一个补丁操作，它可以更新DOM以查看我们的预期。 So while the virtual DOM diff/patch algorithm is probably not the optimal solution , it gives us a very nice way to express our applications. 因此，尽管虚拟DOM差异/补丁算法可能不是最佳解决方案 ，但它为我们提供了表达应用程序的非常好的方式。 We just declare exactly what we want and React/virtual-dom will work out how to make your scene look like this. 我们只是声明我们想要的东西，React / virtual-dom将解决如何让你的场景看起来像这样。 We don't have to do manual DOM manipulation or get confused about previous DOM state. 我们不必进行手动DOM操作或对之前的DOM状态感到困惑。 We don't have to re-render the entire scene either, which could be much less efficient than patching it. 我们也不必重新渲染整个场景，这可能比修补它的效率低得多。

---

#5楼

I really like the potential power of the Virtual DOM (especially server-side rendering) but I would like to know all the pros and cons. 我非常喜欢Virtual DOM的潜在力量（特别是服务器端渲染），但我想知道所有的优点和缺点。

-- OP - OP

React is not the only DOM manipulation library. React不是唯一的DOM操作库。 I encourage you to understand the alternatives by reading this article from Auth0 that includes detailed explanation and benchmarks. 我鼓励您通过阅读Auth0中的这篇文章来理解其他选择，其中包括详细的解释和基准。 I'll highlight here their pros and cons, as you asked: 你会问：我会在这里强调一下它们的优点和缺点：

React.js' Virtual DOM React.js的虚拟DOM

PROS PROS

• Fast and efficient "diffing" algorithm 快速高效的“差异”算法
• Multiple frontends (JSX, hyperscript) 多个前端（JSX，hyperscript）
• Lightweight enough to run on mobile devices 轻巧，足以在移动设备上运行
• Lots of traction and mindshare 很多牵引力和思想分享
• Can be used without React (ie as an independent engine) 可以在没有React的情况下使用（即作为独立引擎）

CONS 缺点

• Full in-memory copy of the DOM (higher memory use) 完整的内存中的DOM副本（更高的内存使用率）
• No differentiation between static and dynamic elements 静态和动态元素之间没有区别

---

Ember.js' Glimmer Ember.js'微光

PROS PROS

• Fast and efficient diffing algorithm 快速高效的衍射算法
• Differentiation between static and dynamic elements 静态和动态元素之间的区别
• 100% compatible with Ember's API (you get the benefits without major updates to your existing code) 与Ember的API 100％兼容（无需对现有代码进行重大更新即可获得优势）
• Lightweight in-memory representation of the DOM DOM的轻量级内存表示

CONS 缺点

• Meant to be used only in Ember 只能在Ember中使用
• Only one frontend available 只有一个前端可用

---

Incremental DOM 增量DOM

PROS PROS

• Reduced memory usage 减少内存使用量
• Simple API 简单的API
• Easily integrates with many frontends and frameworks (meant as a template engine backend from the beginning) 轻松集成许多前端和框架（从一开始就意味着模板引擎后端）

CONS 缺点

• Not as fast as other libraries (this is arguable, see the benchmarks below) 没有其他库那么快（这是有争议的，请参阅下面的基准）
• Less mindshare and community use 减少思想共享和社区使用

---

#6楼

Virtual Dom is not invented by react. 虚拟Dom不是由反应发明的。 It is part of HTML dom. 它是HTML dom的一部分。 It is lightweight and detached from the browser-specific implementation details. 它是轻量级的，与特定于浏览器的实现细节分离。

We can think virtual DOM as React's local and simplified copy of the HTML DOM. 我们可以将虚拟DOM视为React的HTML DOM的本地和简化副本。 It allows React to do its computations within this abstract world and skip the “real” DOM operations, often slow and browser-specific. 它允许React在这个抽象的世界中进行计算，并跳过“真正的”DOM操作，通常是缓慢的，特定于浏览器的。 Actually there is no big differenc between DOM and VIRTUAL DOM. 实际上，DOM和VIRTUAL DOM之间没有很大的区别。

Below are the points why Virtual Dom is used (source Virtual DOM in ReactJS ): 以下是使用Virtual Dom的原因（ ReactJS中的源虚拟DOM ）：

When you do: 当你这样做时：

 document.getElementById('elementId').innerHTML = "New Value" Following thing happens: 

1. Browser needs to parse the HTML 浏览器需要解析HTML
2. It removes the child element of elementId 它删除了elementId的子元素
3. Updates the DOM value with new value 使用新值更新DOM值
4. Re-calculate the css for the parent and child 重新计算父母和孩子的css
5. Update the layout ie each elements exact co-ordinates on the screen 更新布局，即每个元素在屏幕上精确坐标
6. Traverse the render tree and paint it on the browser display 遍历渲染树并在浏览器显示上绘制它

Recalculating the CSS and changed layouts uses complex algorithm and they effect the performance. 重新计算CSS和更改的布局使用复杂的算法，它们会影响性能。

As well as updating the DOM properties ie. 以及更新DOM属性，即。 values. 值。 It follows a algorithm. 它遵循一种算法。

Now, suppose if you update DOM 10 times directly, then all the above steps will run one by one and updating DOM algorithms will take time to updates DOM values. 现在，假设您直接更新DOM 10次，那么上述所有步骤将逐个运行，更新DOM算法将花费时间来更新DOM值。

This, is why Real DOM is slower than virtual DOM. 这就是Real DOM比虚拟DOM慢的原因。