前端SPA正過渡到MPA多頁應用 - nolanlawson

banq發表於2022-05-22

像Astro、Qwik和Elder.js這樣的新框架正在兜售他們的MPA功能,"預設為0kB JavaScript"。部落格文章中列出了SPA的所有挑戰:歷史、焦點管理、滾動恢復、Cmd/Ctrl點選、記憶體洩漏等等。人們對SPA進行了痛快的抨擊。

近年來達環境的變化使MPA在與SPA的競爭中更佔優勢:
  • Chrome瀏覽器實現了油漆保持(paint holding)--在MPA頁面之間導航時不再有 "白色閃光"。(Safari已經做到了這一點)。
  • Chrome實現了後向快取(back-forward caching)--現在所有的主要瀏覽器都有這種最佳化,這使得在MPA中來回導航幾乎是瞬間完成。
  • 服務工作者(Shared Element Transitions)--曾經是實驗性的,現在對於我們這些針對現代瀏覽器的人來說,實際上是100%可用的--允許離線導航,而不需要實現客戶端路由器(以及其中的所有複雜性)。
  • 共享元素轉換(Shared Element Transitions),如果被接受並在各瀏覽器中實施,也會給我們提供一種在MPA導航之間製作動畫的方法--這在以前只有在SPA中才能實現(儘管很困難)。


SPA還保留其地位
但是,這並不是說SPA沒有自己的位置。Rich Harris有一個關於 "過渡性應用 "的精彩演講,其中概述了一些你可能仍然想使用SPA的原因:
例如,你可能想要一個無所不在的元素,可以在頁面導航中存活下來,如音訊/影片播放器或聊天小工具。
或者你可能有一個無限載入的列表,在按下後退按鈕時,會返回到列表的前一個位置。

即使是沒有明確使用這些功能的團隊也可能選擇SPA,只是因為 "未知 "因素:

  • "如果我們有一天想實現導航動畫怎麼辦?"
  • "如果我們想新增一個無所不在的影片播放器呢?"
  • "如果我們想要的一些自定義功能不被現有的瀏覽器API所支援呢?"

選擇MPA是一個重大的架構決定,它可能有效地切斷了未來在瀏覽器API不盡如人意的情況下控制頁面的可能性。
SPA給了你完全的控制權,而許多團隊對放棄這一點猶豫不決。

JQuery教訓
話雖如此,我們以前也見過類似的情況。在很長一段時間裡,jQuery提供了瀏覽器沒有的API,而那些想在晚上睡個安穩覺的團隊就選擇了jQuery。
但是最終瀏覽器技術還是趕上了,給了我們像querySelector和fetch這樣的API,而jQuery開始看起來像是不必要的包袱。

我懷疑SPA也會發生類似的故事。為了說明這一點,讓我們考慮一下Rich的例子,即你 "需要 "一個SPA:

  • 無處不在的聊天小部件:使用共享元素轉換來保持小部件在MPA導航過程中的顯示。
  • 在後退按鈕上恢復滾動位置的無限列表:使用內容可見性,如果有必要,可以將狀態儲存在服務工作者中。
  • 在導航過程中持續播放的無所不在的音訊/影片播放器:今天在MPA中無法實現,但誰知道呢?也許畫中畫的API有一天會支援這個。


SPA不會完全消失
不過要清楚的是,我不認為SPA會完全消失。我不確定你如何能夠合理地實現像Photoshop或Figma這樣的MPA。但是,如果新的瀏覽器API和功能不斷出現,慢慢削弱了SPA的優勢,那麼未來越來越多的團隊可能會選擇建立MPA。

我個人認為,我們有這麼多的選擇是令人興奮的(而且它們都比10年前要好得多!)。我希望人們保持開放的心態,不斷推動SPA和MPA(以及 "過渡性應用",或我們將稱之為下一個東西的任何東西)在未來變得更好。

 

相關文章