像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（以及 "过渡性应用"，或我们将称之为下一个东西的任何东西）在未来变得更好。