不用任何框架開發(fā) Web 應(yīng)用程序，可能嗎？

過去流行的是 Angular，然后是 React，現(xiàn)在是 Vue.js……其他的像 Ember、Backbone 或 Knockout 什么的幾乎都快消失了。一些標(biāo)準(zhǔn)，例如 Web Components，則很少被使用。似乎每年都會(huì)發(fā)布一些新框架，比如 Svelte、Aurelia，而且每個(gè)框架在服務(wù)器端都有對(duì)應(yīng)的對(duì)象（開頭那些框架對(duì)應(yīng)的 NestJS、NextJS 或 Nuxt，Svelte 對(duì)應(yīng)的 Sapper，等等）。非 JavaScript Web 框架（如 Django、Spring、Laravel、Rails 等）就更不用說(shuō)了。甚至還有框架之上的框架（Quasar、SolidJS）、為框架生成組件代碼的框架（Stencil、Mitosis），以及 NCDP（無(wú)代碼開發(fā)平臺(tái)，No-Code Development Platform）。

這種多樣性讓想知道哪種技術(shù)值得學(xué)習(xí)的開發(fā)人員和技術(shù)選型決策者感到困惑。

網(wǎng)絡(luò)上經(jīng)常會(huì)出現(xiàn)一些比較這些框架的文章，好像是在幫助我們解開這種困惑。但大多數(shù)作者通常是帶有偏見的，因?yàn)樗麄兛赡堋坝眠^這個(gè)框架”，但“只嘗試了一些其他的框架”。偏見程度較低的作者總是得出“這取決于具體情況”的結(jié)論（取決于性能、工具、支持、社區(qū)等），這實(shí)際上是一種非結(jié)論性的結(jié)論。

即使一些基準(zhǔn)測(cè)試基于同一個(gè)應(yīng)用程序?qū)Σ煌目蚣苓M(jìn)行了比較，也很難獲得真實(shí)的結(jié)果，因?yàn)檫@種基準(zhǔn)測(cè)試受限于被測(cè)試的應(yīng)用程序（比如待辦事項(xiàng)應(yīng)用程序）。

框架看起來(lái)就像是宗教（或者說(shuō)是政治）：每一個(gè)框架都假裝自己為開發(fā)者提供了解決方案，但每一個(gè)又都不一樣。它們每一個(gè)都聲稱可以為應(yīng)用程序提供最好的前景，但關(guān)于哪一個(gè)真正名副其實(shí)的爭(zhēng)論又不絕于耳。每一個(gè)框架都要求你遵循特定的規(guī)則，它們之間可能有相似之處，但要從一個(gè)框架轉(zhuǎn)換到另一個(gè)框架總是很難。

現(xiàn)在，讓我們來(lái)看看框架的“無(wú)神論”方法：不使用框架。

我有超過 25 年的專業(yè)軟件開發(fā)經(jīng)驗(yàn)，除此之外，本文還將以構(gòu)建真實(shí)純 JS Web 應(yīng)用程序（前端和后端）的經(jīng)驗(yàn)為基礎(chǔ)。

實(shí)際上，這個(gè)想法還很新。早在 2017 年，Django Web 框架聯(lián)合創(chuàng)始人 Adrian Holovaty 就談到了他的框架“疲勞”，以及他為什么離開 Django 去構(gòu)建自己的純 JS 項(xiàng)目。

有人可能會(huì)問，為什么會(huì)有人想要在不使用框架的情況下開發(fā) Web 應(yīng)用程序？為什么不在其他人花了數(shù)年時(shí)間和精力的成果的基礎(chǔ)上做開發(fā)？或者是因?yàn)?NIH（Not Invented Here）綜合癥導(dǎo)致人人都想構(gòu)建定制的框架？

開發(fā)人員并不會(huì)比一般人更傾向于自找麻煩，實(shí)際上，他們可能比任何人都懶：他們只會(huì)想寫更少的代碼（這樣他們就可以更少犯錯(cuò)），想要自動(dòng)化（以避免人為錯(cuò)誤）……

