在不斷發展的網頁開發世界中，關於使用原生 JavaScript 與流行框架如 React、Vue 或 Svelte 的優劣之爭再次引發熱議。討論的焦點是一種稱為硬方式編寫 JavaScript 檢視的模式，該模式提倡使用原生 JavaScript 直接操作 DOM，而不依賴框架提供的抽象層。
 |
|---|
| GitHub 倉庫"Writing JavaScript Views the Hard Way"，突顯了純 JavaScript 與框架之間辯論中的一個關鍵專案 |
無框架開發的吸引力
社群中許多開發者表達了拋棄框架轉而使用原生 JavaScript 方法的熱情。他們提到了顯著的效能優勢、更容易的除錯過程以及與網路平臺更直接的連線。一位開發者分享了他們最近使用純 TypeScript 和 Vite 構建應用程式的經歷，指出在看到直接方法的好處後，他們越來越質疑前端最佳實踐。這種吸引力不僅限於技術優勢，還包括教育益處，因為直接與 DOM 工作迫使開發者更深入地理解底層網路技術。
「我不能斷言它是否可擴充套件，無論這意味著什麼，但我可以肯定有巨大的效能優勢，它很有趣，教會你很多，除錯簡單，理解架構變得簡單，你不需要深入研究特定的渲染/記憶化/等技術獲得博士學位。」
"硬核方式編寫 JavaScript 檢視"的優勢
- 效能：接近最優效能，最小化不必要的操作
- 零依賴：無需升級或管理外部庫
- 可移植性：程式碼可與任何框架一起使用
- 可維護性：遵循嚴格的約定，使程式碼組織更可預測
- 瀏覽器支援：相容所有瀏覽器（併為舊瀏覽器提供相容性選項）
- 更簡單的除錯：淺層堆疊跟蹤使問題追蹤更簡單
- 函式式方法：使用普通函式而非複雜的類層次結構
DOM 作為真相源
討論中出現的一個有趣模式是使用 DOM 本身作為應用程式狀態的真相源，而不是維護單獨的狀態變數。一些開發者提倡透過 getter 和 setter 直接讀寫 DOM 元素，而不是保持需要與 DOM 同步的單獨 JavaScript 變數。這種方法消除了在兩個地方維護狀態的需要，但也引發了對潛在漏洞的擔憂，例如可能意外修改 DOM 的瀏覽器擴充套件，或處理多個 UI 元件間冗餘狀態的挑戰。
可維護性擔憂
雖然硬方式方法承諾簡單性，但許多開發者對其在團隊環境和大型應用中的可維護性表示懷疑。該模式嚴重依賴約定而非強制結構，這可能導致不同團隊成員為程式碼庫貢獻時出現不一致。正如一位評論者指出，設計模式僅基於約定。這意味著開發者可以隨時偏離約定。這與透過 API 和工具強制執行某些模式的框架形成對比。
狀態管理：真正的挑戰
評論中反覆出現的主題是，前端開發中真正的難點不是建立 DOM 元素，而是管理狀態並保持 UI 與該狀態同步。響應式框架的存在正是為了解決這個問題。隨著應用變得更加複雜，手動跟蹤狀態變化時需要更新的 UI 部分變得越來越困難。一位開發者指出，基本問題是當某個狀態發生變化時，所有依賴該狀態的 UI 都需要更新，而隨著應用規模擴大，手動維護這些更新函式變得越來越不便。
"Hard Way"元件的結構
- 模板：使用
document.createElement('template')來定義HTML結構 - 克隆函式：建立模板的新例項
- 初始化函式：設定元件例項，包括：
- DOM變數（對元素的引用）
- 狀態變數（資料值）
- DOM更新函式（用於更改元素）
- 狀態更新函式（用於更改資料）
- 更新函式（用於接收來自父元件的屬性）
安全考慮
幾位開發者提出了關於手寫模板方法可能存在的安全漏洞的擔憂。使用模板字面量生成 HTML 字串如果沒有正確轉義使用者輸入，可能導致跨站指令碼（XSS）漏洞。雖然伺服器端的淨化可以提供幫助，但許多人認為現代框架透過自動處理這些問題提供了更好的保護。討論強調了開發者在手動生成 HTML 時很容易引入安全問題，尤其是那些沒有經歷過前框架時代網頁開發的開發者。
總之，雖然硬方式方法在某些用例中提供了令人信服的好處——特別是在效能、控制和學習機會方面——但社群對其是否適合大規模生產應用仍存在分歧。這場辯論最終反映了多年來網頁開發的特點：簡單性與結構之間、直接控制與抽象便利之間的張力。隨著瀏覽器繼續發展並提供更強大的原生 API，這種討論可能會繼續演變。