小編精選 - 技術文章翻譯 · 05月14日

React 太過頭了：為什麼 Python + HTMX 在 2026 年主導一切

去年我花了四十分鐘搭建一個用於內部管理後台的 React 專案。只是一些樣板程式碼：Vite 配置、ESLint 設定、Tailwind 整合、React Router，還有 TanStack Query，因為有人在 Twitter 上說這是現在處理伺服器狀態的正確方法。當時我一行實際的應用邏輯都沒寫，就已經打開了十二個文件。

儀表板需要列出資料庫中的記錄，允許使用者篩選記錄並更新狀態欄位。就三件事。就這些。

從那以後，我一直在思考那一刻。倒不是因為 React 本身有什麼問題，而是因為整個經驗讓我問了一個或許應該早點問的問題：我究竟在解決什麼問題？我的技術棧是否與這個問題相符？

嚴格來說，HTMX 自 2020 年就已經存在。 Carson Gross 基於一些更早的理念建構了它——intercooler.js、超媒體以及 REST 的正確運作方式。但直到最近一年半左右，它才開始真正出現在生產程式碼庫中，而不再局限於業餘專案和部落格文章。 HTMX的 GitHub 程式碼庫的star 數已突破 4 萬。 2024年的 JS 現況調查顯示了一個奇怪但真實的現象：開發者在 React 旁邊標記「不會再次使用」的選項越來越多，而 React 的使用率卻依然很高。人們仍在使用它，但顯然熱情正在逐漸消退。

HTML 的工作原理其實很簡單，一句話就能解釋清楚：它允許 HTML 元素啟動 HTTP 請求，並根據回應交換頁面內容。就這麼簡單。沒有虛擬 DOM，沒有元件生命週期，沒有客戶端路由，也不需要任何狀態管理函式庫。你只要在輸入框上新增hx-get="/search"和hx-trigger="keyup changed delay:300ms" ，結果 div 就會更新。 HTML 本身就是狀態。伺服器渲染 HTML。搞定！

對於許多使用場景——無論是枯燥乏味的還是富有成效的——這真的就足夠了。

Python 的介入幾乎是水到渠成。 Django 和 FastAPI 都非常擅長快速渲染 HTML 片段。 Django 的模板引擎被低估了。 FastAPI 搭配 Jinja2 的速度足夠快，足以應對小型團隊可能遇到的絕大多數流量水平，你幾乎無需考慮其他因素。你從端點回傳一個 HTML 片段，HTML 就會加入到 DOM 中，使用者就能看到對應的變化。無需 JSON 序列化，無需客戶端反序列化，也無需 React 重新渲染。伺服器只需完成其應有的任務：處理資料，決定 UI 的顯示方式，然後將其發送出去。

Miguel Grinberg 在他的 Flask-HTML 教程中對這種模式做了很好的闡述，其核心觀點幾乎是枯燥乏味的：Web 應用採用伺服器端渲染已經長達十五年之久，而且運作良好。 SPA 時代確實解決了一些實際問題，但也引入了大量不必要的複雜性。

我想客觀地說明一下，因為關於 React 的討論很容易離題。 React 本身並不差。它在它最初設計的領域表現非常出色。當你需要豐富的客戶端互動功能時——例如協作編輯、複雜的即時介面，或類似 Figma 或 Notion 的應用——元件模型、單向資料流和客戶端渲染方式就顯得尤為重要。它的生態系統確實令人印象深刻。 Next.js 解決了實際的部署難題。 React 伺服器元件，一旦你克服了最初對它們概念的困惑，你會發現它們確實是一種值得理解的架構理念。

但大多數應用並非 Figma。大多數應用程式都是具有篩選功能的 CRUD 操作。大多數內部工具都是表單、表格和儀表板。大多數自由職業專案都是電商網站和預約系統。而對於所有這些應用，React 技術堆疊都要求你承擔大量對最終用戶毫無益處的功能。

關於 JavaScript 疲勞的討論由來已久——Jose Aguinaga 在 2016 年發表的這篇文章在八年前還頗具諷刺意味，因為它一針見血。諷刺的是，到了 2026 年，它依然適用，只是函式庫的名稱有所改變。打包工具變了。狀態管理從 Redux 演變為 Zustand，再到 Jotai，以及之後出現的各種工具。 React 引入了伺服器元件，導致一半的現有教程都失效了。要正確搭建一個 React 專案——甚至不需要編寫應用程式邏輯，只是搭建框架——所需的元知識量對於許多團隊來說實在難以接受。

在這裡，我想談談在這些討論中很少被提及的一點，那就是南亞開發者的具體情況。

許多關於前端框架的討論都發生在擁有高速網路、高階電腦的美國/歐洲開發者的視角下，而他們的客戶只要介面美觀，對效能並不在意。這種背景塑造了預設設定。當 Vercel 或 Netlify 的部落格文章討論套件大小和核心 Web 指標時，他們通常是在為那些認為 300kb 的 JS 套件只是小麻煩的受眾寫作。但在巴基斯坦——卡拉奇、拉合爾、海得拉巴以及其他一些小城市——這可不是小麻煩。二線城市的行動資料用戶正在等待你的單頁應用程式（SPA）加載完畢，而這在用戶體驗中顯而易見。

這裡的自由工作者大多在 Upwork 和 Fiverr 上接活。許多專案都是為小型企業開發後台管理面板、為本地公司開發人力資源工具以及基礎庫存管理系統。預算不高，時間也很緊迫。如果一位巴基斯坦開發者能夠用 Django + HTML 在兩三天內交付一個功能齊全的後台管理面板，因為無需設計 API 層、管理用戶端狀態或單獨配置身份驗證令牌流程——這無疑是巨大的生產力優勢。