但他們又想要敏捷，也就是能夠輕松、快速地解決問題。

雖然“快速”似乎是框架承諾的東西（為你搭建腳手架，并增加可靠性），但它不是免費(fèi)的：它們想讓你簽署合同，同意支付“稅”費(fèi)，并將你的代碼放入“孤井”（“稅和孤井”的說(shuō)法來(lái)自 IBM Carbon 系統(tǒng)設(shè)計(jì)團(tuán)隊(duì)負(fù)責(zé)人 Akira Sudhttps://github.com/carbon-design-system/carbon-web-components#readme）。

使用框架是需要付出成本的：

• 遵循它們的 API 規(guī)則，這樣它們就可以向你提供服務(wù)。這就是框架的工作方式：你的代碼必須遵守某些規(guī)則，包括或多或少的樣板代碼。你每天要想的不是“如何做這件事”，而是“如何讓框架做（或不做）這件事”。如果你規(guī)避了這些約束，風(fēng)險(xiǎn)就由你自己承擔(dān)：如果你通過直接調(diào)用底層 API 來(lái)繞過框架，就不要指望它們能理解你的意圖，也不要指望它們的行為能保持一致。所以，框架會(huì)讓你“專注于業(yè)務(wù)”是一個(gè)虛假的承諾：實(shí)際上，框架的事情你也沒少操心。

• 如果你想要以下這些東西，就不得不強(qiáng)制進(jìn)行升級(jí)：

  1) 想要一個(gè)新功能（即使你不需要所有功能，也必須升級(jí)所有東西）；

  2) 想要修復(fù)一個(gè) bug；

  3) 不想失去框架的支持（隨著新版本的發(fā)布，你的應(yīng)用程序所依賴的版本將會(huì)被棄用）。

• 如果框架出現(xiàn)了 bug，但沒有明確的計(jì)劃修復(fù)日期，這會(huì)讓你感到非常沮喪（可能還會(huì)讓項(xiàng)目面臨風(fēng)險(xiǎn)）。第三方提供的框架庫(kù)（如小部件）或插件也不例外，如果你一直使用舊版本，它們與你的應(yīng)用程序的兼容性會(huì)越來(lái)越差。對(duì)于框架維護(hù)者來(lái)說(shuō)，維護(hù)向后兼容性已經(jīng)成為一件非常麻煩的事情。他們發(fā)現(xiàn)，開發(fā)自動(dòng)升級(jí)代碼的工具（Angular 的 ng-update、React 的原生升級(jí)助手、Facebook 的 jscodesshift 等）會(huì)更有利可圖。

• 需要學(xué)習(xí)如何使用它們（它們能做或不能做什么、它們的概念、API、生態(tài)系統(tǒng)、工具），包括了解在新版本中可能發(fā)生的變化。如果你選擇的是當(dāng)前最流行的框架，這可能會(huì)容易些，但你不可能了解一個(gè)框架的方方面面。此外，炒作也從來(lái)不會(huì)消停：如果你決定在一個(gè)新應(yīng)用程序中使用另一個(gè)框架（或者更糟的是，從一個(gè)框架遷移到另一個(gè)框架），那么你在舊框架上所有的投入都將歸零。這就是為什么很多企業(yè)項(xiàng)目會(huì)缺乏活力，即使每個(gè)項(xiàng)目都可能與前一個(gè)項(xiàng)目不一樣。已故的 David Wheeler 曾經(jīng)說(shuō)過：“保持兼容性意味著有意重復(fù)別人的錯(cuò)誤”。

• 將控制權(quán)委托給框架，這是對(duì)框架缺陷的妥協(xié)：你可能無(wú)法做任何你想做的事（或防止框架做你不希望它們做的事情）或者你也許不能獲得你想要的性能（因?yàn)轭~外的分層、普適性、更大的代碼體積或向后兼容性需求)。

