最簡(jiǎn)單的應(yīng)對(duì)方法是對(duì)用戶的任何輸入都進(jìn)行轉(zhuǎn)義（Escape）。然而這也帶來(lái)了其他麻煩，如果對(duì)字符串進(jìn)行多次轉(zhuǎn)義，那么反轉(zhuǎn)義的次數(shù)也必須是相同的，否則會(huì)無(wú)法得到原內(nèi)容。如果又不小心把 HTML 標(biāo)簽（Markup）給轉(zhuǎn)義了，那么 HTML 標(biāo)簽會(huì)直接顯示給用戶，從而導(dǎo)致很差的用戶體驗(yàn)。
XHP 時(shí)代 - 2010
到了 2010 年，為了更加高效的編碼，同時(shí)也避免轉(zhuǎn)義 HTML 標(biāo)簽的錯(cuò)誤，F(xiàn)acebook 開(kāi)發(fā)了 XHP 。XHP 是對(duì) PHP 的語(yǔ)法拓展，它允許開(kāi)發(fā)者直接在 PHP 中使用 HTML 標(biāo)簽，而不再使用字符串。
$content =
;
foreach ($talks as $talk) {
$content->appendChild(
{$talk->name}
);
}
這樣的話，所有的 HTML 標(biāo)簽都使用不同于 PHP 的語(yǔ)法，我們可以輕易的分辨哪些需要轉(zhuǎn)義哪些不需要轉(zhuǎn)義。
不久的后來(lái)，F(xiàn)acebook 的工程師又發(fā)現(xiàn)他們還可以創(chuàng)建自定義標(biāo)簽，而且通過(guò)組合自定義標(biāo)簽有助于構(gòu)建大型應(yīng)用。 而這恰恰是 Semantic Web 和 Web Components 概念的一種實(shí)現(xiàn)方式。
$content = ;
foreach ($talks as $talk) {
$content->appendChild();
}
之后，F(xiàn)acebook 在 JS 中嘗試了更多的新技術(shù)方式以減小客戶端和服務(wù)端之間的延時(shí)。比如跨瀏覽器 DOM 庫(kù)和數(shù)據(jù)綁定，但是都不是很理想。
既然還原狀態(tài)行不通，那就換一種方式繞過(guò)去。 對(duì)于沒(méi)有改變的 DOM 節(jié)點(diǎn)，讓它保持原樣不動(dòng)，僅僅創(chuàng)建并替換變更過(guò)的 DOM 節(jié)點(diǎn)。 這種方式實(shí)現(xiàn)了 DOM 節(jié)點(diǎn)復(fù)用（Reuse）。
至此，只要能夠識(shí)別出哪些節(jié)點(diǎn)改變了，那么就可以實(shí)現(xiàn)對(duì) DOM 的更新。于是問(wèn)題就轉(zhuǎn)化為如何比對(duì)兩個(gè) DOM 的差異。
而這正是 React 所需要的，只不過(guò)它的處理對(duì)象是 DOM 而不是文本文件。 難怪有人說(shuō)：“I tend to think of React as Version Control for the DOM” 。
DOM 是樹(shù)形結(jié)構(gòu)，所以 diff 算法必須是針對(duì)樹(shù)形結(jié)構(gòu)的。目前已知的完整樹(shù)形結(jié)構(gòu) diff 算法復(fù)雜度為 O(n^3) 。
假如頁(yè)面中有 10,000 個(gè) DOM 節(jié)點(diǎn)，這個(gè)數(shù)字看起來(lái)很龐大，但其實(shí)并不是不可想象。為了計(jì)算該復(fù)雜度的數(shù)量級(jí)大小，我們還假設(shè)在一個(gè) CPU 周期我們可以完成單次對(duì)比操作（雖然不可能完成），且 CPU 主頻為 1 GHz 。這種情況下，diff 要花費(fèi)的時(shí)間如下：
如果再加上元素的屬性呢？比如 value ，如果前后兩次標(biāo)簽名稱和 value 屬性都相同，那么就認(rèn)為元素匹配中，無(wú)須改動(dòng)。但現(xiàn)實(shí)是這行不通，因?yàn)橛脩糨斎霑r(shí)值總是在變，會(huì)導(dǎo)致元素一直被替換，導(dǎo)致失去焦點(diǎn)；；更糟糕的是，并不是所有 HTML 元素都有這個(gè)屬性。
那使用所有元素都有的 id 屬性呢？這是可以的，如上圖，我們可以容易的識(shí)別出前后 DOM 的差異。考慮表單情況，表單模型的輸入通常跟 id 關(guān)聯(lián)，但如果使用 AJAX 來(lái)提交表單的話，我們通常不會(huì)給 input 設(shè)置 id 屬性。因此，更好的辦法是引入一個(gè)新的屬性名稱，專門(mén)用來(lái)輔助 diff 算法。這個(gè)屬性最終確定為 key 。這也是為什么在 React 中使用列表時(shí)會(huì)要求給子元素設(shè)置 key 屬性的原因。
// Chrome v63
const div = document.createElement("div");
let m = 0;
for (let k in div) {
m++;
}
console.log(m); // 231
之所以有這么多屬性，是因?yàn)?DOM 節(jié)點(diǎn)被用于瀏覽器渲染管道的很多過(guò)程中。 瀏覽器首先根據(jù) CSS 規(guī)則查找匹配的節(jié)點(diǎn)，這個(gè)過(guò)程會(huì)緩存很多元信息，例如它維護(hù)著一個(gè)對(duì)應(yīng) DOM 節(jié)點(diǎn)的 id 映射表。 然后，根據(jù)樣式計(jì)算節(jié)點(diǎn)布局，這里又會(huì)緩存位置和屏幕定位信息，以及其他很多的元信息，瀏覽器會(huì)盡量避免重新計(jì)算布局，所以這些數(shù)據(jù)都會(huì)被緩存。 可以看出，整個(gè)渲染過(guò)程會(huì)耗費(fèi)大量的內(nèi)存和 CPU 資源。
現(xiàn)在回過(guò)頭來(lái)想想 React ，其實(shí)它只在 diff 算法中用到了 DOM 節(jié)點(diǎn)，而且只用到了標(biāo)簽名稱和部分屬性。 如果用更輕量級(jí)的 JS 對(duì)象來(lái)代替復(fù)雜的 DOM 節(jié)點(diǎn)，然后把對(duì) DOM 的 diff 操作轉(zhuǎn)移到 JS 對(duì)象，就可以避免大量對(duì) DOM 的查詢操作。這種方式稱為 Virtual DOM 。
其過(guò)程如下：
維護(hù)一個(gè)使用 JS 對(duì)象表示的 Virtual DOM，與真實(shí) DOM 一一對(duì)應(yīng)
對(duì)前后兩個(gè) Virtual DOM 做 diff ，生成變更（Mutation）
把變更應(yīng)用于真實(shí) DOM，生成最新的真實(shí) DOM
可以看出，因?yàn)橐炎兏鼞?yīng)用到真實(shí) DOM 上，所以還是避免不了要直接操作 DOM ，但是 React 的 diff 算法會(huì)把 DOM 改動(dòng)次數(shù)降到最低。
著名瀏覽器廠商 Opera 把重排和重繪（Reflow and Repaint）列為影響頁(yè)面性能的三大原因之一。
我們說(shuō) DOM 是很慢的，除了前面說(shuō)到的它的復(fù)雜和龐大，還有另一個(gè)原因就是重排和重繪。
當(dāng) DOM 被修改后，瀏覽器必須更新元素的位置和真實(shí)像素； 當(dāng)嘗試從 DOM 讀取屬性時(shí)，為了保證讀取的值是正確的，瀏覽器也會(huì)觸發(fā)重排和重繪。 因此，反復(fù)的“讀取、修改、讀取、修改...”操作，將會(huì)觸發(fā)大量的重排和重繪。
另外，由于瀏覽器本身對(duì) DOM 操作進(jìn)行了優(yōu)化，比如把兩次很近的“修改”操作合并成一個(gè)“修改”操作。 所以如果把“讀取、修改、讀取、修改...”重新排列為“讀取、讀取...”和“修改、修改...”，會(huì)有助于減小重排和重繪的次數(shù)。但是這種刻意的、手動(dòng)的級(jí)聯(lián)寫(xiě)法是不安全的。
對(duì)此，David Nolen 提出了基于不可變數(shù)據(jù)結(jié)構(gòu)（Immutable Data Structure）的解決方案。 該方案的靈感來(lái)自于 ClojureScript ，在 ClojureScript 中，大部分的值都是不可變的。換句話說(shuō)就是，當(dāng)需要更新一個(gè)值時(shí)，程序不是去修改原來(lái)的值，而是基于原來(lái)的值創(chuàng)建一個(gè)新值，然后使用新值進(jìn)行賦值。
David 使用 ClojureScript 寫(xiě)了一個(gè)針對(duì) React 的不可變數(shù)據(jù)結(jié)構(gòu)方案：Om ，為 shouldComponentUpdate 提供了默認(rèn)實(shí)現(xiàn)。
不過(guò)，由于不可變數(shù)據(jù)結(jié)構(gòu)并未被 Web 工程師廣為接受，所以當(dāng)時(shí)并未把這項(xiàng)功能合并進(jìn) React 。 遺憾的是，截止到目前，shouldComponentUpdate 也仍然未提供默認(rèn)實(shí)現(xiàn)。 但是 David 卻為廣大開(kāi)發(fā)者開(kāi)啟了一個(gè)很好的研究方向。
