blocks|key|164434|text|我最近在这里读了一篇关于React的diff算法的详细文章：http://calendar.perfplanet.com/2013/diff/。据我所知，让React变得快速的原因是：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|164435|仅对子树进行|164436|批处理DOM读/写operations.|unordered-list-item|164437|Efficient更新。|164438|164439|与脏检查相比，IMO的主要区别是：|164440|164441|Model脏检查：每当调用setState时，React组件都被显式设置为脏组件，因此这里不需要(数据)比较。对于脏检查，每次摘要loop.|ordered-list-item|style|BOLD|CODE|164442|DOM更新：DOM操作都会发生(模型的)比较，这是非常昂贵的，因为修改DOM也会应用和计算CSS，布局。不必要的DOM修改所节省的时间可能比区分虚拟DOM所花费的时间更长。|164443|164444|第二点对于非平凡的模型更重要，例如具有大量字段或大型列表的模型。复杂模型的一个字段更改将只导致涉及该字段的DOM元素所需的操作，而不是整个视图/模板。|164445|entityMap|0|LINK|mutability|MUTABLE|url|http://calendar.perfplanet.com/2013/diff/^0|U|15|0|0|0|0|0|0|0|0|0|8|D|8|0|0|5|0|0|0^^$0|@$1|2|3|4|5|6|7|17|8|@]|9|@$A|18|B|19|1|1A]]|C|$]]|$1|D|3|E|5|6|7|1B|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|1C|8|@]|9|@]|C|$]]|$1|I|3|J|5|H|7|1D|8|@]|9|@]|C|$]]|$1|K|3|-4|5|6|7|1E|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|1F|8|@]|9|@]|C|$]]|$1|N|3|-4|5|6|7|1G|8|@]|9|@]|C|$]]|$1|O|3|P|5|Q|7|1H|8|@$A|1I|B|1J|R|S]|$A|1K|B|1L|R|T]]|9|@]|C|$]]|$1|U|3|V|5|Q|7|1M|8|@$A|1N|B|1O|R|S]]|9|@]|C|$]]|$1|W|3|-4|5|6|7|1P|8|@]|9|@]|C|$]]|$1|X|3|Y|5|6|7|1Q|8|@]|9|@]|C|$]]|$1|Z|3|-4|5|6|7|1R|8|@]|9|@]|C|$]]]|10|$11|$5|12|13|14|C|$15|16]]]]

<p>I recently read a detailed article about React's diff algorithm here: <a href="http://calendar.perfplanet.com/2013/diff/" rel="noreferrer">http://calendar.perfplanet.com/2013/diff/</a>. From what I understand, what makes React fast is:</p>

<ul>
<li>Batched DOM read/write operations.</li>
<li>Efficient update of sub-tree only.</li>
</ul>

<p>Compared to dirty-check, the key differences IMO are:</p>

<ol>
<li><p><strong>Model dirty-checking</strong>: React component is explicitly set as dirty whenever <code>setState</code> is called, so there's no comparison (of the data) needed here. For dirty-checking, the comparison (of the models) always happen each digest loop.</p></li>
<li><p><strong>DOM updating</strong>: DOM operations are very expensive because modifying the DOM will also apply and calculate CSS styles, layouts. The saved time from unnecessary DOM modification can be longer than the time spent diffing the virtual DOM. </p></li>
</ol>

<p>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.</p>


blocks|key|2760554|text|以下是React团队成员Sebastian+Markb­ge的评论，它揭示了一些问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2760555|2760556|+React对输出(这是一种已知的可序列化格式，即DOM属性)进行比较。这意味着源数据可以是任何格式。它可以是闭包中不可变的数据结构和状态。|blockquote|2760557|2760558|角度模型不保留引用透明性，因此本质上是可变的。您可以更改现有模型以跟踪更改。如果您的数据源每次都是不可变的数据或新的数据结构(例如JSON响应)，该怎么办？|2760559|脏检查和Object.observe在闭包作用域状态下不起作用。|2760560|显然，这两件事对功能模式是非常有限的。|2760561|此外，当您的模型复杂性增加时，执行脏跟踪的成本也会越来越高。但是，如果只在可视化树上进行差异，比如React，那么它不会增长很多，因为您在任何给定点能够在屏幕上显示的数据量都受到UI的限制。Pete上面的链接涵盖了更多的perf好处。|2760562|2760563|https://news.ycombinator.com/item?id=6937668|offset|length|2760564|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|0|0|0|0|0|0|0|18|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|12|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|14|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|15|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|16|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|17|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|18|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|19|8|@]|9|@$R|1A|S|1B|1|1C]]|A|$]]|$1|T|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|U|$V|$5|W|X|Y|A|$Z|Q]]]]