• 技能零散化。很多開發(fā)人員要么不太了解底層 API（因?yàn)樗麄兛偸鞘褂每蚣芴峁┑臇|西），要么活在過去（只知道過時(shí)的知識(shí)，不知道最新的改進(jìn)和功能）?！肮ぞ叻▌t”常常導(dǎo)致過度設(shè)計(jì)，為簡(jiǎn)單的問題構(gòu)建復(fù)雜的解決方案，而構(gòu)建簡(jiǎn)單解決方案的知識(shí)逐漸零散化。在指南的指導(dǎo)下，我們失去了（或者沒有獲得）好的軟件設(shè)計(jì)（原則、模式）文化，并失去（或者沒有獲得）構(gòu)建重要工程的經(jīng)驗(yàn)。就像 CSS 框架（Bootstrap、Tailwind 等）的用戶缺乏 CSS 技能一樣，Web 框架的用戶也注定缺乏現(xiàn)代 Web API 和軟件設(shè)計(jì)經(jīng)驗(yàn)。

一旦你把錢放入框架，就很難把它拿出來(lái)。

除了必須支付“稅”費(fèi)來(lái)獲得框架的好處之外，如果框架沒有標(biāo)準(zhǔn)化，它們還會(huì)帶來(lái)另一個(gè)問題。

因?yàn)樗鼈儚?qiáng)制要求你遵循框架規(guī)則——而且每一條規(guī)則都不一樣——這意味著你的應(yīng)用程序?qū)⑴c一個(gè)專有的生態(tài)系統(tǒng)綁定在一起，也就是用專有 API（及其升級(jí)過程）鎖定你的應(yīng)用程序代碼。這對(duì)于你的項(xiàng)目來(lái)說(shuō)是一個(gè)冒險(xiǎn)的賭注，正如它們所暗示的那樣：

• 沒有可移植性：將代碼遷移到另一個(gè)框架（或者一個(gè)有重大變化的新版本，甚至是不使用框架）將是非常昂貴的，包括可能需要進(jìn)行重新培訓(xùn)的成本；

• 你的代碼與其他框架運(yùn)行時(shí)或你想要使用的其他框架組件庫(kù)沒有互操作性：由于規(guī)則不同，大多數(shù)框架彼此之間很難實(shí)現(xiàn)互操作。

當(dāng)然，在項(xiàng)目剛開始時(shí)，你可以選擇最流行的框架。對(duì)于一個(gè)短期的項(xiàng)目來(lái)說(shuō)，這可能是可以接受的，但對(duì)于長(zhǎng)期項(xiàng)目來(lái)說(shuō)則不然。

框架來(lái)來(lái)去去。從 2018 年開始，每年都有 1 到 3 個(gè)新框架取代舊框架。

不過，標(biāo)準(zhǔn)框架并不存在孤井。在 Web 平臺(tái)（即瀏覽器框架）上，使用標(biāo)準(zhǔn) Web API 可以降低你的投入風(fēng)險(xiǎn)，因?yàn)樗鼈兛梢栽诖蠖鄶?shù)瀏覽器上運(yùn)行。即使不是所有的瀏覽器都支持，仍然可以通過 polyfill 來(lái)彌補(bǔ)。

例如，現(xiàn)在的 Web 組件既可移植（幾乎可以在所有瀏覽器中使用），又可互操作（可以被任何代碼使用，包括專有框架），因?yàn)樗鼈兛梢员环庋b成任意的 HTML 元素。不僅具備更好的性能，它們的運(yùn)行時(shí)（自定義元素、陰影 DOM、HTML 模板）還作為瀏覽器的一部分運(yùn)行，所以它們已經(jīng)在那里（不需要下載），并且是原生的。

很少會(huì)有開發(fā)者試圖逃離框架孤井。

如果是為實(shí)現(xiàn)應(yīng)用程序邏輯而創(chuàng)建自己的框架，那就不能說(shuō)框架是不好的：任何應(yīng)用程序都需要實(shí)現(xiàn)自己的業(yè)務(wù)規(guī)則。

