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