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

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

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

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

即使一些基準測試基于同一個應用程序?qū)Σ煌目蚣苓M行了比較，也很難獲得真實的結果，因為這種基準測試受限于被測試的應用程序（比如待辦事項應用程序）。

每一個框架都假裝自己為開發(fā)者提供了解決方案，但每一個又都不一樣。它們每一個都聲稱可以為應用程序提供最好的前景，但關于哪一個真正名副其實的爭論又不絕于耳。每一個框架都要求你遵循特定的規(guī)則，它們之間可能有相似之處，但要從一個框架轉換到另一個框架總是很難。

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

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

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

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

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

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

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

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

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

• 如果你想要以下這些東西，就不得不強制進行升級：

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

  2) 想要修復一個 bug；

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

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

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

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

• 技能零散化。很多開發(fā)人員要么不太了解底層 API（因為他們總是使用框架提供的東西），要么活在過去（只知道過時的知識，不知道最新的改進和功能）?！肮ぞ叻▌t”常常導致過度設計，為簡單的問題構建復雜的解決方案，而構建簡單解決方案的知識逐漸零散化。在指南的指導下，我們失去了（或者沒有獲得）好的軟件設計（原則、模式）文化，并失去（或者沒有獲得）構建重要工程的經(jīng)驗。就像 CSS 框架（Bootstrap、Tailwind 等）的用戶缺乏 CSS 技能一樣，Web 框架的用戶也注定缺乏現(xiàn)代 Web API 和軟件設計經(jīng)驗。

一旦你把錢放入框架，就很難把它拿出來。

除了必須支付“稅”費來獲得框架的好處之外，如果框架沒有標準化，它們還會帶來另一個問題。

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

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

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

當然，在項目剛開始時，你可以選擇最流行的框架。對于一個短期的項目來說，這可能是可以接受的，但對于長期項目來說則不然。

框架來來去去。從 2018 年開始，每年都有 1 到 3 個新框架取代舊框架。

不過，標準框架并不存在孤井。在 Web 平臺（即瀏覽器框架）上，使用標準 Web API 可以降低你的投入風險，因為它們可以在大多數(shù)瀏覽器上運行。即使不是所有的瀏覽器都支持，仍然可以通過 polyfill 來彌補。

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

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

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

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

• 是應用程序特有的：任何應用程序最終都會設計自己的“業(yè)務”框架。

• 成為標準，例如，Web 平臺就是一個標準的 Web 框架，而 Web 組件框架（lit、stencil、skatejs 等）最終構建的組件都符合這個標準。

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

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

簡單地說，避免使用框架來構建應用程序的目標是：

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

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

• 只在需要時進行最細粒度的操作（例如，不依賴框架的刷新周期），并減少依賴項，只使用一些必需的輕量級庫，以此來最大化性能。

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

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

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

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

要評估在不使用框架的情況下構建應用程序的難度，我們要明白：它不像構建框架那么困難，因為以下這些不是我們的目標：

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

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

• 構建一個奇特的模板語法（JSX、Angular HTML 等）；

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

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

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

那么，我們該如何設計和實現(xiàn)一個普通的應用程序？因為大多數(shù)應用程序都是使用框架構建的，所以如果沒有這些熟悉的工具，確實很難設計出一種方法來實現(xiàn)類似的結果。你必須：

• 改變你的想法：不要使用特定于框架的服務。對于一個普通的應用程序來說，你可能不需要這些服務。不需要變更檢測，直接更新 DOM 即可……

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

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

接下來，讓我們來看看一些常見的“解法”。

標準 API 屬于“好的框架”，因為它們：

• 具備可移植性：它們在任何地方都可用，如果不可用，可以通過 polyfill 的方式實現(xiàn)。

• 具備互操作性：它們可以與其他標準交互，并被用在專有代碼中。

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

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

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

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

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

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

• 需要學習它們的語法。不過，你可以循序漸進地學習超集編程語言，因為你的代碼的某些部分可以繼續(xù)使用傳統(tǒng) JS。

• 對于非超集編程語言來說，離散化技能確實是一個風險。因為它們的編譯具有普適性，可能不是最優(yōu)的，而你可能沒有意識到這一點。也許你可以使用更簡單和高效的 JS 代碼來完成同樣的操作。

• 需要對缺點做出妥協(xié)，因為我們無法改變轉譯成 JS（或者使用 tsconfig.json 做一點定制）或編譯成 WebAssembly 的過程。有些語言可能還會忽略 JS 的一些概念。

• 具備可移植性，因為通常代碼可以轉譯到 ES5（但有時你不得不妥協(xié)，即使你想要轉譯到 ES6）。WebAssembly 很新，所有現(xiàn)代瀏覽器都支持它。

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

在一個普通的應用程序中，我們要小心謹慎地使用非超集語言，因為它們或多或少都隱含了一些約束。超集語言（TypeScript、Flow）通過避免“要么全有要么全無”來最小化這些約束，我們應該在它們可以帶來價值的地方使用它們。

需要注意的是，在 JavaScript 之上構建的語言層意味著我們的工具鏈中又增加了一層復雜性，可能會因為某些原因招致失?。ㄒ娤挛模４送?，在經(jīng)過編譯或轉譯之后，開發(fā)階段的好處也會消失（通常在運行時不會強制執(zhí)行類型或可見性約束檢查）。

基于不“重寫框架”的假設，就會得出普通的 JS 應用程序不應該使用開發(fā)庫的結論。這是完全錯誤的。“重新發(fā)明輪子”，即從頭開始重寫一切，并不是一個明智的目標。我們的目標是消除框架（而不是開發(fā)庫）中隱含的約束，請不要將其與“自己編寫一切”的教條混淆在一起。

因此，如果你自己不能編寫某些代碼（可能是因為沒有時間，或者因為需要太多的專業(yè)知識），使用開發(fā)庫并沒有什么錯。你只需要關心：

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

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

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

需要注意的是，不要被那些聲稱它們不是框架的文檔或文章所迷惑（因為它們“沒有被明確定義”成框架，或者沒有定義一個“完整的應用程序”）：只要隱含了約束，它們就是框架。

Holovaty 說，只是應用模式（不使用框架）來構建軟件是不夠的。

模式是眾所周知的東西，不特定于某種開發(fā)過程。它們本身是自我文檔化的，因為它們可以被有經(jīng)驗的開發(fā)人員快速識別出來。

這里僅舉幾個例子：

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

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

• 簡化反應式編程的觀察者模式；

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

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

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

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

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

• “視圖”只是 DOM 元素。你當然可以對它們進行抽象（你也應該這樣做），但最終它們也只是抽象而已。

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

• 在普通應用程序中，“檢測”什么時候需要更新視圖通常是沒有必要的。因為在大多數(shù)情況下，你只知道在一個事件之后需要更新什么，然后你直接執(zhí)行這個命令就可以了。當然，在某些情況下，你可能需要通過反轉依賴和通知觀察者（見下文）來進行一般性的更新。

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

首先，DOM API（如 document.createElement("button")）并不是那么難，而且實際上比任何模板語言都更強大，因為你可以全面訪問這些 API。編寫很長的 HTML 片段可能很乏味，如果它們真的很長，可以將它們拆分成更細粒度的組件。

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

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