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 與狀況的同步。
怎樣做到
有兩種思緒：
- 組件級重襯着：比方 React，當狀況改版后，映照出轉變后的假造 DOM，終究轉變當前組件映照的實在 DOM，這個歷程被稱為 reconciliation。
- 監聽修正：比方 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 的初志，但這就是現在的潮水。
末了總結一下看法：
- 也是原作者的，當代 js 框架重要在處理 UI 與狀況同步的題目。
- 傳統的前端三劍客正面臨着進一步生長乏力的危急。
- 當代前端框架正在通知我們新的三劍客：js（假造 dom、假造 css）。
5 更多議論
假如你想介入議論，請點擊這裏，每周都有新的主題，周末或周一宣布。
