Web 前端由 25 年前的技术组成。 HTTP、HTML、CSS 和 JS 都在 20 世纪 90 年代中期首次标准化。 从那时起，网络已经发展成为一个无处不在的应用程序平台。 随着网络的发展，用于开发这些应用程序的架构也在不断发展。 如今，有许多用于构建 Web 应用程序的核心架构。 目前 Web 开发人员使用的最流行的架构是单页应用程序 (SPA)，但我们正在转向一种新的、改进的架构来构建 Web 应用程序。

　　并且元素从一开始就存在。 链接用于让浏览器从服务器获取内容，而表单用于让浏览器将内容发送到服务器（并取回内容）。 通过从一开始就将这种双向通信包含在规范中，就可以永远在网络上创建强大的应用程序。

　　以下是主要的架构（按流行时间顺序排列）：

　　每种 Web 开发架构都有其优点和痛点。 最终，痛点变得足够严重，促使人们转向下一个架构，这带来了自己的权衡。

　　无论我们如何构建应用程序，我们几乎总是需要在服务器上运行代码（值得注意的例外包括像这样的游戏，它将游戏状态存储在本地存储中）。 区分这些架构的一种方法是代码所在的位置。 让我们依次探索每个架构并观察代码位置如何随时间变化。 在讨论每种架构时，我们将特别考虑以下代码用例：

　　当然，Web 应用程序还有更多部分，但这些是移动最多的部分，也是我们作为 Web 开发人员花费大量时间的部分。 根据项目规模和团队结构，我们可能会在所有这些代码类别中工作，也可能只在其中某些类别中工作。

　　多页应用程序 (MPA)

　　在早期，这是基于当时网络浏览器功能的唯一可行的架构。

　　在多页面应用程序中，我们编写的所有代码都驻留在服务器上。 客户端 UI 反馈代码由用户的浏览器处理。

　　MPA架构

　　注意：成功的更新应该发送重定向响应，而不仅仅是新的 HTML。 否则，您的历史堆栈中将会有一个 POST 请求，并且单击后退按钮将再次触发 POST 请求（有没有想过为什么应用程序有时会说“不要单击后退按钮！”是的，这就是原因。他们应该响应重定向）。

　　MPA的优点和缺点

　　

　　MPA 的思维模型很简单。 我们当时不太喜欢它。 虽然某些状态和复杂流程是在请求/响应周期内处理的，但大多数是在请求/响应周期内完成的。

　　这种架构的缺点是：

　　值得注意的是，随着页面跳转API的即将推出，MPA将在更多场景下变得更加可行。 但对于大多数 Web 应用程序来说，这还不够。 无论如何，当时这个问题还远远没有引起标准委员会和用户的重视！

　　逐步增强的多页面应用程序()

　　渐进增强的理念是，我们的 Web 应用程序应该在所有 Web 浏览器上都能正常运行并可访问，然后利用浏览器具有的任何附加功能来增强用户体验。 该术语由 Nick Finck 和 Steve 在 2003 年创造。说到浏览器功能......

　　它最初由微软的 Web 团队于 1998 年开发，但直到 2016 年才标准化（你能相信吗！？）。 当然，到目前为止，这并没有阻止浏览器供应商和网络开发人员的脚步。 AJAX 这个术语在 2005 年开始流行，许多人开始在浏览器中发出 HTTP 请求。 企业建立在这样的理念上：我们不必再次返回服务器来获取更新UI所需的数据，而只需要少量的数据。 这样，我们就可以构建逐步增强的多页面应用程序：

　　“哇！” 您可能会想，“等一下......所有这些代码都来自哪里？” 现在，我们不仅负责来自浏览器的 UI 反馈，还负责路由、数据检索、数据突变和渲染。 逻辑被添加到客户端以及我们在服务器上已有的逻辑。 “怎么样？”

　　嗯，这就是事实。 渐进增强背后的想法是我们的基线应该是一个功能性应用程序。 特别是在 2000 年代初，我们无法保证用户使用的浏览器能够运行我们新的 AJAX 功能，或者他们在与应用程序交互之前能够在足够快的网络上下载我们的浏览器。 因此，我们需要保持现有的MPA架构不变，只用它来增强用户体验。

　　也就是说，根据我们所讨论的增强级别，我们可能确实需要在除持久性之外的几乎所有类别中编写代码（除非我们需要离线模式支持，这确实很好，但不是行业标准实践，所以没有包含在图表中）。

　　此外，我们甚至必须在后端添加更多代码来支持客户端发出的 AJAX 请求。 因此，网络双方都有更多的内容。

　　这是等待的时间。

　　PEMPA 架构行为

　　文档请求：当用户第一次请求文档时，MPA 示例中会发生相同的情况。但是，PEMPA 也会加载客户端，包括