單一頁面應用程式 SPA 的退燒

空氣中瀰漫一種感覺， SPA（single-page app） 已經不再是 10 年前的酷孩子了。

像 Astro、Qwik 和 Elder.js 這樣的新框架都在宣傳他們的 MPA 功能是「預設 0kB JavaScript」。 四處流傳部落格文章，列出了 SPA 的所有挑戰：歷史、焦點管理、滾動恢復、Cmd/Ctrl-click、記憶體洩漏等。

不過，我認為討論較少的是近年來環境發生了怎樣的變化，從而使 MPA （multi-pagep app） 在對抗 SPA 方面更具優勢。 尤其是：

1. Chrome 實現了 “paint holding” — 在 MPA 頁面之間導航時不再出現“白色閃光”。 （Safari 已經這樣做了）
2. Chrome 實現了 “back-forward caching” — 現在所有主流瀏覽器都有這種優化，這使得在 MPA 中來回導航幾乎是即時的。
3. Service Workers — 曾經是實驗性的，現在對於我們這些針對現代瀏覽器的人來說實際上 100% 可用 — 允許離線導航，而無需實現客戶端路由器（以及其中的所有複雜性）。
4. 共享元素轉換，如果在瀏覽器中被接受和實現，也將為我們提供一種在 MPA 導航之間進行動畫處理的方法 — 這在以前只能通過 SPA 實現（儘管很困難）。

這並不是說 SPA 沒有自己的位置。 Rich Harris 就“過渡性應用程式”進行了精彩的演講，其中概述了您可能仍想使用 SPA 的一些原因。例如，您可能想要一個在頁面導航中倖存下來的無所不在的元素，例如音頻/視頻播放器或聊天小零件。或者您可能有一個無限加載列表，按下後退按鈕時，它會返回到列表中的上一個位置。

即使沒有明確使用這些功能的團隊也可能仍然選擇使用 SPA，只是因為“未知”因素。 “如果有一天我們想實現導航動畫怎麼辦？” “如果我們想添加一個無所不在的視頻播放器怎麼辦？” “如果我們想要一些現有瀏覽器 API 不支援的自定義設置怎麼辦？”選擇 MPA 是一個重大的架構決策，在瀏覽器 API 無法滿足要求的情況下，它可能會有效地切斷未來控制頁面的可能性。到最後，因為 SPA 讓您有完全的控制權，所以許多團隊都不願放棄它。

也就是說，我們之前已經看到過類似的情況。長期以來，jQuery 提供了瀏覽器沒有的 API，想要晚上睡個好覺的團隊選擇了 jQuery。最終瀏覽器迎頭趕上，為我們提供了 querySelector和 fetch 等 API，而 jQuery 開始看起來像是不必要的包袱。

我懷疑類似的故事可能會發生在 SPA 上。為了說明這一點，讓我們考慮一下 Rich 的示例，這些示例是您“需要” SPA 來完成的：

1. 無所不在的聊天小零件：使用共享元素轉換在 MPA 導航期間保持小零件的繪製。
2. 點擊後退按鈕後回到無限清單的原滾動位置：使用 content-visibility，並在必要時將狀態存儲在 Service Worker 中。
3. 在導航期間不斷播放的無所不在的音頻/視頻播放器：今日的 MPA 中是不可能做到的，但誰知道呢？ 也許有一天 Picture-in-Picture API 會支援這一點。

不過，需要明確的是，我認為 SPA 不會完全消失。 我不確定如何合理地將 Photoshop 或 Figma 之類的東西實現為 MPA。 但如果新的瀏覽器 API 和功能不斷落地，慢慢削弱了 SPA 的優勢，那麼未來可能會有越來越多的團隊選擇構建 MPA。

就我個人而言，我認為我們有這麼多可供選擇的選擇令人興奮（而且它們都比 10 年前好多了！）。 我希望人們保持開放的心態，繼續推動 SPA 和 MPA（以及“過渡性應用程式”，或者我們將稱之為 the next thing 的任何東西），讓它們在未來變得更好。

>> 原始文章