網上都說操作真實 DOM 慢，但測試結果卻比 React 更快，為什麼？

注意到列表多了許多注釋節點吧，這叫做路標系統，用於確定數組元素的作用域範圍，方便移動它們。大家如果會angular，使用ng-repeat也會有這樣的注釋元素。但這些不是重點。

為了讓大家明白虛擬DOM為什麼這麼高效的原因，我們直接在chrome控制台下對這些LI元素做一些修改，全部加上title屬性。它們能方便告訴我們，一會兒點擊了change按鈕，重新渲染列表，這些LI元素是新建的，還是沿用的舊的。

這只是diff演算法的冰山一角。

其實，如果沒有循環綁定（ms-repeat, ng-repeat, v-for），MVVM是不存在性能問題。

循環綁定會破壞原來的頁面結構，引起頁面重新布局。

傳統的字元串模板，對付它們只會innerHTML，這導致每次都會生成大量的節點，選區，游標位置，事件及掛在它上面的第三方組件都要重新處理。

而一些弱的MVVM框架，它們的演算法就差一點，無法盡量利用已有節點。

avalon與react的做法是使用了虛擬DOM做緩衝層，每次數據變動，都生成對應區域的虛擬DOM樹，然後兩個虛擬DOM做合併操作（diff），得到更新的操作集(patch)。

avalon目前沒有考慮支持多種渲染形態（只有DOM，不存在canvas, webgl, native等渲染介質），那麼可以偷懶，對不存在綁定的元素及其孩子，不再轉換為虛擬DOM，這樣減少diff的節點。

創建一個DOM的消耗是非常驚人，目前，在瀏覽器中存在四種形態的對象

1. 超輕量 Object.create(nulll)

2. 輕量 一般的對象 {}

3. 重量 帶有訪問器屬性的對象, avalon或vue的VM對象

4. 超重量 各種節點或window對象

然後頻繁訪問或創建 3，4種形態的對象是很不明智的。但VM對象能為編程帶來極好的用戶體驗，因此這個代價是可以接受的。

在過去的MVVM框架中，綁定屬性的操作主體是元素節點（它們一般放在觀察者模式的訂閱數組中），有了虛擬DOM，我們就直接操作虛擬DOM，這樣它們移出或插入虛擬DOM樹，是不耗費什麼性能，更不會結合CSS樣式表產生reflow,rerender 什麼破事。 因此原真實DOM擁有了綁定屬性(ms-*, ng-*)與路標系統 ，以後我們將虛擬DOM樹的變更同步到真實DOM樹時是非常方便的。

而react是怎麼追蹤到其更變更的節點呢？它有data-reactid！只要確保對應關係，虛擬DOM怎麼插入，移除，重排，react會在一個事務的盡頭，才開始重新真實DOM，這樣也能確保更新成功。

通過JS修改屬性時觸發DOM回調 · Issue #272 · RubyLouvre/avalon · GitHub

其二，能在虛擬DOM與真實DOM建立映射關係.avalon是使用綁定屬性與路標系統 ，react使用data-reactid，但data-reactid是元素節點的自定義屬性，對於文本節點，它沒有辦法，只好外包一個span，因此嚴重破壞舊有結構。即便插入了這麼span，react性能還是很快。

第三，react與avalon的所有虛擬DOM對象是可回收循環利用。而節點循環利用是很危險，很易造成內存泄漏。

虛擬DOM不只是一個緩衝層，裡面涉及大量演算法，你可以使用hash或KMP，確保更新最少。或者在某級對象創建一個更新對象包，將重複變更的屬性放在裡面，這樣aaa=bbb, aaa=ccc,aaa=ddd就自動合併成一個aaa=ddd。

為了追求性能，react強制單向流動，方便讓狀態疊加。但雙向綁定也能疊加，只是會讓VM內部數據多轉幾圈。

無論怎麼樣，虛擬DOM是一個偉大的發明，但react實現得比較笨拙而已。隨著大家對其源碼的研讀，今年會冒出更多同類型產品。前端就是因為源碼公開而繁榮昌盛！因此大家必須讀源碼，只會調API，永遠是低級碼農。

各按10次，結果如下

• 題主測試結果反常是因為測試用例構造有問題。
• React.js 相對於直接操作原生DOM有很大的性能優勢， 背後的技術支撐是基於virtual DOM的batching 和diff.

• React.js 的使用的virtual DOM 在Javascript Engine中也有執行效率的優勢。

如果想知道解釋，請繼續閱讀。。