如果符合以下這些情況，框架就是好的：

• 是應(yīng)用程序特有的：任何應(yīng)用程序最終都會(huì)設(shè)計(jì)自己的“業(yè)務(wù)”框架。

• 成為標(biāo)準(zhǔn)，例如，Web 平臺(tái)就是一個(gè)標(biāo)準(zhǔn)的 Web 框架，而 Web 組件框架（lit、stencil、skatejs 等）最終構(gòu)建的組件都符合這個(gè)標(biāo)準(zhǔn)。

• 添加一些其他解決方案（包括其他框架）所缺少的獨(dú)特價(jià)值。對(duì)于這種情況，你幾乎沒有選擇，這些附加價(jià)值證明了隱含的鎖定成本是合理的。例如，一個(gè)特定于操作系統(tǒng)的框架遵循了操作系統(tǒng)的標(biāo)準(zhǔn)，除此之外沒有其他方式可以獲得能夠滿足需求的應(yīng)用程序或擴(kuò)展。

• 用于構(gòu)建非關(guān)鍵（短期、低質(zhì)量預(yù)期，并且可以接受“稅費(fèi)”和“孤井”）應(yīng)用程序。例如，使用 Bootstrap 構(gòu)建原型、MVP 或內(nèi)部工具。

簡(jiǎn)單地說(shuō)，避免使用框架來(lái)構(gòu)建應(yīng)用程序的目標(biāo)是：

• 通過避免框架的“一刀切”約束來(lái)最大化靈活性。此外，去掉規(guī)則的約束，提升應(yīng)用程序的創(chuàng)造力。大多數(shù)使用 Bootstrap 開發(fā)的 Web 應(yīng)用程序都屬于此類，因?yàn)樗鼈兒茈y擺脫預(yù)定義組件和樣式，最終將很難從其他角度思考問題。

• 盡量減少對(duì)炒作過度的框架的依賴。不被框架鎖定，才能夠避免可移植性和互操作性方面的問題。

• 只在需要時(shí)進(jìn)行最細(xì)粒度的操作（例如，不依賴框架的刷新周期），并減少依賴項(xiàng)，只使用一些必需的輕量級(jí)庫(kù)，以此來(lái)最大化性能。

當(dāng)然，我們的目標(biāo)也不能是“重新發(fā)明輪子”。我們來(lái)看看該怎么做。

那么，如何在沒有框架的情況下開發(fā)應(yīng)用程序呢？

首先，我們必須明確一個(gè)反目標(biāo)：不要將“不使用框架構(gòu)建應(yīng)用程序”與“取代框架”混淆起來(lái)了?？蚣苁且环N用于托管任意應(yīng)用程序的通用技術(shù)解決方案，所以它們的目標(biāo)并非你的應(yīng)用程序，而是所有的應(yīng)用程序。相反，脫離框架才有可能讓你更專注于你的應(yīng)用程序。

不使用框架開發(fā)應(yīng)用程序并不意味著要重新實(shí)現(xiàn)框架。

要評(píng)估在不使用框架的情況下構(gòu)建應(yīng)用程序的難度，我們要明白：它不像構(gòu)建框架那么困難，因?yàn)橐韵逻@些不是我們的目標(biāo)：

• 構(gòu)建專有的組件模型（實(shí)現(xiàn)特定組件生命周期的容器）；

• 構(gòu)建專有的插件或擴(kuò)展系統(tǒng)；

• 構(gòu)建一個(gè)奇特的模板語(yǔ)法（JSX、Angular HTML 等）；

• 實(shí)現(xiàn)通用的優(yōu)化（變更檢測(cè)、虛擬 DOM）；

• 特定于框架的工具（調(diào)試擴(kuò)展、UI 構(gòu)建器、版本遷移工具）。

