1樓：伊撒爾
天哪竟然有這個問題……我來回答一下
首先，將 diff 放到 worker 中，其實很多人做過嘗試，但是他們都沒能寫的出靠譜的 diff 演算法，或者根本就沒有把 diff 放到 worker 裡
有幾個難點：
如何傳遞事件？
雙線程通訊，事件是沒辦法傳遞的，我們怎麼辦？答案在這裡：https://
zhuanlan /p/91
594153
2. diff 演算法和 patch 演算法怎樣拆開？
dom 沒辦法傳遞，導致 snabbdom，inferno 這種常見的演算法都是不好使的，我們怎麼辦？答案在這裡：
最終，結合這兩個坑，我寫了新框架 voe
132yse/voe
除了以上的兩個技術問題，還有乙個原因，就是場景太少了
將業務邏輯（voe 中的 jsx，依賴收集，響應式），diff 演算法，全部放到 worker 中，導致 document 這些 web 物件全都沒辦法用，cookie，fetch 這種也沒法用
所以導致這種框架基本沒有太好的場景，我們很少需要框架級別的計算力不是嗎？
但是有個特殊的場景，就是小程式——主奴架構
通過沙箱隔絕 web 環境，遮蔽 dom 能力，對使用者的絕對的掌控，不然他們用 web 能力
所以 voe 雖然沒有業務價值，但是它卻有原始碼價值
更新：對一些觀點的解釋
fiber 架構和 web worker 是不同但又相似的兩個方向，fiber 很簡單，可以看 fre 的實現
其實除了場景少，還有乙個原因，是因為搞這玩意的都閉源搞壟斷，沒有開源出來
2樓：今無悔
多執行緒diff演算法複雜，還有分割任務，管理執行緒，合併結果，以及worker通訊的消耗。如果是超複雜虛擬dom可能會有一點優勢，但實際運用大部分情況都是簡單結構。
3樓：kerry
不是因為知道有哪些坑而不做，而是工程複雜度很高、不知道投入產出比怎麼樣而沒做。
這麼做的前提是得先實現類似fiber架構的那套東西，在使用者態模擬著做執行緒管理、任務拆分、非同步渲染，等等。
對於目前的主流前端框架開發的戰鬥力來說，複雜度很高，也就react團隊有戰鬥力實現了fiber架構。
不過以後還是有可能的，走到題主說的用web worker平行計算虛擬dom的diff這一步，目測遲早會有人試驗的，就看試驗的結果是在什麼情況下對效能帶來多少收穫了。
進入GPU渲染時代的C4D，對多核多執行緒cpu的需求降低了嗎？
YQ4869 沒有不想扯理論之類的，從工作場景出發的話，就做室內設計目前的情況而言GPU渲染還是很尷尬 R19試用之後感覺只是初步引入了GPU渲染的概念，類似比較高完成度的demo而已，用一下可以，但是用來完整的挑工作流程還是不方便 真正完善支援GPU渲染的渲染器多半是第三方，阿諾德用的人少，OC不...
為什麼用OpenMP平行計算會出現比單執行緒還要慢？該怎樣正確使用OpenMP？
風起花散 我曾經遇到過三種 一種是由於各個執行緒之間有共享的需要寫入的乙個變數，並行的時候發生了衝突。解決方法應該是對共享的變數加鎖。第二種就是上面所說的對於共享的變數加鎖，不過我用的是atomic原子操作測試的，而且迴圈體內就這一條語句，貌似是乙個迴圈裡面就一條相加的語句。這個程式邏輯上根本不是並...
佳能90d拍風景用什麼鏡頭
洋蔥Tiny 新手入坑建議選擇焦段更廣闊的18 135。廣闊的焦段可以幫助你更好地找到自己最感興趣的領域。只有盡可能多嘗試不同的風格，才能清晰知道什麼最適合自己。上路最重要的不是行走，而是方向。 強烈推薦EF S 15 85 70 300，從廣角到長焦，日常生活旅遊妥妥的，畫質用過的人都知道。再加上...