<p>Here's a comment by React team member Sebastian Markbåge which sheds some light:</p>
<blockquote>
<p>React does the diffing on the output (which is a known serializable format, DOM attributes). This means that the source data can be of any format. It can be immutable data structures and state inside of closures.</p>
<p>The Angular model doesn't preserve referential transparency and therefore is inherently mutable. 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)?</p>
<p>Dirty checking and Object.observe does not work on closure scope state.</p>
<p>These two things are very limiting to functional patterns obviously.</p>
<p>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. Pete's link above covers more of the perf benefits.</p>
</blockquote>
<p><a href="https://news.ycombinator.com/item?id=6937668" rel="noreferrer">https://news.ycombinator.com/item?id=6937668</a></p>


blocks|key|2973306|text|我是一个virtual-dom模块的主要作者，所以我也许能够回答您的问题。事实上，这里有两个问题需要解决|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2973307|回答:当我观察到数据是脏的时。|2973308|How我可以高效地重新渲染吗？答案:使用虚拟DOM生成真实的DOM补丁|unordered-list-item|style|BOLD|2973309|2973310|在React中，每个组件都有一个状态。这种状态类似于您可能在knockout或其他MVVM样式库中找到的可观察对象。本质上，当重新渲染场景时，React知道，因为它能够观察到这些数据何时发生变化。脏检查比可观察数据慢，因为您必须定期轮询数据，并递归检查数据结构中的所有值。相比之下，在状态上设置一个值将通知侦听器某个状态已经更改，因此React可以简单地侦听状态上的更改事件并排队重新呈现。|2973311|虚拟DOM用于高效地重新呈现DOM。这与脏检查您的数据并不真正相关。您可以使用虚拟DOM重新渲染，无论是否进行脏检查。您说得对，在计算两个虚拟树之间的差异时存在一些开销，但虚拟DOM差异是为了了解DOM中需要更新的内容，以及您的数据是否发生了更改。实际上，diff算法本身就是一个脏检查器，但它是用来查看DOM是否脏的。|2973312|我们的目标是只有在状态改变时才重新渲染虚拟树。因此，使用可观察对象检查状态是否已更改是防止不必要的重新渲染的有效方法，这将导致许多不必要的树差异。如果什么都没有改变，我们什么也不做。|2973313|虚拟DOM很好，因为它可以让我们编写代码，就像我们重新渲染整个场景一样。在幕后，我们想要计算一个更新DOM的补丁操作，使其看起来符合我们的期望。因此，尽管虚拟DOM+diff/patch算法可能不是最佳的解决方案，但它为我们提供了一种很好的表达应用程序的方式。我们只需准确地声明我们想要的东西，React/virtual-dom就会解决如何让你的场景看起来像这样。我们不需要手动操作DOM，也不需要对以前的DOM状态感到困惑。我们也不需要重新渲染整个场景，这可能比修补效率低得多。|2973314|entityMap|0|LINK|mutability|MUTABLE|url|http://github.com/Matt-Esch/virtual-dom^0|4|B|0|0|0|0|F|0|0|26|39|0|0|40|0|0|2N|B|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@$A|12|B|13|1|14]]|C|$]]|$1|D|3|E|5|6|7|15|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|16|8|@$A|17|B|18|I|J]]|9|@]|C|$]]|$1|K|3|-4|5|6|7|19|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|1A|8|@$A|1B|B|1C|I|J]]|9|@]|C|$]]|$1|N|3|O|5|6|7|1D|8|@$A|1E|B|1F|I|J]]|9|@]|C|$]]|$1|P|3|Q|5|6|7|1G|8|@]|9|@]|C|$]]|$1|R|3|S|5|6|7|1H|8|@$A|1I|B|1J|I|J]]|9|@]|C|$]]|$1|T|3|-4|5|6|7|1K|8|@]|9|@]|C|$]]]|U|$V|$5|W|X|Y|C|$Z|10]]]]