因此，構(gòu)建一個(gè)普通的應(yīng)用程序并不是一項(xiàng)艱巨的“重新發(fā)明輪子”的任務(wù)，因?yàn)檫@個(gè)“輪子”主要是關(guān)于 API/ 合約、實(shí)現(xiàn)、通用引擎和相關(guān)的優(yōu)化、調(diào)試能力等。放棄通用目標(biāo)，專注于應(yīng)用程序的目標(biāo)，這意味著你可以擺脫大部分目標(biāo)，而這才是真正的“專注于你的應(yīng)用程序”。

那么，我們?cè)撊绾卧O(shè)計(jì)和實(shí)現(xiàn)一個(gè)普通的應(yīng)用程序？因?yàn)榇蠖鄶?shù)應(yīng)用程序都是使用框架構(gòu)建的，所以如果沒有這些熟悉的工具，確實(shí)很難設(shè)計(jì)出一種方法來(lái)實(shí)現(xiàn)類似的結(jié)果。你必須：

• 改變你的想法：不要使用特定于框架的服務(wù)。對(duì)于一個(gè)普通的應(yīng)用程序來(lái)說(shuō)，你可能不需要這些服務(wù)。不需要變更檢測(cè)，直接更新 DOM 即可……

• 用其他技術(shù)替代方案來(lái)執(zhí)行原先使用框架執(zhí)行的常見任務(wù)（更新 DOM、延遲加載等）。

一些作者，如 Jeremy Likness 或 Chris Ferdinandi（被稱為“JS 極客”）也提到過這個(gè)話題。但是，根據(jù)定義，任何一個(gè)普通的應(yīng)用程序都可以選擇（或不選擇）使用其中的一種技術(shù)，具體視需求而定。例如，MeetSpace 的作者只需要使用標(biāo)準(zhǔn) API 就足以。

接下來(lái)，讓我們來(lái)看看一些常見的“解法”。

標(biāo)準(zhǔn) API 屬于“好的框架”，因?yàn)樗鼈儯?/p>

• 具備可移植性：它們?cè)谌魏蔚胤蕉伎捎?，如果不可用，可以通過 polyfill 的方式實(shí)現(xiàn)。

• 具備互操作性：它們可以與其他標(biāo)準(zhǔn)交互，并被用在專有代碼中。

• 長(zhǎng)期存在：由多個(gè)行業(yè)參與者設(shè)計(jì)，而不只是一個(gè)。它們被設(shè)計(jì)得很好，一旦發(fā)布就會(huì)一直存在，使用它們的風(fēng)險(xiǎn)較小。

• 在大多數(shù)情況下在瀏覽器中都是立即可用的，避免了下載過程。在某些情況下，你可能需要下載 polyfill。但是，與專有框架（注定會(huì)越來(lái)越不流行）不一樣的是，它們的可用性會(huì)越來(lái)越高（逐漸降低下載的必要性）。

在選擇編程語(yǔ)言時(shí)，我們要著重考慮標(biāo)準(zhǔn)。JavaScript 經(jīng)過多年的發(fā)展，現(xiàn)在也包含了在其他編程語(yǔ)言中出現(xiàn)的特性，比如 class 關(guān)鍵字和通過 JSDoc 注釋（如 @type）提供有限的類型檢查支持。

很多編程語(yǔ)言可以被編譯成 JavaScript：TypeScript、CoffeeScript、Elm、Kotlin、Scala.js、Haxe、Dart、Rust、Flow 等。它們都為你的代碼添加了不同的價(jià)值（類型檢查、額外的抽象、語(yǔ)法糖）。普通的應(yīng)用出現(xiàn)應(yīng)該使用它們嗎？為了回答這個(gè)問題，讓我們來(lái)看看它們是否隱含了與框架相同的缺點(diǎn)：

• 遵循語(yǔ)法：大多數(shù)編程語(yǔ)言都強(qiáng)制要求這么做（CoffeeScript、Elm、Kotlin 等）。但需要注意的是，它們是 JavaScript 的超集（TypeScript、Flow），你仍然可以用純 JavaScript 編寫你選擇的某些部分。

