如何逃離框架孤井？

前言

前面我發過一篇文章，脫離了Spring詢問大家能不能繼續開發，結果文章下麵的評論和回覆都告訴我大家伙的基礎打得很牢固，該咋寫還是咋寫。看得我在這內捲的時代瞬間躺平。

那麼今天挑戰升級，不用任何框架開發 Web 應用程式，你能做到麽？

首先，我們要思考一個問題：

不使用框架等同於重覆造輪子嗎？

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

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

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

即使一些基準測試基於同一個應用程式對不同的框架進行了比較，也很難獲得真實的結果，因為這種基準測試受限於被測試的應用程式（比如待辦事項應用程式）。

框架看起來就像是宗教（或者說是政治）：每一個框架都假裝自己為開發者提供瞭解決方案，但每一個又都不一樣。它們每一個都聲稱可以為應用程式提供最好的前景，但關於哪一個真正名副其實的爭論又不絕於耳。每一個框架都要求你遵循特定的規則，它們之間可能有相似之處，但要從一個框架轉換到另一個框架總是很難。所以沒有什麼一說：Angular天下第一；Vue是天。ヾ(=･ω･=)o

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

為什麼不使用框架？

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

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

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

能擺誰不擺呢？

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

雖然“快速”似乎是框架承諾的東西（為你搭建腳手架，並增加可靠性），但它不是免費的：它們想讓你簽署合同，同意支付“稅”費，並將你的代碼放入“孤井”（“稅和孤井”的說法來自 IBM Carbon 系統設計團隊負責人 Akira Sud）。

框架稅

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

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

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

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

  2. 想要修複一個 bug；

  3. 不想失去框架的支持（隨著新版本的發佈，你的應用程式所依賴的版本將會被棄用）。

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

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

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

• 技能零散化。很多開發人員要麼不太瞭解底層 API（因為他們總是使用框架提供的東西），要麼活在過去（只知道過時的知識，不知道最新的改進和功能）。“工具法則”常常導致過度設計，為簡單的問題構建複雜的解決方案，而構建簡單解決方案的知識逐漸零散化。在指南的指導下，我們失去了（或者沒有獲得）好的軟體設計（原則、模式）文化，並失去（或者沒有獲得）構建重要工程的經驗。就像 CSS 框架（Bootstrap、Tailwind 等）的用戶缺乏 CSS 技能一樣，Web 框架的用戶也註定缺乏現代 Web API 和軟體設計經驗。

一旦你把錢放入框架，就很難把它拿出來。要麼砸碎他，當然可能最好的方法就是一開始就不塞進去。

框架孤井

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

因為它們強制要求你遵循框架規則——而且每一條規則都不一樣——這意味著你的應用程式將與一個專有的生態系統綁定在一起，也就是用專有 API（及其升級過程）鎖定你的應用程式代碼。這對於你的項目來說是一個冒險的賭註，正如它們所暗示的那樣：

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

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

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

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

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

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

但很少會有開發者試圖逃離框架孤井。

那麼框架本質上就是不好的嗎？

如果是為實現應用程式邏輯而創建自己的框架，那就不能說框架是不好的：任何應用程式都需要實現自己的業務規則。

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

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

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

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

• 用於構建非關鍵（短期、低質量預期，並且可以接受“稅費”和“孤井”）應用程式。例如，使用 Bootstrap 構建原型、MVP 或內部工具。

去框架化的目標

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

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

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

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

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

框架之外的選擇

那麼，如何在沒有框架的情況下開發應用程式呢？

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

不使用框架開發應用程式並不意味著要重新實現框架。

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

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

• 構建專有的插件或擴展系統；

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

• 實現通用的優化（變更檢測、虛擬 DOM）；

• 特定於框架的工具（調試擴展、UI 構建器、版本遷移工具）。

因此，構建一個普通的應用程式並不是一項艱巨的“重新發明輪子”的任務，因為這個“輪子”主要是關於 API/ 合約、實現、通用引擎和相關的優化、調試能力等。放棄通用目標，專註於應用程式的目標，這意味著你可以擺脫大部分目標，而這才是真正的“專註於你的應用程式”。

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

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

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

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

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

標準

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

需要註意的是，在 JavaScript 之上構建的語言層意味著我們的工具鏈中又增加了一層複雜性，可能會因為某些原因招致失敗（見下文）。此外，在經過編譯或轉譯之後，開發階段的好處也會消失（通常在運行時不會強制執行類型或可見性約束檢查）。

開發庫

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

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

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

• 避免冗餘：在沒有標準的情況下才使用開發庫，並優先選擇實現了標準的開發庫；

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

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

模式

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

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

這裡僅舉幾個例子：

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

• 根據配置創建對象的工廠模式；

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

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

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

• 用於封裝操作（可能基於上下文被觸發）的命令模式。

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

更新視圖

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

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

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

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

模板

開發人員不希望缺失的另一個特性是編寫帶有動態部分或監聽器的 HTML 片段。

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

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

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