我跟一些在信德省和旁遮普省的HITEC、COMSATS以及類似大學做畢業設計的學生聊過。說實話，React技術棧對那些還在摸索async/await的學生來說確實有點難。看著有人下午就搞懂HTML，晚上就能做出能用的東西──這可不是件容易的事。這種既能降低入門門檻又不犧牲功能的科技，確實值得稱讚。

本地的SaaS思維模式也截然不同。在卡拉奇，當有人開發他們的第一個B2B軟體產品時，他們考慮的是如何快速獲得付費客戶，而不是他們的架構能否擴展到千萬用戶規模。 Python搭配Django，就能在一個軟體包中提供ORM、管理面板、驗證和模板系統。再加上HTML，就能獲得響應式UI，而無需單獨部署前端、設定CORS或處理API版本控制等繁瑣的工作。對於單人創辦人或兩人團隊來說，這種簡潔性價值連城。

隨著時間的推移，我越來越清楚地認識到哪些情況下我會真正選擇 Python + HTMX。

內部工具顯然是最佳選擇。任何時候，如果公司需要一個只有十個人使用的儀表板，那麼建立一個完整的 React 單頁應用程式（SPA）就是一種組織成本，而不是一個功能。 JavaScript 套件需要維護，前端開發人員需要了解 API 接口，還需要有人管理部署流程。而使用伺服器端渲染的 HTML 和 HTMLX，只需要一個應用程式，一次部署。建構資料模型的開發人員也負責建立使用者介面。這並非簡單，而是經濟高效。

處於創意驗證階段的小型新創公司。如果你還不確定你的產品是否可行，那麼在與用戶交流之前就花三個月時間建立一個完善的 React 前端，這可能是一個不明智的決定。 Django + HTML 可以讓 Python 開發者在幾天內交付一個使用者可以點擊瀏覽的介面。這並非一勞永逸的架構，但也不必如此。

內容豐富且具有一定互動性的網站。例如，一個包含評論區、搜尋欄和新聞簡報訂閱的部落格。 HTML 可以簡潔地處理這些互動。你無需為了這三個互動元素而引入前端框架。

真正困難的地方在於，當你需要豐富的客戶端狀態。這類應用的使用者介面本身就是產品——設計工具、即時協作、複雜的資料視覺化（需要具備本地篩選和排序功能），而且這些功能必須即時回應。 React 及其生態系在這方面確實更勝一籌。這並非勉強承認，而是事實。

團隊協作方面也存在著一個常被人們忽略的因素。很多團隊的後端開發人員精通 Python，但前端技能一般，缺乏深度。 React 生態系統要麼需要真正的前端專業知識，要麼需要願意大量照搬 Stack Overflow 上的各種方法。 HTML 的伺服器端渲染則能充分發揮 Python 開發人員的優勢，無需專門的 Python 開發人員。在全端 Python 開發人員比 React 開發人員更容易找到且成本更低的市場中，這一點在組織架構上至關重要。

如果你想理解其中的理念而不僅僅是機制，那麼亞當·約翰遜關於 Django + HTMX 模式的研究以及HTMX 文件中關於超媒體的文章都值得一讀。這裡的論點並非“單頁應用程式（SPA）是個錯誤”，而是更接近：Web 平台擴展了 HTML 以支援透過 JavaScript 實現交互，但或許它應該擴展 HTML 本身。 HTMX 正是基於這種理念而誕生的。它是一個小巧而專注的庫——未壓縮後僅約 14kb——並且刻意限制了其功能範圍。它只負責一件事，其餘的都由 HTML 和 HTTP 來完成。

我一直覺得有些東西很難用語言表達，但卻很重要。 React 針對的是一種特定的開發者體驗——開發者在元件內部，以狀態、屬性和效果為核心進行思考的體驗。一旦你真正理解並接受這種思考模式，它就會成為一個強大的工具。但這種思考模式需要你完全投入，而且它也帶來了許多複雜性。

HTML 針對的是另一種體驗－伺服器端完全掌控一切，瀏覽器只是簡單地顯示伺服器端輸出的內容。這是一種更傳統的模式，它更貼近人們實際思考資料和業務邏輯的方式，而這些資料和邏輯都運作在伺服器端。對於許多開發者，尤其是那些真正擅長資料、後端系統和 API 的開發者來說，這種模式更加自然，也減少了情境切換的次數。

兩者之間沒有絕對的優劣。它們分別適用於不同的問題、不同的團隊以及產品生命週期中的不同階段。

然而，到了2026年，我們仍然可以肯定的是，HTML已經憑藉其在生產環境中的出色表現，贏得了應有的重視。這並非是對現代工具的抵制，也並非是對PHP「義大利麵式」程式碼的懷念。它是一種建立Web介面的實際方法，尤其適用於特定、龐大且尚未被充分重視的應用類別——而這正是我們大多數人大部分時間都在建構的應用類型。

我最終重建了那個管理後台。花了三天時間，用了 FastAPI、Jinja2 模板和 HTML。沒有建置步驟。沒有像小國那麼大的 node_modules 資料夾。後端團隊的每個開發人員都可以閱讀和修改模板，而無需學習新的程式設計範式。

它還在執行。沒人要求我用 React 重寫它。

如果你想深入了解其具體機制， HTMX 的官方文件寫得非常好，而且篇幅出乎意料地短小精悍。對於 Python 方面，即使你將 React 前端替換為 Jinja2， full-stack-fastapi-template也是一個很好的起點。此外， Carson Gross 在 2022 年 DjangoCon 大會上的演講，是你理解 HTMX 真正意圖的最佳途徑，也是最有條理的三十分鐘講解。