• 如果你使用的是非常舊的編程語(yǔ)言（包括 JavaScript）版本，就需要升級(jí)，但升級(jí)頻率比框架低很多。

• 需要學(xué)習(xí)它們的語(yǔ)法。不過，你可以循序漸進(jìn)地學(xué)習(xí)超集編程語(yǔ)言，因?yàn)槟愕拇a的某些部分可以繼續(xù)使用傳統(tǒng) JS。

• 對(duì)于非超集編程語(yǔ)言來(lái)說(shuō)，離散化技能確實(shí)是一個(gè)風(fēng)險(xiǎn)。因?yàn)樗鼈兊木幾g具有普適性，可能不是最優(yōu)的，而你可能沒有意識(shí)到這一點(diǎn)。也許你可以使用更簡(jiǎn)單和高效的 JS 代碼來(lái)完成同樣的操作。

• 需要對(duì)缺點(diǎn)做出妥協(xié)，因?yàn)槲覀儫o(wú)法改變轉(zhuǎn)譯成 JS（或者使用 tsconfig.json 做一點(diǎn)定制）或編譯成 WebAssembly 的過程。有些語(yǔ)言可能還會(huì)忽略 JS 的一些概念。

• 具備可移植性，因?yàn)橥ǔ４a可以轉(zhuǎn)譯到 ES5（但有時(shí)你不得不妥協(xié)，即使你想要轉(zhuǎn)譯到 ES6）。WebAssembly 很新，所有現(xiàn)代瀏覽器都支持它。

• 提供與其他 JS 代碼的互操作性。例如，Typescript 可以被配置為支持 JS。

在一個(gè)普通的應(yīng)用程序中，我們要小心謹(jǐn)慎地使用非超集語(yǔ)言，因?yàn)樗鼈兓蚨嗷蛏俣茧[含了一些約束。超集語(yǔ)言（TypeScript、Flow）通過避免“要么全有要么全無(wú)”來(lái)最小化這些約束，我們應(yīng)該在它們可以帶來(lái)價(jià)值的地方使用它們。

需要注意的是，在 JavaScript 之上構(gòu)建的語(yǔ)言層意味著我們的工具鏈中又增加了一層復(fù)雜性，可能會(huì)因?yàn)槟承┰蛘兄率。ㄒ娤挛模４送?，在?jīng)過編譯或轉(zhuǎn)譯之后，開發(fā)階段的好處也會(huì)消失（通常在運(yùn)行時(shí)不會(huì)強(qiáng)制執(zhí)行類型或可見性約束檢查）。

基于不“重寫框架”的假設(shè)，就會(huì)得出普通的 JS 應(yīng)用程序不應(yīng)該使用開發(fā)庫(kù)的結(jié)論。這是完全錯(cuò)誤的?！爸匦掳l(fā)明輪子”，即從頭開始重寫一切，并不是一個(gè)明智的目標(biāo)。我們的目標(biāo)是消除框架（而不是開發(fā)庫(kù)）中隱含的約束，請(qǐng)不要將其與“自己編寫一切”的教條混淆在一起。

因此，如果你自己不能編寫某些代碼（可能是因?yàn)闆]有時(shí)間，或者因?yàn)樾枰嗟膶I(yè)知識(shí)），使用開發(fā)庫(kù)并沒有什么錯(cuò)。你只需要關(guān)心：

• 模塊化：如果你只需要一小部分功能，就要避免依賴整個(gè)大開發(fā)庫(kù)；

• 避免冗余：在沒有標(biāo)準(zhǔn)的情況下才使用開發(fā)庫(kù)，并優(yōu)先選擇實(shí)現(xiàn)了標(biāo)準(zhǔn)的開發(fā)庫(kù)；

