策劃 | 蔡芳芳
作者 | Jér me Beau
譯者 | 明知山
不使用架構等同于重複造輪子嗎？
本文經原文作者授權、由 InfoQ 翻譯并分享，轉載請注明作者、譯者資訊和出處。
過去流行的是 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）。
這種多樣性讓想知道哪種技術值得學習的開發人員和技術選型決策者感到困惑。
網絡上經常會出現一些比較這些架構的文章，好像是在幫助我們解開這種困惑。但大多數作者通常是帶有偏見的，因為他們可能“用過這個架構”，但“隻嘗試了一些其他的架構”。偏見程度較低的作者總是得出“這取決于具體情況”的結論（取決于性能、工具、支援、社群等），這實際上是一種非結論性的結論。
即使一些基準測試基于同一個應用程式對不同的架構進行了比較，也很難獲得真實的結果，因為這種基準測試受限于被測試的應用程式（比如待辦事項應用程式）。
架構看起來就像是宗教（或者說是政治）：每一個架構都假裝自己為開發者提供了解決方案，但每一個又都不一樣。它們每一個都聲稱可以為應用程式提供最好的前景，但關于哪一個真正名副其實的争論又不絕于耳。每一個架構都要求你遵循特定的規則，它們之間可能有相似之處，但要從一個架構轉換到另一個架構總是很難。
現在，讓我們來看看架構的“無神論”方法：不使用架構。
從哪裡講起？
我有超過 25 年的專業軟體開發經驗，除此之外，本文還将以建構真實純 JS Web 應用程式（前端和後端）的經驗為基礎。
為什麼不使用架構？
實際上，這個想法還很新。早在 2017 年，Django Web 架構聯合創始人 Adrian Holovaty 就談到了他的架構“疲勞”，以及他為什麼離開 Django 去建構自己的純 JS 項目。
有人可能會問，為什麼會有人想要在不使用架構的情況下開發 Web 應用程式？為什麼不在其他人花了數年時間和精力的成果的基礎上做開發？或者是因為 NIH（Not Invented Here）綜合症導緻人人都想建構定制的架構？
開發人員并不會比一般人更傾向于自找麻煩，實際上，他們可能比任何人都懶：他們隻會想寫更少的代碼（這樣他們就可以更少犯錯），想要自動化（以避免人為錯誤）……
但他們又想要靈活，也就是能夠輕松、快速地解決問題。
雖然“快速”似乎是架構承諾的東西（為你搭建腳手架，并增加可靠性），但它不是免費的：它們想讓你簽署合同，同意支付“稅”費，并将你的代碼放入“孤井”（“稅和孤井”的說法來自 IBM Carbon 系統設計團隊負責人 Akira Sudhttps://github.com/carbon-design-system/carbon-web-components#readme）。
架構稅
使用架構是需要付出成本的：
遵循它們的 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 片段的能力。這實際上是Web元件的一部分。
JavaScript從ES6(2015)開始支援模闆字面量，你可以很輕松地将值嵌入到字元串中。你可以嵌入原始類型（數字、字元串，包括其他HTML代碼等），但不能嵌入更複雜的元素，例如注冊了監聽器的DOM元素。
我們可以借助标記模闆字面量函數将複雜的值（如DOM節點）嵌入到模闆中。ObservableHQ已經設計了一個非常友善的工具，可以用它編寫html`$這樣的代碼，或者實作更複雜的模闆，比如html`$}。
模闆中的條件或循環語句該怎麼辦？且不說這可能從來都不是一個好主意（UI 中不應該包含邏輯），你可以（也應該）隻用 JS 來實作邏輯，然後使用上面的技術将結果插入到模闆中。
事件
現在，我們有了基本的模闆，那麼該如何将事件綁定到 DOM 節點呢？這裡也有幾種選擇：
HTML事件處理器代碼（）可以被插入到HTML源代碼中，但這并非最好的辦法，因為指定的處理器隻在指定的範圍内可用。
事件處理器API（button.addEventListener("click", myClickHandler)）可用于所有通過DOM API或HTML标記模闆字面量函數建立的節點。
那麼定制或業務事件該怎麼辦？如果我需要對應用程式的某個元件觸發的一些事件作出反應該怎麼辦？這裡也有多種處理方式：
自定義事件：你可以通過擴充 EventTarget 來建立自己的事件類，并派發或監聽它們，就像“标準”事件一樣。
理論上說，使用 EventEmitter 也是一種辦法（存在于 Node 中，在浏覽器中作為庫存在），但它很少被使用。
觀察者模式：你可以建構自己的觀察者，也可以考慮使用 RxJs，它是這方面的标準。你隻需要建構一個 Subject，并在發生事件時通知所有訂閱者，讓訂閱者對事件做出反應。
元件
雖說開發普通的應用程式不同于開發複雜的基礎設施（也就是用于托管元件的容器），但如果一些東西在系統中會多次出現，那麼将它們設計成可重用元件（與上下文無關）仍然是一個好主意。無論你使用何種技術，也無論是業務還是技術，一定程度粒度的抽象仍然是有用的：将與同一業務概念相關的資料和規則封裝成一個可重用的對象，或者建構可以在應用程式多個地方進行執行個體化的小部件，總歸是個好主意。
建立元件的方法有很多，具體視自己的需求而定。早在 2017 年，Mev-Rael 就提出了很多技巧，用于處理 JavaScript 元件的狀态、自定義屬性和視圖。當然，我們不要拘囿于别人推薦的技術，而是要先考慮自己的需求，然後再選擇合适的技術。
除了标準的小部件元件（通常是标準的 Web 元件），任何一個元件都應該能夠：
将邏輯和視圖拆分開（通常會使用 MVC 模式）。把它們混合在一起通常會導緻代碼不易于維護，還會降低靈活性（例如，如果你想同時以詳情或表格的形式顯示一條記錄，你的 RecordComponent 隻需要使用 DetailRecordView 或 RowRecordView）。
參數化元件的行為或視圖。
通過觸發事件的形式通知訂閱者元件中發生了某些事件（通常是在發生使用者互動之後）。
同步：如果發生一些事件，元件應該能夠進行重繪。這個使用反應式開發庫（如 RxJS）可以很容易實作。
在任何情況下，無論你選擇了什麼樣的設計政策，你的元件（或者更具體地說，它的相關“視圖”）都必須能夠提供一些 HTML 渲染結果。你可以使用包含 HTML 代碼的字元串，但 HTMLElement（或 Element）通常是更好的選擇（可讀性高，直接更新，可以綁定事件處理器），而且性能更好（不需要解析）。
此外，你可能希望使用來自第三方的外部元件。由于專有架構的流行程度較高，它們可以更大程度地利用社群開發的庫群組。它們中的大多數實際上與純 JS 實作的特性（比如 JQuery）并沒有太大不同，但問題是，它們缺乏互操作性，是以到最後你會發現自己需要的其實是純 JS 或 Web 元件。
所幸的是，這樣的庫确實存在，比如 Vanilla JS Toolkit，盡管可能不太常見。在 Web 元件方面，webcomponents.org 列出了 2000 多個元素。甚至還有普通的 Web 元件，隻是它們與我們要讨論的不太相關（更多的是關注輕量級實作，而不是互操作性）。
路由
在 SPA 中管理路由需要使用 Web History API。雖然這并不複雜，但你仍然可能希望将其委托給簡單的路由器庫，如 Navigo。
你所要做的就是在路由時用一個 DOM 元素替換另一個 DOM 元素（使用 replaceChildren() 或 replaceWith() 方法）。
延遲加載
按需加載 JavaScript 代碼是任何一個 Web 應用程式都需要考慮的問題。你一定不希望為了顯示一個登入界面而加載全部的應用程式代碼。
早在 2009 年，在 Web 架構出現之前，James Burke（Dojo 開發者）就釋出了 RequireJS（最開始叫“RunJS”）來解決這個問題。從那時起，随着子產品化的出現，出現了更多的技術。從 ES6（2015）開始，我們可以動态加載代碼。在 Node 中可以，在浏覽器中也可以：
那麼如何将子產品分拆到單獨的檔案中？打包器（如 Webpack）可以為你做這些工作。
需要注意的是，在導入路徑裡你應該隻使用常量，否則打包器就無法猜到你想要加載什麼，就會将所有可能的檔案都打包在一個檔案中。例如，await import() 将把所有東西都打包到指定的目錄中，因為打包器不知道變量 moduleName 在運作時會是什麼。
原生應用程式
越來越多的架構為原生平台（如 React Native）提供了運作、遷移或編譯應用程式的方法，以便将它們作為獨立應用程式部署到 Android 或 iOS 移動系統上。
除了考慮開發真正的原生應用程式之外，更普遍的解決方案是将 Web 應用程式嵌入到原生容器中，比如之前的 PhoneGap（現已停止維護）或 Apache Cordova，現在的 NativeScript（它支援架構，如 Angular，也支援普通的應用程式），或者像 Electron 這樣的原生 Web 應用程式包裝器，或者 Electron 的輕量級後繼者 Tauri。
伺服器端渲染
很多架構在前端和後端運作的代碼是相似的，這樣更容易實作對 SEO 友好的伺服器端渲染（SSR）。
這可能是一個又酷又便利的特性，但需要注意的是，它也可能導緻伺服器鎖定。是以，在向應用程式引入架構鎖定之前，你需要考慮它對項目、基礎設施、用戶端技術等方面的影響。
所幸的是，你也可以在不使用架構的情況下實作這個特性。
從伺服器端渲染
采用普通的實作方案在一開始看起來很簡單：不就是傳回 HTML 嗎？是的，你已經有現成的元件了，但是：
你還需要一個伺服器端 DOM API，因為預設情況下，伺服器端不提供 DOM API（由 Domenic Denicola 負責維護的 JSDOM 或經過優化的 Happy DOM 就是很好的選擇）。
你的渲染元件不能假設是 DOM 是在用戶端或伺服器端，也就是說，不要使用全局 DOM，因為在伺服器端，每個請求都需要一個 DOM。要做到這一點，你需要從（用戶端或伺服器）應用程式上下文中選擇 DOM 對象（windowdocument 和類型，如 Node、HTMLElement、NodeFilter），而不是直接擷取。
在用戶端和伺服器應用程式之間共享渲染元件有多種辦法，比如将其釋出在包存儲庫中，但最靈活的應該是讓應用程式包引用 monorepo 中的子產品。
添加互動性
然而，一旦 HTML 元素被轉換成字元串，在這些元素上設定的所有事件處理器都丢失了。為了恢複互動性，你需要一些“補水”步驟，也就是注入腳本，讓它們在用戶端執行。架構因其普适性很難做到這一點。就拿影子 DOM 來說，它們不斷嘗試改進算法，希望能夠以最聰明的方式做到這一點，但如果我們把問題縮小到應用程式層面，就會變得簡單很多。
當然，在普通的伺服器應用程式中做到這一點也意味着需要将 JS 腳本注入到響應消息中（通過引用或内聯，具體取決于你想要怎樣的“漸進”程度，比如将 Web 元件所需的代碼嵌入到 HTML 響應中，讓它們在用戶端執行）。
普通的解決方案讓你可以控制在哪裡、什麼時候以及附加哪些東西：你可以先隻發送 HTML，再加載基本的互動性 JavaScript，然後加載更多（取決于使用者的操作），等等。
這比本文中提到的任何一個東西都簡單，因為它們是應用程式代碼，而不是通用的架構代碼。
國際化
多年來，國際化問題都是通過庫來處理的（最終也被內建到架構中）。要自己內建這些庫也很容易，但你也可以選擇自己實作一個，因為與通用庫相比，自己的實作可以支援更簡單、更有效的消息類型。
就是這麼簡單：
這裡為你提供了：
類型檢查：每個消息都有一個靜态類型（和幾個翻譯實作），是以 IDE 可以檢查你是否使用了有效的消息屬性，并為你提供自動補全功能。
翻譯完整性檢查：在為所有消息鍵提供所有語言的翻譯之前，無法通過編譯。
你所需要做的就是（加載和）執行個體化與使用者語言環境相關的消息類。通用庫不會提供這種特定于業務的消息類型。
工具
如果你想要擺脫對強限制性軟體技術棧的依賴，那你很可能也想擺脫對工具的依賴：你不希望隻有靠着它們（它們的局限性、性能、錯誤、版本）才能向前走。你不希望被一個你無法解決的建構問題（或者需要數小時或數天才能解決）所困擾（特别是如果你使用的是最近建構的版本，而它們還沒有經過充分的實戰測試）。
話雖如此，你仍然很難避免使用這些工具。大多數情況下，你的産品代碼必須以某種方式打成包，包括縮小體積、混淆、代碼拆分、搖樹優化、延遲加載、包含樣式等。毫無疑問，現有的打包工具如 Webpack、Parcel、ESBuild 或 Vite 會做得比你更好。
你所能做的是：
盡可能少用轉譯。例如，使用 TypeScript 可能是件好事，但它會帶來額外的複雜性，你的工具鍊中必須有相應的工具來處理這種複雜性。CSS 也一樣，特别是最新版本，不值得你用預處理器（如 Sass）來處理它們。
盡可能少用工具。你用的工具越多，就越有可能出問題或無法滿足你的需求。
如果确實需要使用工具，請選擇最流行的工具，因為它們經過實戰測試，更有可能滿足你的需求（這樣你就不會陷入“改變需求或更換工具”的困境）。過早使用最新的打包工具可能會為你節省幾秒鐘的建構時間，但這些時間很可能都不夠用來了解工具文檔、處理 bug 或處理因缺乏支援而導緻的問題。
最大的挑戰
說到底，最大的挑戰不是技術上的，而是關于人的：
你要走出舒适區。希望你終将能夠明白，使用普通的解決方案并不是那麼困難，架構的複雜性比它們帶來的好處要大得多。此外，你可能會看到更多新的 API（WebComponents、ES6 子產品、代理、MutationObserver……），而且 Web 比你想象的更現代、更強大。
至于其他人，你可以嘗試說服他們。他們可能不願意這麼做，因為任何人都不願意開啟自己從未嘗試過的旅程。
其他人可能會跟你說：
“你要開發自己的架構”：不，我們要開發的是應用程式，而不是架構。
“你要寫更多的代碼”：也許，但也許不會太多（取決于用了多少開發庫），因為這需要與架構的樣闆代碼進行比較。但不管怎樣，需要加載的代碼都會更少。
“你将不斷地重新發明輪子”：當然不是。不使用架構是為了不遵循它們預定義的規則（配置、生命周期管理、重新整理機制等），但我們并沒有忘記 DRY 原則，我們仍然可以（并且應該）使用經過實戰測試的第三方庫。
“你需要為每一個功能寫更多的代碼”：不，你可以遵循自己的規則，而不是使用架構樣闆代碼。
“沒有文檔可看”：肯定不會有架構文檔（因為根本就沒有架構），但你仍然需要寫應用程式文檔。值得一提的是，使用模式有助于你自動文檔化你的軟體設計。你隻需要關心應用程式的代碼文檔，而如果你多使用一個架構，就需要多看一份文檔。
“不會有限制或模式來指導開發人員”：不，如果你确實需要限制，沒有什麼能阻止你（你隻需要定義契約就行了）。
“你會錯過性能提升”，比如曾經被大肆炒作的虛拟 Dom（如今受到了挑戰，包括來自 Svelte 或 Aurelia 架構的挑戰）：不，因為需要這些“性能提升”的是架構本身（為了通用性），而不是應用程式。相反，通用架構更有可能錯過一些可以通過自定義代碼實作的性能提升。
你遇到這個問題是因為你沒有使用架構。每一個問題（包括漏洞、延遲、招募等）都會被歸咎于因為沒有使用架構。因為大多數開發人員的經驗是，所有正常運作的東西都使用了架構，預設情況下，不使用它們将被認為是有風險的。一旦出現問題，無論是否與不使用架構有關，這個假設都會被認為是正确的。他們忘記了在使用架構時也會遇到類似的問題。
“我們找不到開發者”：他們會說很難找到能夠寫純 JS 代碼的開發者。這句話是對的，也是錯的。因為很多開發者（且不說管理者）會發現自己更習慣于使用架構。如果他們從來沒有使用過或不了解基本的 Web API，那麼他們可能會對從零開始建構一個 Web 應用程式感到害怕。但是，如果你想要開發高品質的應用程式，就不應該去找這種類型的開發者。當然，現在找 React 開發者很容易，但你需要的不隻是 React 開發者，而是優秀的開發者。
“你無法獲得與架構相同的代碼品質”。當然，架構或開發庫通常是由行業裡有經驗的開發者編寫的。但是，架構的代碼主要與架構特定的活動相關（元件生命周期、通用的重新整理機制和優化、工具，等等），與你的應用程式無關。此外，即使使用了架構，你仍然可能做出糟糕的設計，寫出糟糕的代碼。應用程式的品質總是更多地取決于團隊的品質，而不是因為缺少架構。
“你無法獲得與架構相同的性能”：不，我們可以獲得更好的性能。行業裡關于架構采用了可以“提升性能”的複雜技術的說法就不在這裡讨論了，因為它們可能主要被用來解決架構通用解決方案的性能缺陷（比如虛拟 DOM）。
毫無疑問，性能最好的架構是那些在普通代碼之上添加層數較少的架構。架構的“優化”更多的是為了彌補架構本身的開銷。
結 論
不使用架構建構 Web 應用程式并非意味着要自己建構架構，它是關于在不使用通用引擎的情況下開發應用程式，目的是：
避免散失控制和被隐含限制（鎖定、更新成本等）；
可以進行優化（性能、體積、設計）。
也就是隻編寫特定于應用程式的代碼（業務和技術），包括使用開發庫。你真正應該關注的架構是你自己的架構，也就是那個特定于應用程式的架構。這是真正的“專注于業務”，也是最有效的。
這并沒有你想象的那麼難，特别是有了現代标準的加持（在必要時主流浏覽器可以通過 polyfill 來支援新特性）。
https://javarome.medium.com/design-noframework-bbc00a02d9b3