原生 (只保留了關鍵代碼，其他都去掉了，這樣看得更清楚一點）

這裡看出問題沒？

1. 構造一個 String, 包含一個1000個 Tag。

2. 把這1000個 Tag 一次性添加到 DOM 樹中。

其實，題主的測試用例只做了一次 DOM 操作。。而且主要問題是，如果你真的做一個WebAPP, 然後直接操作DOM更新，更新的模式完全不是這樣子的。

我們來看看你在插入一個DOM元素的時候，發生了什麼.

「 You may be thinking that it"s expensive to change data if there are a large number of nodes under an owner. The good news is that JavaScript is fast and `render()` methods tend to be quite simple, so in most applications this is extremely fast. Additionally, the bottleneck is almost always the DOM mutation and not JS execution. React will optimize this for you using batching and change detection.「

給你們每個條目加個標示符，這樣每次更新的DOM都不一樣，我看React.js你怎麼做Diff, 哇哈哈哈哈哈.

• 第一次點擊運行的時候所耗的時間 ＝ 框架被編譯的時間(JIT) + 執行時間

• 之後執行的時間 ＝ 執行時間。

var tplDom = document.createElement("div");
container.appendChild(tplDom);
tplDom.innerHTML = html;
html = "";


tplDom先加入global DOM然後在修改，這個算是刷global DOM了吧？

Raw的性能統計

• 但是「通過引入函數式思維來加強對狀態的管理」， 貌似木有在「why」裡面提到？

• 第三方那個我木有找到引用。
• 而「Virtual DOM 可以渲染到非 DOM 的後端從而催生 ReactNative」, 是在：「Because React has its own lightweight representation of the document, we can do some pretty cool things with it:」

聽起來貌似是：

In a traditional JavaScript application, you need to look at what data changed and imperatively make changes to the DOM to keep it up-to-date. Even AngularJS, which provides a declarative interface via directives and data binding requires a linking function to manually update DOM nodes.

對於使用原生DOM介面操作大片DOM而言：

1. 如果對DOM創建過程稍作優化，首次創建必定比所有框架或者庫都快。

2. 如果對DOM變更過程做相對複雜的優化，它會比大多數框架或者庫都快。

3. 如果想要DOM的變更過程更快，需要作更加複雜的優化。

各按兩次或以上，比較最後一次的時間。

詳細原理可以在知乎里查 "虛擬DOM": 怎麼更好的理解虛擬DOM? - React.js 。

大致原理是，第一次渲染，大家都是往空的div里插入新的元素，react還多了個創建虛擬DOM的過程，自然較慢。

但第二次往後，raw的一般思路是刪了原來的元素重新創建元素插入。而react是在虛擬DOM上做比較，對實際的DOM只修改有變動的部分。就這個例子來說，修改原有元素的文本就行了，不需要走 "刪除-創建-插入" 的步驟。

一般隨機數據的情況下，近似可以認為DOM變更在50%左右，倘若基數又大，那麼直接innerHTML進行一次性重繪的時間記作t1，vd比對的時間記作t2，vd更新真實DOM的時間記作t3。

我看了很多答案感覺都在發散思維，沒答到點子上。問題是

然後這個測試結果為什麼 vanilla 會比 React 快？這個測試實際上就是測一個 data 數組內全部數據更改後重繪的時間。這個測試中所比較的包括 vanilla 在內的框架，其實都是做了數據綁定這件事，什麼意思，就是為了讓開發者把精力集中在操作數據，而接管 DOM 操作。

React 的 Virtual DOM 在這個測試中所做的事情是在數據更新後對修改前後的兩棵虛擬 DOM 樹進行 diff 差異對比，根據 React 的 diff 演算法，對比數組長度沒有變化，並且數組元素全是基本元素（div, span），那麼它將直接修改這些 DOM 元素內的 Text 節點，實際上做了 n 次 DOM 操作，併產生一次 container 的重繪（因為同一 tick 內 container 中的每個子節點都發生了改變）。

而 vanilla 所做的事情很簡單，每次數據變更後，拼接 html，然後填充到 container 的 innerHtml，實際上只做了一次 DOM 操作，併產生一次 container 的重繪。

所以，在這個測試中，React 和 vanilla 的 DOM 操作時間其實是差別不大。雖然 vanilla 只有一次 DOM 操作，但是他在瀏覽器引擎內會分解成 n 次節點創建，但是這總是比腳本級別的 javascript 做 n 次節點修改要快一點。即使兩者的 DOM 操作耗時一樣，React 依然會比 vanilla 慢一點，因為 React 在邏輯上還做了虛擬 DOM 操作創建，diff 差異對比和 reconciliation 調和差異。

--------------------- 以上為解答，以下吹水 ----------------------

其實這個測試根本不能左右你選擇使用 React 還是 vanilla，因為在實際的開發中整個數據的改變發生的頻率不會很大，即使 Angular 這麼慢，在偶爾發生一次整體數據變更的時候，這點時間還是可以忍受的。React 主要解決的是局部數據變更引起的重繪成本，這時 React 通過調和演算法可以分析出比較小的區域重繪的 DOM 操作方法，而使用 vanilla 或者其他模版庫，就只能整塊重繪了。

大家都忽略了一個問題，那就是原作者的 React 寫得很爛。

Benchmark：Performance Comparison for Knockout, Angular and React

正如 @noyobo 所說，題主貼出的 Benchmark，如果第二次 run React ，時間會長到幾千 ms ，這肯定不對勁啊。

玩玩重寫後的版本你就會發現，

你的問題就是錯的，從多個層面上來說都是錯的。

• 首先，這個測試顯示的數字上，是否 react 真的慢於原生？只有前兩次是這樣，後面你測一千次也是 react 更快。
• 其次，這個顯示的數字是否代表真實的速度？並不是這樣。實際表現，原生更慢。
• 羅志宇：網上都說操作真實 DOM 慢，但測試結果卻比 React 更快，為什麼？ 這個回答講的已經很清楚了，（就這個測試而言）原生花在 rendering 上的時間相當多，你可以自己用 Chrome 開發者工具的 performance 測測看。
• 我這裡的數據是，react 的版本，rendering 小於 scripting，原生的 rendering 是 scripting 的 1.5 倍以上。本來 react 顯示的數字就比原生小，我這裡是 30ms 對 50ms（左右），這麼一算總時間就是 60ms 對 125ms。
• 這個數字是真的假的，很容易就能感受到，你用滑鼠去飛速點擊，react 的毫無卡頓，但原生的就會卡卡的。
• 最後，這個程序能否代表真實 DOM 操作？並不能。
• 原生肯定不會比 react 慢，比如這裡你可以第一次渲染的時候把列表裡的 DOM 都存起來，以後每次渲染遍歷一遍 DOM，直接設置它們的 innertHTML。在我這裡這麼做只要 20ms。
• 測試里這段代碼著實太惡劣了（見下），生成一段巨大的 HTML，讓瀏覽器去解析，這是可能都算不上 DOM 操作了。這麼做相當於寫一段程序，展示一段數據，你不是留一個介面，直接讓人去改內存，而是把數據硬編碼在程序里，每次要刷新就重新編譯一遍。
• 哪怕是生成一個 DOM，循環的時候 clone 它，然後讓 container 去 appendChild，都要比這個來得好，基本可以做到 react 那樣不卡（我這裡顯示是 35ms）。（有趣的是這種做法在 profile 的時候性能急劇下降，不知道為什麼）

for (var i = 0; i &< data.length; i++) { var render = template; render = render.replace("{{className}}", ""); render = render.replace("{{label}}", data[i].label); html += render; } container.innerHTML = html;

@kidneyball 的回答挺詳細的了。先理解「虛擬DOM」的概念。

react這個「虛擬DOM」的性能優越不是體現在 初始化第一次創建DOM，而是更加精確更加有效率地操作DOM。

看了一下你給的鏈接，第一次 run 的時候確實是 raw 快，但是如果 run 多次，react 速度還是領先的。樓上意見分析的很透徹了，以下我就簡單說明，供懶人參考

沒有仔細閱讀頁面源代碼，僅僅從現象分析下原因（歡迎大家交流）。

第一次 run 的時候，react 和 raw 都需要插入 dom，react 還要在 virtual dom 里渲染一遍，再 diff 到真實 dom，這就比 raw 花費了更長時間。

而當你第二次運行的時候，raw 就沒有 react 快了，raw 是刪除了所有元素，再添加，而 react 只是把 diff 的元素更新了，react 速度會快。實際測試也符合這個猜想，我本地第二次測試react 花費28ms，raw 花費53ms。

virtual dom還是適合頻繁部分修改 dom 的場景，純插入和刪除可能性能不如 raw。

一個簡單的理解可以認為 virtual dom 就是一個 cache。最壞情況下就是 cache 每次都沒命中，肯定還沒有不加 cache 速度快 。cache 的原理是利用數據的時空局部性原理，將熱數據放到高速存儲區，只有能多次重複利用 cache 時，才能體現 cache 的優勢。（放在這裡就是頻繁部分修改 dom，才能發揮react的優勢）

點贊加關注，乾貨持續分享中

舉個例子，實際的。

富文本編輯器中的粘貼功能，取到字元串的html字元。ctrl v的時候你需要分析這一段html字元串中的節點信息，比如是否格式化，是否重置style樣式，然後再創建節點插入頁面。完成複製。

這一過程中無疑使用dom api完成分析比較快捷。正則錯誤率高還複雜。

測試無論chrome還是ie 原生api的方法都要比虛擬dom慢。比如getTagname getStyle 都是非常消耗性能的 比如獲取前後節點信息 父子節點信息。

這時虛擬dom也就是假的parent child next prev getTags 等方法速度可是原生的很多倍。。尤其複雜關係結構。

我只說這一個例子。。手機打的 別見怪。。。方法寫的不全。

個人覺得這種快應該這樣理解：

在傳統的jquery開發中，大家都很隨意，大多數程序員都不會全面考慮dom操作慢的問題的，由於種種原因，寫出各種混亂的直接操作dom的代碼，這肯定會造成最終產生的應用變得比較慢。

而react對dom操作做了一層優化，逼迫開發者按照他的方式去做界面操作，以便react做集中的優化處理，這樣做出來的應用，很可能就比較快。