• 避免鎖定：不要直接使用開發(fā)庫(kù)的 API，而是把它們包裝在應(yīng)用程序 API 中。

需要注意的是，不要被那些聲稱它們不是框架的文檔或文章所迷惑（因?yàn)樗鼈儭皼]有被明確定義”成框架，或者沒有定義一個(gè)“完整的應(yīng)用程序”）：只要隱含了約束，它們就是框架。

Holovaty 說(shuō)，只是應(yīng)用模式（不使用框架）來(lái)構(gòu)建軟件是不夠的。

模式是眾所周知的東西，不特定于某種開發(fā)過程。它們本身是自我文檔化的，因?yàn)樗鼈兛梢员挥薪?jīng)驗(yàn)的開發(fā)人員快速識(shí)別出來(lái)。

這里僅舉幾個(gè)例子：

• 模型、視圖和控制器模式（MVC）；

• 根據(jù)配置創(chuàng)建對(duì)象的工廠模式；

• 簡(jiǎn)化反應(yīng)式編程的觀察者模式；

• 用于遍歷集合的迭代器模式；

• 用于延遲加載、安全檢查的代理模式；

• 用于封裝操作（可能基于上下文被觸發(fā)）的命令模式。

這樣的模式有很多：你可以自由地用它們來(lái)滿足你的需求。如果一個(gè)模式為你的應(yīng)用程序的一個(gè)典型問題提供了典型的解決方案，你一定要用它。更寬泛地說(shuō)，任何符合 SOLID 原則和具有良好內(nèi)聚力的東西都有利于應(yīng)用程序的靈活性和可維護(hù)性。

在面試開發(fā)者時(shí)，當(dāng)被問及在構(gòu)建一個(gè)普通應(yīng)用程序時(shí)他們主要會(huì)擔(dān)心哪些東西時(shí)，他們大多數(shù)會(huì)回答：實(shí)現(xiàn)復(fù)雜的模型變化檢測(cè)和后續(xù)的“視圖”更新。這是典型的“工具法則”效應(yīng)，它會(huì)讓你按照框架的思路思考問題，但實(shí)際上你的一些簡(jiǎn)單的需求根本不需要用到框架：

• “視圖”只是 DOM 元素。你當(dāng)然可以對(duì)它們進(jìn)行抽象（你也應(yīng)該這樣做），但最終它們也只是抽象而已。

• 更新它們只是調(diào)用 viewElement.replaceChild(newContent) 的問題，不需要更新更大范圍的 DOM，也不需要重畫或滾動(dòng)。更新 DOM 的方法有好多種，可以插入文本，也可以操作實(shí)際的 DOM 對(duì)象，只要選一個(gè)適合你的就行了。

• 在普通應(yīng)用程序中，“檢測(cè)”什么時(shí)候需要更新視圖通常是沒有必要的。因?yàn)樵诖蠖鄶?shù)情況下，你只知道在一個(gè)事件之后需要更新什么，然后你直接執(zhí)行這個(gè)命令就可以了。當(dāng)然，在某些情況下，你可能需要通過反轉(zhuǎn)依賴和通知觀察者（見下文）來(lái)進(jìn)行一般性的更新。

開發(fā)人員不希望缺失的另一個(gè)特性是編寫帶有動(dòng)態(tài)部分或監(jiān)聽器的 HTML 片段。

首先，DOM API（如 document.createElement("button")）并不是那么難，而且實(shí)際上比任何模板語(yǔ)言都更強(qiáng)大，因?yàn)槟憧梢匀嬖L問這些 API。編寫很長(zhǎng)的 HTML 片段可能很乏味，如果它們真的很長(zhǎng)，可以將它們拆分成更細(xì)粒度的組件。

不過，將這些元素視為模板確實(shí)可以提高可讀性。那么該如何管理它們呢？這里有多種方法：

• 現(xiàn)在可以在瀏覽器中使用HTML模板了（實(shí)際上從2017年就可以了）。它們提供了構(gòu)建可重用的HTML