精讀《現代 js 框架存在的根本緣由》

1 引言

深刻思考爲什麼前端須要框架，以及 web components 是否能夠代替前端框架？

原文地址，建議先閱讀原文，或者閱讀概述。

2 概述

如今前端框架很是多了，若是讓咱們回答 「爲何要用前端框架」 這個問題，你以爲是下面這些緣由嗎？

• 組件化。
• 擁有強大的開源社區。
• 擁有大量第三方庫解決大部分問題。
• 擁有大量現成的第三方組件。
• 擁有瀏覽器拓展/工具幫助快速 debug。
• 友好的支持單頁應用。

不，這些都不是根本緣由，最多算前端框架的營銷手段。做者給出的最根本緣由是：

解決 UI 與狀態同步的難題。

做者假設了一個沒有前端框架的項目，就像 Jquery 時代，咱們須要手動同步狀態與 UI。就像下面的代碼：

addAddress(address) {
  // state logic
  const id = String(Dat.now())
  this.state = this.state.concat({ address, id })

  // UI logic
  this.updateHelp()

  const li = document.createElement('li')
  const span = document.createElement('span')
  const del = document.createElement('a')
  span.innerText = address
  del.innerText = 'delete'
  del.setAttribute('data-delete-id', id)

  this.ul.appendChild(li)
  li.appendChild(del)
  li.appendChild(span)
  this.items[id] = li
}

首先更新效率是個問題，最大問題仍是同步問題。試想屢次與服務器交互，在同步過程當中漏執行了一步，會致使以後的 UI 與狀態逐漸脫節。

由於咱們只能一步步同步狀態與 UI，卻沒法保證每一個瞬間 UI 與狀態是徹底同步的，任何一個疏忽都會致使 UI 與狀態脫節，而咱們除了不斷檢查 UI 與數據是否對應，毫無辦法。

因此現代框架最重要的幫助是保持 UI 與狀態的同步。

如何作到

有兩種思路：

1. 組件級重渲染：好比 React，當狀態改版後，映射出改變後的虛擬 DOM，最終改變當前組件映射的真實 DOM，這個過程被稱爲 reconciliation。
2. 監聽修改：好比 Angluar 和 Vue.js，狀態改變直接觸發對應 DOM 節點中 value 值的變化。

這裏稍微說明下，React 雖然是總體渲染，但在虛擬 DOM 做用下，效率不比 observable 低。observable 在值不能完整映射 UI 時，也須要作更大範圍的 rerender。另外，Vue.js 與 Angluar 也早已採用了虛擬 DOM。

這三個框架已經融會貫通，做者提到的兩種思路如今已是一種混合技術了。

那 web components 呢？

你們常常會拿 React, Angluar, Vue.js 與 web components 作比較，可 web components 最大的問題就是，沒有解決 UI 與狀態同步。

web components 只提供了模版語法，自定義標籤解決 html 的問題，並無給出一套狀態與 UI 同步的方法。

因此就算使用 web components，咱們可能還須要一個框架作 UI 同步，好比 Vue.js 或者 stenciljs。

做者還提供了一段簡短的 UI 狀態同步實例，這裏略過。

最後給出了四點總結：

• 現代 js 框架主要在解決 UI 與狀態同步的問題。
• 僅使用原生 js 難以寫出複雜、高效、又容易維護的 UI 代碼。
• Web components 沒有解決這個主要問題。
• 雖然使用虛擬 DOM 庫很容易造一個解決問題的框架，但不建議你真的這麼作！

3 精讀

做者的核心觀點是，現代前端框架主要解決 UI 與狀態同步的問題，這是毫無疑問的，也提到了包括 web components 也依然沒有解決這個問題。

這多是 web 開發最核心的問題了。

最初開發者的精力都在前端標準化上，誕生了一系列解決標準化問題的庫，最有知名度的是 jquery。當前端進入 react 時代後，能夠看到精力從解決標準化到解決 web 規範與實踐的衝突，這個衝突正是做者說的問題。

前端三劍客

問題就出如今 html、js、css 三者分離上。

html、css、js 各是一套獨立的體系，但 js 又能同時控制 html 與 css，那爲了解決同步問題，最好將控制權所有交給 js。

這樣 web components 的問題也就好理解了，web components 解決的是 html 問題，註定與 js 無關。

html 官方規範估計很難出現現代框架的設計了，由於官方設計中前端三劍客是相互分離的方案，爲了解決現階段前端框架的問題，html 必須由 js 徹底接管，這幾乎就是 jsx，或者支持 template 語法的 html，可這與最初網頁設計思路是違背的。

html 是獨立的，甚至能夠不依賴 js 運行，這自然致使了 UI 與狀態同步這個難題。

爲何必定要用 js

html 不依賴 js 的設計可能已經跟不上前端發展步伐了，也許 jsx 或者 template 纔是真正的將來。

誠然，html 如今的設計能夠在不支持 js 的瀏覽器執行，但就在最近，全部現代瀏覽器都支持了 service worker，它是凌駕於 html 執行時機之上的 js 腳本，甚至能夠攔截 html 請求。一個不支持 js 的瀏覽器，可能也沒法支持 service worker，禁用 js 的堅持可能只剩下安全性保護。

而實際上現代 web 頁面都使用了 js 徹底主導網頁渲染，因此這已經從技術問題上升到了社會問題，現在禁用 js 的瀏覽器還有多少網頁能夠正常訪問？除了某些超大型網站對禁用 js 狀態作了特殊優化之外，如今幾乎沒有前端項目會考慮禁用 js 的狀況了，由於咱們不會假設 React、Angluar、Vue.js 框架代碼沒法運行。

因此爲何不融合 html 與 js 呢？

既然事實上 UI 已經與 js 綁定了，那 w3c 爲什麼不將 jsx 或者 template 列爲標準呢？也許爲了向前兼容，規範永遠也邁不出這一步吧。

幸運的是，這並不妨礙現代前端框架的大量普及，並且勢不可擋。

4 總結

也許 UI 與狀態同步的問題是前端發展的最大阻力，雖然現代化框架已經解決了這個問題，但 w3c 標準卻一直沒法往這個方向發力，致使 web 的下一個發展方向難以依靠標準規範來推進。前端突飛猛進的發展，很大一部分是規範的發展帶來的，而如今咱們進入了一個由工業化領導的時代，規範極可能永遠也跟不上來，隨之而來的是工業化社區也難以作進一步突破。

前端不只是 web，或者也許下一個突破並不在 web，而是 ar/vr 或者下一我的機交互場景。一樣，web 也不只是前端三劍客，若是認爲 React、Angluar、Vue.js 帶來的工業化規範就是新的規範，前端纔有動力向後發展，好比基於虛擬 DOM 的新框架、新語言。

因此筆者推導出現代前端開發的本質，是將 js、html 的平行關係變成了 js 包含 html 的關係，正如上面所說，這可能背離了 w3c 的初衷，但這就是如今的潮流。

最後總結一下觀點：

1. 也是原做者的，現代 js 框架主要在解決 UI 與狀態同步的問題。
2. 傳統的前端三劍客正面臨着進一步發展乏力的危機。
3. 現代前端框架正在告訴咱們新的三劍客：js（虛擬 dom、虛擬 css）。

5 更多討論

討論地址是： 精讀《現代 js 框架存在的根本緣由》 · Issue #84 · dt-fe/weekly

若是你想參與討論，請點擊這裏，每週都有新的主題，週末或週一發佈。