<p>I'm the primary author of a <a href="http://github.com/Matt-Esch/virtual-dom" rel="noreferrer">virtual-dom</a> module, so I might be able to answer your questions. There are in fact 2 problems that need to be solved here</p>

<ol>
<li><strong>When do I re-render?</strong>  Answer: When I observe that the data is dirty.  </li>
<li><strong>How do I re-render efficiently?</strong> Answer:  Using a virtual DOM to generate a real DOM patch</li>
</ol>

<p>In React, each of your components have a state. This state is like an observable you might find in knockout or other MVVM style libraries. Essentially, React knows <strong>when</strong> to re-render the scene because it is able to observe when this data changes. 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.</p>

<p>The virtual DOM is used for efficient re-rendering of the DOM. This isn't really related to dirty checking your data. You could re-render using a virtual DOM with or without dirty checking. 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. In fact, <strong>the diff algorithm is a dirty checker itself</strong> but it is used to see if the DOM is dirty instead.</p>

<p>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. If nothing has changed, we do nothing.</p>

<p>A virtual DOM is nice because it lets us write our code as if we were re-rendering the entire scene. Behind the scenes we want to compute a patch operation that updates the DOM to look how we expect. So while the virtual DOM diff/patch algorithm <strong>is probably not the optimal solution</strong>, it gives us a very nice way to express our applications. We just declare exactly what we want and React/virtual-dom will work out how to make your scene look like this. We don't have to do manual DOM manipulation or get confused about previous DOM state. We don't have to re-render the entire scene either, which could be much less efficient than patching it.</p>


