隨心所欲的超媒體
Carson Gross多頁應用程式（MPA）剩下的一大優勢是（伺服器端程式）語言的選擇。如果你已經加入了反 JavaScript 的行列，那麼我接下來要說的內容對你來說就沒那麼重要了。
但是，我稍後會提到：這艘船可能已經啟航了...
Rich Harris - 單頁應用程式（SPA）是否毀了網路？
我們喜歡談論的一個概念是「HOWL 堆疊」。HOWL 代表隨心所欲的超媒體。
這是一個半開玩笑的 軟體堆疊，並參考了更知名的堆疊，例如 LAMP 堆疊 或 MEAN 堆疊。
HOWL 堆疊的重點是：當你為你的網路應用程式使用 超媒體驅動方法 時，你可以自由選擇任何最適合你的問題和技術偏好的伺服器端技術。
#感受到 JavaScript 的壓力
如果你決定為你的網路應用程式使用單頁應用程式（SPA）框架，很自然地，你會擁有一個用 JavaScript 編寫的大型前端程式碼庫。
鑑於此，以下問題將不可避免地出現
「那麼，我們為什麼不在後端也使用 JavaScript 呢？」
這是一個合理的問題，在網路兩端採用相同的程式語言有很多優勢
- 你可以在兩個程式碼庫之間共享應用程式邏輯。這裡的一個很好的例子是驗證邏輯。
- 你可以在兩個程式碼庫之間共享資料結構。
- 你可以建立對單一語言 JavaScript 的專業知識，讓開發人員更容易在應用程式的各個部分工作。
- 你可以重複使用你為前端獲得的建置系統和依賴管理知識
隨著你對 JavaScript 前端生態系統的投資增加，採用 JavaScript 的這種壓力只會越來越大。
此外，JavaScript 在過去五年中有了顯著的改進，現在有許多優秀的伺服器端執行環境來執行它。許多關於該語言混亂的舊論點可以被視為可透過程式碼檢查、開發人員自律等方式來避免。
JavaScript 是網路開發思想領袖中的主要語言，並且有大量的教學課程、程式碼訓練營等，都強烈強調這種語言。沒有什麼比成功更成功了，而 JavaScript（以及 React）已經成功了。
讓我們將此結果稱為JavaScript 壓力，並承認幾乎每個從事網路開發的開發人員都至少在某種程度上感受到了這種壓力。
#超媒體：我們唯一的希望
非 JavaScript 開發人員在網路開發中還有什麼希望？
嗯，瀏覽器中與 JavaScript 並存的一種較舊的技術是：超媒體。
瀏覽器提供出色的 HTML 支援（以及相關的文件物件模型，或 DOM）。事實上，即使你正在使用單頁應用程式（SPA）框架，你也會以某種形式使用該超媒體基礎設施（例如透過 JSX 範本），即使只是為了建立瀏覽器可以理解的使用者介面。
因此，你將在你的網路應用程式中以某種方式使用 HTML 或相關的 DOM API。
那麼，如果我們使 HTML 成為更強大的超媒體呢？
這就是 htmx 的想法，它可以使用超媒體方法實現常見的現代網路應用程式模式。這縮小了傳統多頁應用程式（MPA）和單頁應用程式（SPA）之間的 UX 差距，使得採用超媒體路線對於更多網路應用程式來說是可行的。
一旦你採用這種超媒體方法（並記住，你無論如何都會使用超媒體基礎設施，那麼為什麼不盡可能地利用它呢？），就會發生一個令人驚訝的副作用
突然間，Harris 歸因於多頁應用程式（MPA）的伺服器端語言選擇的優勢又重新回到了檯面上。
如果你的應用程式的前端主要是以 HTML 編寫的，可能帶有一些用戶端腳本，並且沒有大型 JavaScript 程式碼庫，那麼你突然大幅減少（或完全消除）了後端的 JavaScript 壓力。
你現在可以根據其他考慮因素（技術、美學或其他）來選擇你的伺服器端語言（和框架）
- 也許你正在從事人工智慧方面的工作，並希望為你的專案使用 Lisp 的變體
- 也許你正在從事大數據方面的工作，並希望使用 Python
- 也許你非常了解 Django，並且喜歡它所採用的包含所有功能的途徑
- 也許你更喜歡 Flask 及其採取的精簡方法
- 也許你喜歡 PHP 的原始、接近 HTML 的感覺
- 也許你現有的 Java 程式碼庫需要一些修飾
- 也許你正在學習 Cobol，並希望使用 htmx 為其建立一個漂亮的前端。
- 也許你只是非常喜歡 Rust、Ocaml、Kotlin、Haskell、.NET、Clojure、Ada、ColdFusion、Ruby… 隨便什麼！
這些都是完全合理的技術、哲學和美學觀點。
而且，透過採用超媒體作為你的主要前端技術，你可以追求任何這些目標，而無需使用雙程式碼庫。超媒體不在乎你用什麼來產生它：你可以在任何你想要的環境中使用超媒體。
#為所有人開放的網路
當我們說「任何」時，我們真的是這個意思。
這是最近 htmx discord 的 HOWL 子部分的螢幕截圖。請注意，這些只是剛好有活躍流量的頻道，還有更多。
你可以看到我們正在用許多不同的程式語言和框架進行對話：Java、Go、.NET、Rust、Clojure、PHP、Ruby、Python、Ocaml。我們甚至還有一些人談論使用 htmx 和 Bash 和 Cobol！
這正是我們想要看到的未來：一個豐富而充滿活力的網路，其中每種後端語言和框架都可以作為一個平等且有趣的替代方案發揮作用。每種語言和框架都有其獨特的優勢和文化，並且每種語言和框架都可以為神奇的 超媒體系統（即網路）做出貢獻。
#但是，這是反 JavaScript 的抵抗嗎？
在結束這篇文章之前，我們確實想解決這樣一個觀點，即對無處不在的 JavaScript 的抵制必然是反 JavaScript 的。
現在，誠然，我們嘲笑了很多關於 JavaScript 的笑話，而且我們甚至還為網路建立了一種替代的腳本語言 hyperscript。
所以看起來我們應該是堅定的反 JavaScript 支持者。
但是，恰恰相反，我們非常讚賞 JavaScript。
畢竟，htmx 和 hyperscript 都是用 JavaScript 建構的。如果沒有 JavaScript，我們就無法建立這些函式庫，無論人們怎麼說，它都具有存在於那裡的巨大優勢。
我們甚至進一步建議在超媒體驅動的應用程式中使用 JavaScript 來滿足前端腳本需求，只要你以超媒體友善的方式編寫腳本即可。
此外，如果 JavaScript 是你的團隊的最佳選擇，我們也不會阻止人們在超媒體驅動的應用程式的伺服器端使用 JavaScript（或 TypeScript）。正如我們之前所說，JavaScript 現在有許多優秀的伺服器端執行環境和許多優秀的伺服器端函式庫可供使用。
它可能是你和你的團隊的最佳選擇，在這種情況下沒有理由不使用它。
隨心所欲的超媒體的意思就是：任何你想要的。
但 JavaScript 不是，而且它不應該是你團隊唯一的伺服器端選項。
#讓船轉彎
隨著人們對超媒體的興趣重新燃起（以及超媒體的改進），網路的開放和多元的未來現在是一個真正的可能性，如果還不是一個正在出現的現實。
網路被設計為一個開放、多語和參與式的超媒體系統。
而且，這艘船還沒有放棄那個夢想，至少還沒有！
我們可以透過重新學習和重新擁抱網路的基礎技術：超媒體，來保持那個夢想的活力。
我討厭 htmx 社群已經淪為建構者互相幫助，而無視讚數、與不追隨潮流的人互動、將簡短的言論擴展為細微差別。它可能不會獲得廉價的社群媒體積分，但它很健康。網路過去比現在更糟糕。