為什么 React 源碼不用 TypeScript 來寫？

周末的，看點(diǎn)輕松的把，之前看過 React 的源碼，比較好奇像 React 這樣龐大的工程為什么沒有用 TypeScript。

Facebook 工程師 Cat Chen 在知乎上（https://www.zhihu.com/question/378470381/answer/1079675543）從內(nèi)部的角度解答了為什么現(xiàn)在 React 的源代碼用了 Flow 但沒有用 TypeScript。

Facebook 是一家技術(shù)很厲害的公司，能夠超前做一些外界沒有的東西，但等外界把這個東西做出來了，Facebook 就發(fā)現(xiàn)自己遷移不過去了，被自己過去超前做的技術(shù)鎖定了，因為遷移成本太高。舉個例子，在還沒有 webpack 的時候 Facebook 就有自己很好的前端構(gòu)建流水線，但 webpack 出來后 Facebook 無法遷移到 webpack，甚至無法輕易把 transpiler 遷移到 Babel。

如果我沒記錯的話，Babel 作者 Sebastian McKenzie 進(jìn)入 Facebook 后做過一個項目，就是幫助 Facebook 遷移到 Babel。為什么呢？因為在外界還沒有 Babel 的時候，甚至在 Babel 前身 6to5 還沒出現(xiàn)的時候，Facebook 內(nèi)部的流水線已經(jīng)有自己的 transpiler，能夠把一部分 ES6 語法轉(zhuǎn)譯為 ES5。當(dāng)時我們可爽了，在外部根本還沒意識到能這樣做事情的時候，我們已經(jīng)可以隨手寫 ES6 了。但有了 Babel 后，內(nèi)部流水線根本不兼容中間插入 Babel 這一步，所以就需要專門改造這個流水線才能遷移到 Babel。而且 Facebook 已有的大量代碼的 ES6 寫法是基于內(nèi)部 transpiler 寫的，誰能保證遷移到 Babel 后 100% 兼容？遷移到 Babel 后如果編譯出錯了，那還能找出來修復(fù)。如果不出錯，但實際執(zhí)行結(jié)果略微不一樣，導(dǎo)致出現(xiàn)線上事故，那怎么辦？

React 在寫的時候，是基于上述 Facebook 內(nèi)部流水線寫的，所以自然是內(nèi)部有什么工具就依賴什么工具。React 一開始寫的時候，其實是沒有 Babel、TypeScript 和 Flow 的，但有上述內(nèi)部 transpiler，所以就這樣寫了。到后來有了 Flow，而且要保證依賴于 React 的代碼能夠得到正確的 Flow 類型推斷，自然就加上了 Flow 注釋。此外，內(nèi)部流水線應(yīng)該是從來沒做過 TypeScript 支持的，所以估計就算想用 TypeScript 來寫也做不到，因為這不是加個 webpack 插件就能支持的。

為什么 Facebook 要做 Flow 而不用 TypeScript？這是一個規(guī)模的問題，對于大多數(shù)一般人來說沒有這個規(guī)模是不可能理解的。我可以舉若干個故事來解釋一下什么是規(guī)模，以及為什么大多數(shù)人都沒有機(jī)會解決這類問題，但非常少數(shù)的超大規(guī)模型公司需要請非常資深的工程師來解決。

第一個例子是為什么 Facebook 不能用 TypeScript，因為 TypeScript 會把所有源代碼加載到內(nèi)存里進(jìn)行處理。Facebook 用的是 monorepo，也就是一個單體源代碼庫，不按項目分多個代碼庫，這使得互相引用的 JavaScript 非常龐大。如果讓 TypeScript 直接跑，TypeScript 的內(nèi)存開銷會大到連 Facebook 的服務(wù)器都 hold 不住，然后崩潰掉。為此 Facebook 堅持做自己的 Flow，Flow 能夠分拆要處理的 JavaScript 然后一部分一部分地處理，解決 Facebook 內(nèi)部的獨(dú)家問題。Facebook Flow 團(tuán)隊的態(tài)度很明確：「這是做給我們自己用的，我們順手開源而已，你們愛用就用，沒人逼你們用。我們會優(yōu)先做內(nèi)部需求，社區(qū)需求不著急做，如果社區(qū)需求跟內(nèi)部需求沖突的必然讓路給內(nèi)部需求?！?/p>

第二個例子是為什么 Facebook 用 Mercurial (hg) 而不用 Git，因為 Facebook 幾年前每周的 commit 數(shù)量就高達(dá)五位數(shù)，現(xiàn)在可能已經(jīng)六位數(shù)了。這導(dǎo)致每天上班跑一次 git pull --rebase 搞不好就 30 分鐘，非常影響生產(chǎn)力，而且一天還可能要跑幾次。既然 Git 是開源的，Facebook 就想要去改 Git 源代碼，改善自己工作流程的生產(chǎn)力。Facebook 主動去撩 Git，說「我們愿意貢獻(xiàn)源代碼啊，我們可以優(yōu)化我們在乎的工作流程的性能，你們愿意接受我們的 Pull Request 嗎？」Git 說「滾！這是你們特有的問題，正常的 Git 用戶根本沒有這么高的 commit 流量，不要引入非必要的復(fù)雜度到我們的源代碼里?！褂谑?Facebook 跑去撩 Mercurial，人家說「歡迎來貢獻(xiàn)代碼」，于是 Facebook 就切換到 Mercurial 了。

第三個例子是 Facebook 特有的 iOS 開發(fā)環(huán)境優(yōu)化。跟上面的例子相似，如果當(dāng)作一個普通的 Xcode 項目打開 Facebook 主應(yīng)用的源代碼，編譯一下就 60 分鐘，根本無法干活。所以 Facebook 做了一些非常專門的優(yōu)化，保證大家如果只是改動一兩個模塊里的代碼時，編譯速度非?？?，一下子就能把 Facebook 主應(yīng)用編譯出來，能看到改動的效果。Facebook 跟 Apple 的關(guān)系不錯，就問 Apple 有沒有興趣對 Xcode 做一些相關(guān)的優(yōu)化，Apple 當(dāng)然表示沒興趣。Apple 說他們真正看重的是那些一兩個程序員組成的小開發(fā)者，因為這種類型開發(fā)者寫了絕大部分 App Store 上面的應(yīng)用，包括大部分的高質(zhì)量應(yīng)用。Apple 要優(yōu)先滿足這種類型開發(fā)者的需求，而不是 Facebook 這種「僅此一家」的需求。

舉這三個例子是為了說明這樣一個事情：Facebook 的很多問題是獨(dú)家的，并不是外部看到的那么簡單的問題。有些很多問題是因為規(guī)模導(dǎo)致的，做不到 Facebook 這樣的規(guī)模根本遇不到這樣的問題。你可以想象你自己做項目會怎么做，但你把這應(yīng)用到 Facebook 這樣的規(guī)模就很可能行不通。

??愛心三連擊
1.看到這里了就點(diǎn)個在看支持下吧，你的「點(diǎn)贊，在看」是我創(chuàng)作的動力。
2.關(guān)注公眾號程序員成長指北，回復(fù)「1」加入高級前端交流群！「在這里有好多 前端?開發(fā)者，會討論?前端 Node 知識，互相學(xué)習(xí)」！
3.也可添加微信【ikoala520】，一起成長。
“在看轉(zhuǎn)發(fā)”是最大的支持