blocks|key|2973410|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2973411|我真的很喜欢虚拟DOM的潜在功能(特别是服务器端渲染)，但我想知道所有的优缺点。|blockquote|2973412|2973413|--操作|2973414|2973415|React不是唯一的DOM操作库。我鼓励您通过阅读这篇包含详细解释和基准的article+from+Auth0来了解替代方案。正如您所问的，我将在这里强调它们的优缺点：|offset|length|2973416|2973417|+React.js的虚拟DOM|2973418|2973419|2973420|📷|atomic|2973421|优点|2973422|快速高效的algorithm|2973423|Multiple前端(JSX、hyperscript)|unordered-list-item|2973424|
|2973425|Lightweight，足以在移动设备上运行)|2973426|快速高效的“扩散”前端|2973427|大量的traction和JSX无需React即可使用(即作为独立引擎)|2973428|2973429|2973430|缺点|2973431|2973432|+DOM的完整内存中拷贝(更高的内存使用率)|2973433|静态和动态元素之间没有区别|2973434|2973435|2973436|Ember.js的微光|2973437|2973438|2973439|与Ember兼容的静态和动态algorithm|2973440|Differentiation之间快速高效的区分|2973441|2973442|(无需对现有的DOM|2973443|
的内存中表示进行重大更新即可获得好处|2973444|2973445|2973446|只能在Ember|2973447|中使用，只有一个前端可用|2973448|2973449|2973450|增量DOM|2973451|2973452|2973453|2973454|Reduced+memory+usage|2973455|Simple+API|2973456|轻松与许多前端和框架集成(从一开始就是模板引擎后端)|2973457|2973458|2973459|2973460|不如其他库快(这是有争议的，请参阅下面的基准测试)|2973461|较少使用|2973462|2973463|entityMap|0|LINK|mutability|MUTABLE|url|https://auth0.com/blog/2015/11/20/face-off-virtual-dom-vs-incremental-dom-vs-glimmer/|1|IMAGE|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/3d953f457e1c3f211e480a037873aae0.png|imageAlt|2|https://ask.qcloudimg.com/http-save/yehe-900000/ec9a1bebf7bfad7719fba1e4ef275df8.png|3|https://ask.qcloudimg.com/http-save/yehe-900000/f0ae0d0a23541b6154b1139d6837c3d2.png^0|0|0|0|0|0|11|I|0|0|0|0|0|0|0|1|1|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1|2|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1|3|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|35|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|36|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|37|7|@]|8|@]|9|$]]|$1|E|3|F|4|5|6|38|7|@]|8|@]|9|$]]|$1|G|3|-4|4|5|6|39|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|3A|7|@]|8|@$J|3B|K|3C|1|3D]]|9|$]]|$1|L|3|-4|4|5|6|3E|7|@]|8|@]|9|$]]|$1|M|3|N|4|C|6|3F|7|@]|8|@]|9|$]]|$1|O|3|-4|4|5|6|3G|7|@]|8|@]|9|$]]|$1|P|3|-4|4|5|6|3H|7|@]|8|@]|9|$]]|$1|Q|3|R|4|S|6|3I|7|@]|8|@$J|3J|K|3K|1|3L]]|9|$]]|$1|T|3|U|4|5|6|3M|7|@]|8|@]|9|$]]|$1|V|3|W|4|5|6|3N|7|@]|8|@]|9|$]]|$1|X|3|Y|4|Z|6|3O|7|@]|8|@]|9|$]]|$1|10|3|11|4|5|6|3P|7|@]|8|@]|9|$]]|$1|12|3|13|4|Z|6|3Q|7|@]|8|@]|9|$]]|$1|14|3|15|4|Z|6|3R|7|@]|8|@]|9|$]]|$1|16|3|17|4|Z|6|3S|7|@]|8|@]|9|$]]|$1|18|3|-4|4|5|6|3T|7|@]|8|@]|9|$]]|$1|19|3|-4|4|5|6|3U|7|@]|8|@]|9|$]]|$1|1A|3|1B|4|5|6|3V|7|@]|8|@]|9|$]]|$1|1C|3|-4|4|5|6|3W|7|@]|8|@]|9|$]]|$1|1D|3|1E|4|Z|6|3X|7|@]|8|@]|9|$]]|$1|1F|3|1G|4|Z|6|3Y|7|@]|8|@]|9|$]]|$1|1H|3|-4|4|5|6|3Z|7|@]|8|@]|9|$]]|$1|1I|3|-4|4|5|6|40|7|@]|8|@]|9|$]]|$1|1J|3|1K|4|5|6|41|7|@]|8|@]|9|$]]|$1|1L|3|R|4|S|6|42|7|@]|8|@$J|43|K|44|1|45]]|9|$]]|$1|1M|3|U|4|5|6|46|7|@]|8|@]|9|$]]|$1|1N|3|1O|4|5|6|47|7|@]|8|@]|9|$]]|$1|1P|3|1Q|4|Z|6|48|7|@]|8|@]|9|$]]|$1|1R|3|11|4|5|6|49|7|@]|8|@]|9|$]]|$1|1S|3|1T|4|Z|6|4A|7|@]|8|@]|9|$]]|$1|1U|3|1V|4|5|6|4B|7|@]|8|@]|9|$]]|$1|1W|3|1B|4|5|6|4C|7|@]|8|@]|9|$]]|$1|1X|3|-4|4|5|6|4D|7|@]|8|@]|9|$]]|$1|1Y|3|1Z|4|Z|6|4E|7|@]|8|@]|9|$]]|$1|20|3|21|4|Z|6|4F|7|@]|8|@]|9|$]]|$1|22|3|-4|4|5|6|4G|7|@]|8|@]|9|$]]|$1|23|3|-4|4|5|6|4H|7|@]|8|@]|9|$]]|$1|24|3|25|4|5|6|4I|7|@]|8|@]|9|$]]|$1|26|3|R|4|S|6|4J|7|@]|8|@$J|4K|K|4L|1|4M]]|9|$]]|$1|27|3|U|4|5|6|4N|7|@]|8|@]|9|$]]|$1|28|3|-4|4|5|6|4O|7|@]|8|@]|9|$]]|$1|29|3|2A|4|Z|6|4P|7|@]|8|@]|9|$]]|$1|2B|3|2C|4|Z|6|4Q|7|@]|8|@]|9|$]]|$1|2D|3|2E|4|Z|6|4R|7|@]|8|@]|9|$]]|$1|2F|3|-4|4|5|6|4S|7|@]|8|@]|9|$]]|$1|2G|3|1B|4|5|6|4T|7|@]|8|@]|9|$]]|$1|2H|3|-4|4|5|6|4U|7|@]|8|@]|9|$]]|$1|2I|3|2J|4|Z|6|4V|7|@]|8|@]|9|$]]|$1|2K|3|2L|4|Z|6|4W|7|@]|8|@]|9|$]]|$1|2M|3|-4|4|5|6|4X|7|@]|8|@]|9|$]]|$1|2N|3|-4|4|5|6|4Y|7|@]|8|@]|9|$]]]|2O|$2P|$4|2Q|2R|2S|9|$2T|2U]]|2V|$4|2W|2R|2X|9|$2Y|2Z|30|-4]]|31|$4|2W|2R|2X|9|$2Y|32|30|-4]]|33|$4|2W|2R|2X|9|$2Y|34|30|-4]]]]

<blockquote>
  <p>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.</p>
  
  <p><em>-- OP</em></p>
</blockquote>

<p>React is not the only DOM manipulation library. I encourage you to understand the alternatives by reading this <a href="https://auth0.com/blog/2015/11/20/face-off-virtual-dom-vs-incremental-dom-vs-glimmer/">article from Auth0</a> that includes detailed explanation and benchmarks. I'll highlight here their pros and cons, as you asked:</p>

<blockquote>
  <h1>React.js' Virtual DOM</h1>
  
  <p><a href="https://i.stack.imgur.com/S1vng.png"><img src="https://i.stack.imgur.com/S1vng.png" alt="enter image description here"></a></p>
  
  <h3>PROS</h3>
  
  <ul>
  <li>Fast and efficient "diffing" algorithm</li>
  <li>Multiple frontends (JSX, hyperscript)</li>
  <li>Lightweight enough to run on mobile devices</li>
  <li>Lots of traction and mindshare</li>
  <li>Can be used without React (i.e. as an independent engine)</li>
  </ul>
  
  <h3>CONS</h3>
  
  <ul>
  <li>Full in-memory copy of the DOM (higher memory use)</li>
  <li>No differentiation between static and dynamic elements</li>
  </ul>
  
  <hr>
  
  <h1>Ember.js' Glimmer</h1>
  
  <p><a href="https://i.stack.imgur.com/AgSYC.png"><img src="https://i.stack.imgur.com/AgSYC.png" alt="enter image description here"></a></p>
  
  <h3>PROS</h3>
  
  <ul>
  <li>Fast and efficient diffing algorithm</li>
  <li>Differentiation between static and dynamic elements</li>
  <li>100% compatible with Ember's API (you get the benefits without major updates to your existing code)</li>
  <li>Lightweight in-memory representation of the DOM</li>
  </ul>
  
  <h3>CONS</h3>
  
  <ul>
  <li>Meant to be used only in Ember</li>
  <li>Only one frontend available</li>
  </ul>
  
  <hr>
  
  <h1>Incremental DOM</h1>
  
  <p><a href="https://i.stack.imgur.com/M8f40.png"><img src="https://i.stack.imgur.com/M8f40.png" alt="enter image description here"></a></p>
  
  <h3>PROS</h3>
  
  <ul>
  <li>Reduced memory usage</li>
  <li>Simple API</li>
  <li>Easily integrates with many frontends and frameworks (meant as a template engine backend from the beginning)</li>
  </ul>
  
  <h3>CONS</h3>
  
  <ul>
  <li>Not as fast as other libraries (this is arguable, see the benchmarks below)</li>
  <li>Less mindshare and community use</li>
  </ul>
</blockquote>


blocks|key|165678|text|虚拟Dom不是由react发明的。它是HTML+dom的一部分。它是轻量级的，并且独立于特定于浏览器的实现细节。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|165679|我们可以认为虚拟DOM是React的HTML+DOM的本地简化副本。它允许React在这个抽象的世界中进行计算，并跳过“真正的”DOM操作，这些操作通常很慢并且特定于浏览器。实际上，DOM和虚拟DOM之间没有太大的区别。|165680|以下是使用虚拟Dom的原因(源Virtual+DOM+in+ReactJS)：|offset|length|165681|165682|当你这样做的时候：|blockquote|165683|165684|document.getElementById('elementId').innerHTML+=+"New+Value“发生以下事情：|165685|165686|165687|浏览器需要解析|ordered-list-item|165688|，它会删除elementId|165689|Updates的子元素，用新的value|165690|Re-calculate去掉DOM值，将父元素和子元素的css更新为|165691|，更新布局，即每个元素在value|165692|Re-calculate上精确协调渲染树，并将其绘制在浏览器上显示|165693|165694|重新计算CSS和更改的布局使用复杂的算法，它们会影响性能。|165695|以及更新DOM属性ie。值。它遵循一种算法。|165696|现在，假设您直接更新DOM+10次，那么上面的所有步骤都将逐个运行，更新DOM算法将花费时间来更新DOM值。|165697|这就是为什么真正的DOM比虚拟的DOM慢。|165698|entityMap|0|LINK|mutability|MUTABLE|url|https://hackernoon.com/virtual-dom-in-reactjs-43a3fdb1d130^0|0|0|F|M|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1L|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1M|8|@]|9|@$F|1N|G|1O|1|1P]]|A|$]]|$1|H|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|1R|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|1S|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1T|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1U|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]|$1|Q|3|R|5|S|7|1W|8|@]|9|@]|A|$]]|$1|T|3|U|5|S|7|1X|8|@]|9|@]|A|$]]|$1|V|3|W|5|S|7|1Y|8|@]|9|@]|A|$]]|$1|X|3|Y|5|S|7|1Z|8|@]|9|@]|A|$]]|$1|Z|3|10|5|S|7|20|8|@]|9|@]|A|$]]|$1|11|3|12|5|S|7|21|8|@]|9|@]|A|$]]|$1|13|3|-4|5|6|7|22|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|23|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|24|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|25|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|26|8|@]|9|@]|A|$]]|$1|1C|3|-4|5|6|7|27|8|@]|9|@]|A|$]]]|1D|$1E|$5|1F|1G|1H|A|$1I|1J]]]]

<p>Virtual Dom is not invented by react. It is part of HTML dom.
It is lightweight and detached from the browser-specific implementation details.</p>

<p>We can think virtual DOM as React’s local and simplified copy of the HTML DOM. It allows React to do its computations within this abstract world and skip the “real” DOM operations, often slow and browser-specific. Actually there is no big differenc between DOM and VIRTUAL DOM.</p>

<p>Below are the points why Virtual Dom is used (source <a href="https://hackernoon.com/virtual-dom-in-reactjs-43a3fdb1d130" rel="nofollow noreferrer">Virtual DOM in ReactJS</a>):</p>

<blockquote>
  <p>When you do:</p>

<pre><code>document.getElementById('elementId').innerHTML = "New Value" Following thing happens:
</code></pre>
  
  <ol>
  <li>Browser needs to parse the HTML</li>
  <li>It removes the child element of elementId</li>
  <li>Updates the DOM value with new value</li>
  <li>Re-calculate the css for the parent and child</li>
  <li>Update the layout i.e. each elements exact co-ordinates on the screen</li>
  <li>Traverse the render tree and paint it on the browser display</li>
  </ol>
  
  <p>Recalculating the CSS and changed layouts uses complex algorithm and
  they effect the performance.</p>
</blockquote>

<p>As well as updating the DOM properties ie. values. It follows a algorithm.</p>

<p>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.</p>

<p>This, is why Real DOM is slower than virtual DOM.</p>


<p>I saw a <a href="http://facebook.github.io/react/index.html" rel="noreferrer">React</a> dev talk at (<a href="http://www.youtube.com/watch?v=x7cQ3mrcKaY" rel="noreferrer">Pete Hunt: React: Rethinking best practices -- JSConf EU 2013</a>)  and the speaker mentioned that dirty-checking of the model can be slow. 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?</p>

<p>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.</p>


Why is React's concept of Virtual DOM said to be more performant than dirty model checking?

数据结构

服务器

JSON

我在()上看了一次开发人员的演讲，演讲者提到模型的脏检查可能会很慢。但是，计算虚拟DOM之间的差异实际上不是更差吗，因为在大多数情况下，虚拟DOM应该比模型更大？我真的很喜欢Virtual DOM的潜在功能(特别是服务器端渲染)，但我想知道所有的优缺点。

问为什么React的虚拟DOM的概念被认为比脏的模型检查性能更好？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么React的虚拟DOM的概念被认为比脏的模型检查性能更好？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么React的虚拟DOM的概念被认为比脏的模型检查性能更好？
EN