深圳餐饮网站建设,肥城做网站tahmwlkj,产品网络推广方案,wordpress的评论插件Web 技术大概 25 年前开始萌芽#xff0c;HTTP、HTML、CSS 和 JS 都是在九十年代中期首次被标准化的。直到如今#xff0c;Web 演变成一个无处不在的应用平台。随着 Web 的发展#xff0c;Web 应用程序的开发架构也在不断发展。现在有许多用于构建 Web 应用程序的核心架构HTTP、HTML、CSS 和 JS 都是在九十年代中期首次被标准化的。直到如今Web 演变成一个无处不在的应用平台。随着 Web 的发展Web 应用程序的开发架构也在不断发展。现在有许多用于构建 Web 应用程序的核心架构目前最流行的是单页应用 (SPA)但我们正在逐渐过渡到一种新的改进架构来构建 Web 应用程序。下面是一些主要的架构模式多页应用 (MPA)渐进增强的多页应用PEMPA单页应用 (SPA)渐进增强的单页应用 (PESPA)每种架构都有它的优点和痛点但是往往架构的痛点会成为一个足以促使人们转向下一个架构的核心动力在技术选型时我们需要综合考虑。无论我们怎么构建我们的应用程序总绕不过需要在服务器上运行代码。其实这些架构的最大区别就是代码所在的位置。下面我们就依次来看一下并观察代码的位置是如何随时间演进的。在分析每种架构时我们会从以下几个角度考虑持久化Persistence - 从数据库中保存和读取数据路由Routing - 根据 URL 切换模块数据获取Data fetching - 从持久化存储中检索数据数据变更Data mutation- 持久化中的数据变化渲染逻辑Rendering logic - 向用户显示数据UI 反馈UI Feedback - 响应用户交互注意在后面的架构图中我们都会使用英文当然Web 应用程序的组成部分远不止这些但这些部分是变化最多的部分也是我们作为 Web 开发者花费大量时间的地方。根据不同的项目规模和团队结构我们可能会处理所有这些类别的代码也可能只处理其中的一部分。多页应用 (MPA)在早期浏览器的功能比较简单这是当时在 Web 上运行的唯一架构。MPA我们编写的所有代码都存在于服务器上只有客户端上的 UI反馈 代码由用户的浏览器处理。MPA 架构文档请求MPA 文档请求当用户在地址栏中输入 URL 时浏览器会向我们的服务器发送请求。我们的路由逻辑将调用一个函数来获取数据该函数会与数据库通信来检索数据。然后渲染逻辑会使用此数据来生成将作为响应发送给客户端的 HTML。一般来讲浏览器都会向用户提供一些处理中状态的反馈比如 favicon 位置的 loading。变更请求MPA 变更请求当用户提交表单时浏览器会将表单内容序列化为发送到我们服务器的请求我们的路由逻辑会调用一个函数来更新数据库。然后它就会通知浏览器进行重定向浏览器会触发一个新的 GET 请求来获取新的 UI然后就和上一步用户输入 URL 的结果一样了。注意成功的变更会发送一个重定向的响应而不仅仅是发送一个新的 HTML这一点很重要。浏览器的历史堆栈中会有一个 POST 请求点击后退按钮会再次触发这个 POST 请求想知道为什么应用程序有时会显示“不要点击后退按钮” 是的就是这个原因。。MPA 的优缺点MPA 的心智模型很简单但当时我们对它并不看好。虽然在请求中主要由 Cookie 处理一些状态和复杂的流程但在大多数情况下一切都发生在请求/响应周期的时间内。缺点让诸如焦点管理之类的操作变得苦难具有动画效果的页面切换几乎不太可能用户体验很差。值得注意的是随着即将推出的 page transitions API Web 平台不断改进给 MPA 架构带来了更多可能性。https://developer.chrome.com/blog/shared-element-transitions-for-spas/渐进增强的多页应用 (PEMPA)渐进式增强的理念是我们的 Web 应用程序应该是功能性的对所有 Web 浏览器都应该是可访问的然后利用浏览器的任何额外功能来增强体验。该术语由 Nick Finck 和 Steve Champeon 于 2003 年创造。渐进增强是我们的 Web 应用程序应该是功能性的并且所有 Web 浏览器都可以访问的想法然后利用浏览器具有的任何额外功能来增强体验。该术语由 Nick Finck 和 Steve Champeon 于 2003 年创造。XMLHttpRequest 最初由 Microsoft 的 Outlook Web Access 团队于 1998 年开发但直到 2016 年才标准化你相信吗。当然这从未阻止过浏览器供应商和 Web 开发者。AJAX 作为一个术语在 2005 年流行起来很多人开始在浏览器中发出 HTTP 请求。业务建立在这样一个理念上即我们不必回到服务器去获取更多的数据来更新适当的 UI。这样我们就可以构建逐步增强的多页面应用了PEMPA“哇!“ 你可能会想 “等一下… 这些代码是从哪里来的?” 因此现在我们不仅要负责来自浏览器的UI反馈我们还需要向客户端提供路由、数据获取、数据变更和渲染逻辑而不仅仅是在服务器上已有的这些逻辑。“到底发生了什么事?”好吧是这样的。渐进增强背后的理念是我们的基线应该是一个功能性的应用程序。特别是在 21 世纪初我们不能保证用户使用的浏览器能够运行像 AJAX 这样花哨的新东西或者他们在与应用程序交互之前能够在足够快的网络上下载我们的 JavaScript 。所以我们需要保持现有的 MPA 架构只使用 JavaScript 来增强体验。也就是说根据我们所讨论的增强级别我们可能确实需要编写几乎所有类别的代码数据持久化除外除非我们想支持离线模式。另外我们还必须向后端添加更多代码来支持客户端发出的 AJAX 请求。所以在两端都需要有更多的开发者。这是 jQuery、MooTools 等的时代。PEMPA 架构文档请求PEMPA 文档请求当用户第一次请求 HTML 文档时发生的事情和 MPA 示例中的一样。但是PEMPA 还将通过包含用于增强功能的 script 标签来加载客户端 JavaScript。客户端导航PEMPA 客户端导航当用户在我们的应用程序中单击带有 href 的 anchor 元素时我们的客户端数据获取代码会阻止默认的整页刷新行为并使用 JavaScript 更新 URL。然后客户端路由逻辑会确定需要对 UI 进行哪些更新并手动执行这些更新包括在数据获取库向服务端发出网络请求时显示任何 Loading 状态UI 反馈。服务器路由逻辑会调用数据获取代码从数据库中检索数据并将其作为响应XML 或 JSON发送然后客户端使用其渲染逻辑执行最终的 UI 更新。PEMPA 变更请求当用户提交表单时我们的客户端数据变更逻辑会阻止默认的整页刷新和发布行为使用 JavaScript 序列化表单并将数据发送到服务端。然后服务器路由逻辑调用数据变更函数与数据库交互以执行变更并将更新的数据响应给客户端。客户端渲染逻辑将使用更新后的数据来更新 UI在某些情况下客户端路由逻辑会将用户发送到另一个地方这会触发与客户端导航流程类似的流程。PEMPA 的优缺点通过引入客户端代码并将 UI 反馈的责任推给我们自己我们确实解决了 MPA 的问题。我们有更多的控制权可以给用户一种更像自定义应用程序的感觉。但同时为了给用户提供他们想要的最佳体验我们必须负责路由、数据获取、变更和渲染逻辑。这样做有几个问题阻止浏览器默认行为 - 在路由和表单提交方面我们做得不如浏览器好。在此之前保持页面上的数据是最新的从来都不是一个需要考虑的问题但现在这在我们的客户端代码中占了一半以上。此外竞争条件、表单重新提交和错误处理都是隐藏 bug 的好地方自定义代码 - 有更多的代码需要管理而我们以前不必编写这些代码。我知道相关性并不意味着因果关系但我注意到一般来说我们的代码越多我们的错误就越多♂️代码重复 - 在渲染逻辑方面存在大量的代码重复。客户端代码需要以与后端代码在变更或客户端转换后渲染所有可能状态相同的方式更新 UI。后端拥有的 UI 必须在前端也可用。而且大多数情况下它们使用的是完全不同的语言这使得代码复用困难。进行客户端交互然后确保客户端代码更新的 UI 与整个页面刷新时所发生的情况相同这是非常困难的代码组织 - 对于 PEMPA这是非常困难的。由于没有集中存储数据或渲染 UI 的地方人们几乎可以在任何地方手动更新 DOM而且很难遵循代码规范这会减慢开发速度。就个人而言这大约是我刚进入 Web 开发世界的时候。回想起这段时光我心中充满了渴望的怀旧和颤抖的恐惧。单页应用 (SPA)没过多久我们意识到如果我们只是从后端删除 UI 代码就可以消除重复的问题。这就是我们所做的SPA你会注意到这个架构图几乎与 PEMPA 相同。唯一的区别是渲染的逻辑消失了一些路由代码也消失了因为我们不再需要 UI 路由只剩下了 API 路由。这是 Backbone、Knockout、Angular、Ember、React、Vue、Svelte 等的时代。SPA 架构文档请求SPA 文档请求由于后端不再具有渲染逻辑所有文档请求用户输入 URL 时发出的第一个请求都由静态文件服务器通常是 CDN提供服务。在 SPA 的早期HTML 文档几乎总是一个有效的空 HTML 文件其中包含用于“挂载”应用程序的 div idroot/div 。然而如今一些框架允许我们使用称为“静态站点生成”SSG的技术在构建时预渲染尽可能多的页面。客户端导航SPA 客户端导航数据变更SPA 数据变更这个架构中的其他行为与 PEMPA 相同只是现在我们主要使用 fetch 代替 XMLHttpRequest。SPA 的优缺点有趣的是在上面的架构行为中与 PEMPA 的唯一区别是文档请求的体验更差了! 那么我们为什么还要这么做呢?到目前为止最大的优点就是开发者体验。这是从 PEMPA 向 SPA 过渡的原始驱动力没有代码重复是一个巨大的好处。我们通过各种方法证明了这一改变的合理性DX 毕竟是 UX 的输入。不幸的是改进 DX 是 SPA 真正为我们所做的一切。我个人相信 SPA 架构有助于提高感知性能因为 CDN 对 HTML 文档的响应速度比服务器生成 HTML 文档的速度要快但在现实世界的场景中这似乎从来没有什么区别要归功于现代基础设施。可悲的现实是SPA 仍然存在一些与 PEMPA 相同的所有其他问题尽管有了更现代的工具使事情更容易处理。更糟糕的是SPA 还带来了几个新问题包大小 — 有点爆炸了。关于 JavaScript 对网页性能的影响请参阅 web Almanac 这篇详尽的文章。瀑布请求 — 因为所有用于获取数据的代码现在都在 JavaScript 包中我们必须等待它被下载后才能获取数据。与此同时还需要利用这些包的代码拆分和懒加载现在我们有了这样的关键依赖情况: document→ app.js→ page.js→ component.js→ data.json→ image.png。这最终会导致更糟糕的用户体验。对于静态内容我们可以避免很多这样的问题但 SSG 策略的开发者正致力于解决这些问题并乐意向我们出售他们的特定于供应商的解决方案。运行时性能 — 有这么多的客户端 JavaScript 要运行一些低功率设备很难跟上(可以阅读这篇文章https://v8.dev/blog/cost-of-javascript-2019 )。过去在我们强大的服务器上运行的程序现在可以在人们手中的微型计算机上运行。我知道我们用更少的能源把人类送上了月球但这仍然是一个问题。状态管理 — 这成了一个大问题。为了证明这一点我提供了可用于解决此问题的库的数量。以前MPA 会在 DOM 中渲染我们的状态我们只需要引用/修改它。现在我们只得到 JSON我们不仅要让后端知道数据何时更新还要保持该状态的内存表示是最新的。这具有缓存挑战的所有标志毫不夸张地说是软件中最困难的问题之一。在典型的 SPA 中状态管理占人们工作代码的 30-50% 。为了帮助解决这些问题并减少它们的影响已经有一些开源库出现了。自 2010 年代中期以来SPA 成为了开发网页应用的标准方法。现在我们已经进入了 21 世纪 20 年代一些新的想法即将出现。渐进增强的单页应用 (PESPA)MPA 的心智模型非常简单并且也具有更强大的功能。经历过 MPA 阶段并在 SPA 中工作的人们确实为我们在过去十年中失去的简单性感到惋惜。如果你考虑到 SPA 架构背后的动机主要是为了在 PEMPA 上改进开发人员的体验那么这一点就特别有趣。如果我们能够以某种方式将 SPA 和 MPA 合并到一个体系结构中获得两者的优点那么我们就有希望得到既简单功能又强大考虑到渐进式增强即使没有客户端 JavaScript基线也是一个功能性应用程序。考虑到渐进式增强即使没有客户端 JavaScript基线也是一个功能性应用程序。的东西。这就是渐进式增强单页应用。考虑到渐进式增强即使没有客户端 JavaScript基线也是一个功能性应用程序。因此如果我们的框架支持并鼓励渐进式增强作为核心原则那么我们的应用程序的基础就是 MPA 的简单心智模型的坚实基础。具体来说就是在请求/响应周期的背景下思考事物的心智模型。这使我们在很大程度上消除了 SPA 的问题。需要强调的是渐进式增强的主要好处不是“你的应用程序不需要 JavaScript 就可以工作”(尽管这是一个很好的附带好处)而是心智模型大大简化了。为了做到这一点PESPA 需要在 Prevent default 时 “模拟浏览器”。因此无论浏览器是发出请求还是发出基于 JavaScript 的 fetch 请求服务器代码都以相同的方式工作。因此当我们仍然拥有这些代码时我们可以在剩下的代码中保留简单的心智模型。其中一个重要部分是PESPA 模拟浏览器的行为即在发生变更时重新验证页面上的数据以保持页面上的数据是最新的。使用 MPA我们只需要重新加载整个页面。对于 PESPA这种重新验证发生在 fetch 请求中。记住我们在 PEMPA 中也有一个重要的问题代码重复。PESPA 通过使后端 UI代码和前端UI代码完全相同来解决这个问题。通过使用一个既能在服务器渲染又能在客户端上进行交互/处理更新的UI库我们就不存在代码重复的问题。PESPA您会注意到有一些用于数据获取、变更和渲染的小框。这些是用来增强的。例如挂起状态、乐观UI 等在服务器上无法实现所以我们将有一些只在客户端上运行的代码。但即便如此在现代UI库中实现也非常简单。PESPA 架构文档请求PESPA 文档请求使用 PESPA 的文档请求实际上与 PEMPA 相同。应用程序所需的初始 HTML 直接从服务器发送并且还会加载 JavaScript 以增强用户交互体验。客户端导航PESPA 客户端导航当用户单击链接时我们会阻止浏览器的默认行为。我们的路由将确定新路由所需的数据和 UI并为下一个路由需要的任何数据触发数据获取并渲染为该路由渲染的 UI。数据变更PESPA 数据变更PESPA 的变更是通过表单提交完成的。没有更多的 onClickfetch 废话但是命令式变更对于渐进增强是体验更好的比如当用户会话超时时重定向到登录页面。当用户提交表单时我们将组织浏览器默认行为。我们的变更代码会序列化表单并将其作为请求发送到与表单动作相关联的路由(默认为当前 URL)。后端路由逻辑调用数据库交互代码并返回成功的响应例如一个点赞操作或重定向例如创建一个新的GitHub repo。如果是重定向路由处理器会为该路由(并行)加载代码/数据/资产然后触发渲染逻辑。如果不是重定向路由处理器会重新验证当前UI的数据并触发渲染逻辑来更新UI。有趣的是不管它是内联变更还是重定向路由处理器都参与其中为两种类型的变更提供了相同的心智模型。PESPA 的优缺点PESPA 消除了以前架构中的大量问题。让我们一一看一下MPA 问题全页刷新 - PESPA 阻止浏览器默认行为使用客户端 JS 来模拟浏览器。从我们编写的代码的角度来看这与 MPA 没有什么不同但从用户的角度来看这是一种改进了很多的体验。UI 反馈控制 - PESPA 允许我们完全控制网络请求因为我们正在阻止浏览器默认行为并发出数据获取请求因此我们可以以任何对我们的 UI 最有意义的方式向用户提供反馈。PEMPA 问题阻止浏览器默认行为 - PESPA 的一个核心方面是它们的行为方式应该与浏览器在路由和表单方面的行为方式大致相同。这就是他们为我们提供 MPA 心智模型的方式。取消来自重新提交表单的请求正确处理无序响应以避免竞争条件问题以及显示错误以避免永远不会消失的微调器。这就是框架真正有用的地方。自定义代码 - 通过在客户端和服务器之间共享代码并拥有模拟浏览器行为的正确抽象我们最终大大减少了我们必须自己编写的代码量。代码重复 - PESPA 的部分想法是服务器和客户端使用完全相同的代码来渲染逻辑。所以没有重复可言。不要忘记挑战“进行客户端交互然后确保客户端更新的 UI 与我们刷新页面时获得的 UI 相同。” 对于 PESPA它应该始终通过我们开发人员的努力或考虑。代码组织 - 由于 PESPA 的浏览器模拟提供的心智模型应用程序状态管理不是一个考虑因素。并且渲染逻辑在网络两端的处理方式相同因此也不会出现随意的 DOM 变更。服务器/客户端阻隔 - 模拟浏览器的 PESPA 意味着前端代码和后端代码位于同一位置从而消除了阻隔并提高了我们的工作效率。SPA 问题包大小 - 使用 PESPA 需要一个服务器这意味着我们可以将大量代码移动到后端。所有 UI 需要的是一个可以在服务器和客户端上运行的小型 UI 库、一些用于处理 UI 交互和反馈的代码以及用于组件的代码。多亏了 URL基于路由的代码拆分我们终于可以告别拥有数百 KB JS 的网页了。最重要的是由于渐进式增强大多数应用程序应该在 JS 完成加载之前工作。目前 JS 框架正在努力进一步减少客户端所需的 JS 数量。瀑布请求 - PESPA 的一个重要部分是它们可以了解给定 URL 的代码、数据和资产要求而无需运行任何代码。这意味着除了代码拆分之外PESPA 还可以一次触发对代码、数据和资产的请求而不是依次等待一个。这也意味着 PESPA 可以在用户触发导航之前预先获取这些内容以便在需要时浏览器可以立即返回从而使整个应用程序的使用体验变得好。运行时性能 - PESPA 在这个部分有两件事情要做1他们将大量代码移动到服务器因此设备首先要执行的代码更少2由于渐进增强UI 已经准备好在 JS 完成加载和执行之前使用。状态管理 - 因为浏览器模拟我们提供了 MPA 心智模型所以应用程序状态管理在 PESPA 上下文中不是问题。这一点的证据是应用程序应该在没有 JavaScript 的情况下大部分工作。当变更完成时PESPA 会自动重新验证页面上的数据。有一点很重要无论有没有客户端 JavaScriptPESPA 的工作方式都不完全相同。无论如何这绝不是渐进增强的目标。只是大多数应用程序应该在没有 JavaScript 的情况下工作。这不仅仅是因为我们关心无 javascript 的用户体验。这是因为通过以渐进增强为目标我们大大简化了我们的 UI 代码。你会惊讶于我们可以在没有 JS 的情况下走多远但是对于某些应用程序来说没有客户端 JavaScript 就没有必要或不切实际。但是即使我们的某些 UI 元素确实需要一些 JavaScript 来操作我们仍然可以获得 PESPA 的主要好处。PESPA 的区别功能是基线 - 用于增强的 JS 未启用懒加载智能预取不仅仅是 JS 代码将代码推送到服务器无需手动复制 UI 代码如在 PEMPA 中透明浏览器仿真 (#useThePlatform)至于缺点我们还在研究中。但以下是一些初步想法许多习惯于 SPA 和 SSG 的人会感叹我们现在有服务端代码运行我们的应用程序。然而对于任何现实世界的应用程序我们都无法避免服务端代码。当然在某些用例中我们可以一次构建整个站点并将其粘贴到 CDN 上但我们为日常工作而开发的大多数应用程序都不属于这一类。与此相关的是人们对服务器成本的关注。这个想法是SSG 允许我们一次性创建应用然后通过 CDN 以非常低的成本将其提供给几乎无限数量的用户。这有两个缺陷。1) 我们可能会在我们的应用程序中使用 API因此这些用户仍然会在访问时触发大量我们最昂贵的服务端代码。2) CDN 支持 HTTP 缓存机制所以如果我们真的能够使用 SSG那么我们绝对可以利用它来提供快速响应并限制渲染服务器处理的工作量。人们离开 SPA 时遇到的另一个常见问题是现在我们必须应对在服务器上进行渲染的挑战。对于习惯于只在客户端上运行代码的人来说这绝对是一种不同的模型但如果我们使用的工具考虑到了这一点这就不是什么挑战了。如果我们没有这样做那么它肯定是一个挑战但是有一些合理的变通方法可以强制某些代码在我们迁移时只在客户端运行。正如我所说我们仍在发现渐进式增强型单页应用程序的缺点但我认为它的好处是值得的我们目前可以察觉到。我还应该提到尽管我们已经在相当长的一段时间内使用现有工具实现了 PESPA 体系结构的功能但在共享渲染逻辑代码的同时关注渐进增强还是新的。这篇文章主要感兴趣的是演示事实上的标准架构而不仅仅是平台的功能。PESPA 实践RemixPESPA 的领头羊是 Remix这是一个专注于 Web 基础和现代用户体验的 Web 框架。Remix 是第一个开箱即用的 Web 框架它提供了我所描述的 PESPA 提供的一切。在这方面其他框架也可以效仿 Remix 的做法。我特别注意到 slveltekit 和 SolidStart 在他们的实现中都采用了 PESPA 原则。我想还会有更多的元框架(同样元框架支持 PESPA 架构已经有一段时间了但是 Remix 把这种架构放在了最前沿其他的也在效仿)。当我们为我们的 PESPA 建立一个 Web 框架时情况如下在这种情况下Remix 充当了跨 Web 的桥梁。如果没有 Remix我们必须自己实现它才能拥有完整的 PESPA。Remix 还通过结合基于约定和基于配置的路由来处理我们的路由。Remix 还将帮助我们逐步增强数据获取和变更例如 twitter 上的点赞按钮以及用于实现诸如挂起状态和乐观 UI 之类的 UI 反馈。多亏了 Remix 中内置的嵌套路由我们也获得了更好的代码组织 Next.js 也在追求。虽然 PESPA 架构不需要嵌套路由但基于路由的代码拆分是一个重要部分。此外我们通过嵌套路由获得了更精细的代码拆分因此这是一个重要方面。Remix 证明我们可以通过 PESPA 架构更快地构建更好的体验。我们最终会遇到这样的情况完美的 lighthouse 分数最后就我个人而言我非常期待这个转变。同时获得更好的 UX 和 DX 是一种坚实的胜利。我认为这是一个重要的决定我对我们的未来感到兴奋。另外我也创建了一个库演示了使用 TodoMVC 应用程序在各个时代移动的所有代码! 你可以在这里找到它https://github.com/kentcdodds/the-webs-next-transformation本文译自epicweb.dev/the-webs-next-transition作者Kent C. Dodds往期精彩推荐2022 Web 年鉴 — JavaScript如果你有任何想法欢迎在留言区和我留言如果这篇文章帮助到了你欢迎点赞和关注。················· 若川简介 ·················你好我是若川毕业于江西高校。现在是一名前端开发“工程师”。写有《学习源码整体架构系列》20余篇在知乎、掘金收获超百万阅读。从2014年起每年都会写一篇年度总结已经坚持写了8年点击查看年度总结。同时最近组织了源码共读活动帮助5000前端人学会看源码。公众号愿景帮助5年内前端人走向前列。扫码加我微信 lxchuan12、拉你进源码共读群今日话题目前建有江西|湖南|湖北 籍 前端群想进群的可以加我微信 lxchuan12 进群。分享、收藏、点赞、在看我的文章就是对我最大的支持~
