过于保守使得 Javascript 生态系统很难跟上时代的步伐。
对于该行业的新手来说，关注新库、框架、概念和强烈观点的动态可能具有挑战性。
这是一个很好的提醒，默认情况下，使用“无聊”的技术，你熟悉的技术，并且是较晚采用者，通常是一个不错的选择。
言归正传，本文将带读者了解 Javascript 生态系统的最新发展，通过检查过去构建大型 Web 应用程序时的痛点来了解当前的状况。
不要专注于快速解决方案，而是从根本问题开始。 每种架构都会有不同的答案css简化，但也会有不同的权衡。 在本文的结尾，我们将列举流行框架的中级模型，例如 React、Svelte、Vue、Solid、Astro、Marko、Fresh、Next、Remix、Qwik 以及适用于当今环境的“元框架”。
汲取过去的教训，才能了解未来。 让我们回顾过去，展望未来趋势。 这一次，我们将重点关注小型项目中激发其他方法和思维方式的问题。
网页介绍
Web 最初由链接在一起的静态文档组成。 那时，人们可以提前计划一份文件，并将其放在笔记本中。 今天它最酷的地方在于任何人都可以访问它，而无需在场。
在此过程中，我们认为使这些文件动态化会非常酷。 因此，我们拥有 CGI 等技术，使我们能够根据请求提供不同的内容。 后来，我们有了像Perl这样的表达语言来编写这样的脚本。 它影响了最初为 Web 开发的 PHP。 PHP的创新之处在于将HTML直接链接到前端代码。 这使得以编程方式创建嵌入动态值的文件变得容易。
Web 最重要的突破之一来自于此：
<html>
<body>
Hello ConardLi !
</body>
</html>
具有易于嵌入的动态值：
<html>
<body>
Y2K? <?php echo time(); ?>
</body>
</html>
框架时代拉开序幕
这种动态页面很受欢迎。 我们可以轻松定制发送给用户的内容，包括启用会话 cookie。 在与数据库交互的语言生态系统中，基于服务器的模板框架已经存在。 有了这个框架，我们可以轻松地从静态页面开始，然后扩展到动态页面。
Web的发展日新月异，我们想要更多的交互体验。 为此，我们使用 Flash 等浏览器插件。 除此之外，我们会将 Javascript 片段“撒在”前端提供的 HTML 之上。
像 jQuery 和 Prototype 这样的工具的出现隐藏了 Web API 的复杂性并消除了浏览器之间的差异。
随着时间的推移，科技公司的规模不断扩大，但由于项目和开发团队的减少，在模板中添加更多的业务逻辑是很常见的。
编写用于将处理后的数据传输到服务器模板语言的服务器代码。 模板通常充当业务逻辑的“混合体”来访问全局变量。 由于SQL注入等攻击越来越普遍，安全问题也日益突出。
最后，论文《Ajax：一种 Web 应用程序的新方法》（Ajax：A New Approach to Web Applications）为我们带来了 Ajax 技术。 现在使用 Ajax 技术可以做的新事情是异步而不是同步更新页面。 这些模式因第一批小型客户端应用程序（例如 Microsoft Maps 和 Microsoft Docs）而得到普及。 后来，我们开始听说 Web 分发对桌面式软件的影响。 与在商店购买光盘的软件相比，这是一个重大改进。
JavaScript 的增长
当 Node.js 出现时，它带来的新功能是用与后端相同的语言编写前端。 所有这些都是开发人员熟悉的异步优先模式。 以前是压倒性的，现在也是。 随着越来越多的企业上线，竞争优势在于快速交付和迭代的能力。
Node.js 生态系统指出了大型单一用途包的重用，您可以利用这些包开箱即用地完成工作。
后端和前端分离
我们更渴望一个能够与桌面和移动设备竞争的网络。 如今，我们已经拥有一系列可重用的“小部件”库和工具，例如 jQueryUI、Dojo、Mootools、ExtJs 和 YUI 等。
我们越来越关注这些小工具，但后端的工作也越来越多。 这通常会导致后端和前端模板重复。 像 Backbone 和 Knockout 这样的框架以及许多其他框架出现了。 它们通过 MVC、MVVM 等框架减少了后端的关注点分离。但是，该框架与我们收集的所有小部件和 JQuery 插件兼容。 添加结构有助于增强所有后端代码。 并且可以加快前端模板的交付速度。
我们一直在编写微调的 DOM 操作来更新页面并保持组件同步。 这个问题并不简单，与数据同步相关的错误非常常见。
在微软的支持下，Angular应运而生。 它通过使 HTML 更加动态来促进生产力的提高。 它配备了单向数据绑定和受电子表格启发的反应系统。 这种声明性单向绑定消除了许多必须更新的模板。 这是一件好事，可以让我们的工作更有效率。
随着规模的扩大，跟踪变化变得越来越困难，通常会导致性能下降。 更新周期发生，抢占主线程（明天像 Svelte 这样的库可以维护单向绑定，但代价是增加它们的缺陷）。 除了联通设备的普及之外，这种提高生产力的框架也加速了后端和前端的分离。 这为探索指出这些前馈的不同架构铺平了道路。
这是 JAMstack 理念的主要部分，这意味着尽早预生成 HTML 并通过 CDN 提供服务。 当时，这与提供静态文档相比是一种倒退。 但现在，我们拥有基于 git 的工作流程、强大的 CDN 基础设施以及可以与独立 API 交互的前馈后端，而无需远距离的中央服务器。 与运营服务器相比，将静态资产放在CDN上要划算得多。
如今，Gatsby、Next 等工具都利用了这一概念。
React 的兴起
快速进入大科技时代。 我们正在努力追风，改变旧有的生活方式。 对于进入该行业的人来说，Javascript 很大，构建由独立前端驱动的前馈 SPA 已成为现实。
在 Facebook，React 诞生时就面临着一些挑战。
数据频繁更改时的一致性：保持许多小部件同步仍然是一个重大挑战。 由于数据流缺乏可预测性，这是一个大规模问题。
组织规模：优先考虑上市时间和速度。 对于新开发人员来说，能够快速但高效地上手至关重要。
React 诞生了，你可以做的一件很酷的新事情就是以声明方式编写后端代码。
后端关注点分离是众所周知的自省，原有的MVC框架很难扩展。 人们不喜欢从模板到 Javascript 驱动的 JSX 的转变。 我们大多数人都接受它。
组件模型允许前馈独立后端团队可以更轻松地在独立组件上并行工作。 作为一种架构，它允许组件分层。 从共享谓词到构成页面根的“有机体”。 双向数据流使数据流更易于理解、跟踪和调试。 这增强了以前无法实现的可预测性。 虚拟DOM就是我们可以编译函数来返回用户界面的描述，让React解决这个困难。 这可以防止数据频繁更改时出现的一致性问题，但有助于更人性化的模板组合。
大规模 React 达到了 CPU 和网络的极限
React 如此受欢迎，以至于它已经成为行业标准，即使对于不想要其功能的网站也是如此。 在规模的远端，我们开始听到一些限制。
CPU遭受很大打击
DOM 是 React 模型的一个问题。 浏览器并不是为了在连续的渲染周期中不断创建和销毁 DOM 节点而构建的。 就像任何可以通过引入新的间接级别来解决的问题一样，React 将其具体化为虚拟 DOM。
人们只有在 100 纳秒内感知到反馈才能感觉更顺畅。 当执行诸如滚动页面之类的操作时，它要低得多。 当与单线程环境结合时，这些优化已成为高度交互应用程序的新困境。 当虚拟 DOM 和真实 DOM 之间发生协调时，小型交互式应用程序将对用户输入变得无响应。 像“长期任务”这样的术语开始出现。
这导致 React 在 2017 年被重写，为并发模型奠定了基础。
降低运行成本
同时，更快的连接意味着传输更多的代码。 当浏览器运行大量Javascript时，启动速度慢就成为问题。 我们开始注意到所涉及的所有运行时成本，不仅在 HTML 和虚拟 DOM 中，而且在我们编写的 CSS 形式中。
组件模型简化了我们使用 CSS 的体验。 我们可以将样式与组件放在一起，从而增强可删除性。 对于那些之前不敢删除CSS代码的人来说，这是一个非常好的属性。 我们仍在处理的级联和所有具体问题都通过 JavaScript 库中的 CSS 来体现。
第一波库通常会带来固有的运行时成本。 我们需要等到组件渲染完成之后才能将这种样式注入到页面中，这会导致 JavaScript 包中出现样式问题。 从规模上看，糟糕的性能通常会付出很大的代价，我们已经注意到了这一代价。 这导致 JavaScript 库中出现了新的 CSS，这些库通过使用智能预编译器提取样式表，此类库专注于没有运行时开销。
低效的网络和渲染阻塞组件
当浏览器呈现 HTML 时，CSS 或脚本等呈现阻塞资源会阻止显示 HTML 的其他部分。 在组件层次结构中，父组件通常会成为子组件的渲染障碍。
在实践中，许多组件依赖于数据库中的数据和 CDN 中的代码（通过代码分割）。 这通常会导致网络请求拥塞瀑布式下降。 渲染完成后，组件将获取数据并解锁异步子组件。 然后他们将获得所需的数据并重复该过程。 “下拉地狱”或累积布局倾斜是很常见的，这是加载 UI 时屏幕上出现的变化。
React 后来发布了 Suspense，让页面的加载阶段更加流畅。 而且，默认情况下，这不会阻止正在进行的网络级联。 Suspense 支持“一边渲染一边获取数据”模式。
Facebook 如何解决这个问题？
我们将继续绕道看看如何大规模缓解 React 的一些权衡。 这将有助于在新框架中构建模式。
在React中，虚拟DOM的运行时成本是难以避免的。 并发模式是一种解决问题的方法，可让您在高度交互的体验中保持响应能力。
在 JavaScript 中的 CSS 领域，使用了一个名为 Stylex 的内部库。 当渲染数千个组件时，这可以保持人性化的开发人员体验，而无需运行时成本。
Facebook 使用 Relay 来避免顺序网络瀑布问题。 对于给定的入口点，静态分析可以准确确定要加载的代码和数据。 这意味着代码和数据都可以在优化的 graphQL 查询中并行加载。
这比初始加载和 SPA 转换的顺序网络瀑布要快得多。
基本问题之一是交付独立于用户的 JavaScript。
当您具有针对特定类型和用户组的 A/B 测试、功能标记和编码经验时，这会很困难。 还有语言和区域设置。 当代码有很多分支时，静态依赖图无法看到在实践中针对特定用户组一起使用了哪些模块。
Facebook 使用由人工智能驱动的动态包装系统。 这利用其紧密的客户端-服务器集成来根据运行时的请求来估计最佳依赖关系图。 这与根据优先级分阶段加载包的框架相结合。
生态系统的其他部分又如何呢？
Facebook 拥有复杂的基础设施和多年来建立的内部库。 如果您是一家小型科技公司，您可以投入大量资金和资源来优化这种大规模的权衡。
这为后端产品开发人员创造了成功的深渊，使他们能够在保持性能的同时完成任务。
我们大多数人都不会构建 Facebook 规模的应用程序。 然而，对于许多小型企业来说，性能是一个话题。 我们可以向这个模型学派学习，比如：获取尽可能多的数据、并行化网络、使用内联需求等。
小型科技公司经常在内部推出自己的应用程序框架。 不同的用户存储库中留下了大量的解决方案。 这导致了很多Javascript生态系统疲劳和框架疲劳。
JavaScript 的世界：群龙无首
还在我们身边吗？ 我们正处于SPA时代。 这就是这个行业从业者面临的现状。
React 是无可争议的亚军，但我们看到了巨大的选择。
React 提供了一个层。 它将其他必要的层留给了生态系统，导致路由、状态管理、数据获取等所有重要方面的混乱，每个方面都有自己的概念和 API。
不可变与可变、带有类的 OOP 与函数式 OOP、争论和库都在如火如荼地进行。
如今，许多开发商都受到不确定性的困扰。 他们不知道该做什么或如何建造。
起来，起来，React 替代品！
组件有粘性。 但运行时成本、Javascript 驱动的 JSX 以及复杂性都存在争议。 许多并非来自小型科技公司的草根替代方案已经获得了广泛接受。 我们先来介绍一下这个方法：
维埃
当人们评估迁移到 Angular 2 或 React 时，Vue 填补了入门门槛较低的空白。 为什么需要担心复杂的 webpack 配置。 您可以从 CDN 下载并开始使用对许多开发人员来说直观的模板构建组件。
核心团队可以使用路由和样式等核心组件来减少决策疲劳。 它还通过静态剖析模板来减轻 React 协调算法的各个方面，以实现驱动运行时的优化。 这称为编译器通知的虚拟 DOM。
斯韦尔特
Svelte 开创了预编译消除运行时复杂性和开销的方式。
我们的愿景是拥有一个能够自行编译并将输出简化为最小的普通 JavaScript 的框架。 所有这些都基于声明性组件和熟悉的可变 JavaScript 风格，以保持现代的创作体验。 Svelte 完全避免使用虚拟 DOM，因此它不受 JavaScript 编写不可变风格的约束，JavaScript 可以用于执行更新状态等操作。 对于许多人来说，这是在网络上构建事物的更简单、更合理的模型。
坚硬的
Solid 具有受 Knockout 启发的直接且可预测的反应模型。 与 React 一样，它也阻止使用模板来简化函数的可组合性。
React 采用不断重新渲染世界的方法。 Solid 仅渲染一次，并使用精益反应系统进行细粒度更新，而不会降低虚拟 DOM 开销。 Solid 看起来就像我们许多 React 开发人员想要使用 hooks 的新代码。 它的 API 实际上更加人性化，但在很多方面都很流畅，例如钩子的依赖字段，强调细粒度的反应性和可组合谓词。
交流互鉴
每个框架都有很多东西要说。 每个人也会在自己的基本模式和偏好上做出不同的权衡。
事实上，进化往往是由人类意志决定的。 尝试不同的解决方案来解决当前的痛点，每个框架互相学习的东西很少。 其中一大主题是精简和简化。 将事物从运行时转移到编译时是产生“Reactforget”的主题之一，该功能有望消除记忆的需要。 它们的共同点是都解决了文件的交互部分。 正如我们所看到的，这是一个以易于扩展的方式解决的具有挑战性的方面。
与此同时，我们听说了纯客户端渲染的权衡。 加载页面时，空白的蓝屏需要更长的时间。 对于连接的设备和网络来说，这是一场灾难。 对于许多网站来说，在不提高性能的情况下加快页面打开速度已成为主要的竞争优势。
我们采取了这一步，并正在寻找通过首先在服务器上渲染内容来提高渲染速度的方法（我后来发现这是一种权衡）。 这种最初的回归引发了新一波“元”框架和 HTML 优先的后端框架。
新一代JavaScript Web框架
我们不会停止寻找。 我们所有任务的终点就是我们的开始。 这也是我第一次知道这个地方。
受到 PHP 的启发，Next 着手简化创建静态页面以推送到 CDN 的过程。 它还解决了在 React 应用程序中使用 SSR 的棘手问题。
它还提供了一些关于使用基于文件的路由构建应用程序的欢迎建议。 还有一些其他不错的功能。 从那时起，又一波“元”框架被创建。 对于 Vue，我们在 Nuxt 中有一个类似的框架。 Svelte的Sveltekit，以及正式推出的SolidStart。
这是服务器优先，集成了 Web 框架和人体工程学的所有部分。 人们长期以来关心的不仅仅是互动元素。
对话的重点是改善用户体验和开发者体验，而不是交流。
MPA的反击
多页面架构从服务器提供 HTML，其中导航是全页面刷新。 快速启动对于许多网站来说至关重要，尤其是那些无需登录的网站。 它与搜索排名和跳出率等因素直接相关。 对于许多低交互性的网站和应用程序来说，使用像 React 这样的客户端渲染库是多余的。
对于许多人来说，这意味着翻转剧本。 先做HTML而不是先做Javascript，MPA比SPA好，并且默认为零Javascript。
Marko、Astro、Fresh、Rocket 和 Enhance 等框架都采用了这些技巧。 与某些元框架相比，路由器保留在服务器上，而不是让客户端的路由器在第一次加载后接管。 在 Javascript 生态系统中，这是对不久之后 Node.js 推出的基于服务器的模板的回归。
本轮MPA与前几代有所不同。 “Sprinkles”是用基于组件的模型编写的，一般使用岛模式。 在后端和前端代码中使用相同的语言。 经常共存于同一个文件中。 这解决了添加一些交互性时后端和前端构造不同的重复样板代码的问题。
渐近改进回归
Remix 带来了 React 生态系统逐步改进的回归。
从技术角度来看，Remix 是 ReactRouter 的编译器，并且与其他新兴元框架一样，是边缘兼容的运行时。 它通过嵌套布局和数据获取 API 解决了 Facebook 通过 Relay 大规模解决的相同挑战。
这允许并行检索初始代码和数据。 这是使用Suspense实现“渲染采集”模式的良好前提。 强调渐进式改进意味着其 API 基于 Web 标准，其数据突变故事基于 HTML 表单。
而不是通过连接风暴处理程序发出必要的获取请求。 您呈现表单，将数据传递给在服务器上处理这些数据的操作函数（通常在同一文件中）。 受到 PHP 的启发。
与 Next 类似，应用程序可以像传统的服务器渲染 MPA 一样缩小规模，无需 Javascript 即可工作，也可以纵向扩展为基于每页的交互式 React 应用程序。
Remix 还提供了许多 API 和模式，用于处理诸如开放式 UI 更新、静态条件处理和高贵降级等事务，这些都是您期望从专注于最终用户体验的深思熟虑的框架中获得的所有功能。
混合未来
不要与 Quic 合约混淆。 Qwik 框架旨在最大限度地减少不必要的 Javascript。 实际上它的 API 看起来很像 React，但它的方法与其他元框架不同，因为它专注于水合过程。
就像您可以暂停虚拟机并将其连接到不同的化学机器一样。 Qwik 将这一想法应用到服务器和浏览器之间发生的工作中。 其“可恢复”水合概念意味着您可以在服务器上启动某些内容，然后在客户端上恢复它css简化，而无需任何返工。 这与部分水合形成鲜明对比，部分水合发生时，Qwik 试图首先阻止其发生。
这是一组有趣的观点，允许通过服务器和客户端的紧密集成来实现这些动态捆绑和服务。
这个概念开始模糊 MPA 和 SPA 之间的界限，应用程序可以从 MPA 开始并动态过渡到 SPA。 有时（用更流行的说法）它被称为“过渡应用程序”。
边缘渲染
与此同时，前端基础设施和托管也在不断完善。 CDN 的优势使我们的 SPA 的静态资产服务变得简单而快速。 将运行时和数据转移到边缘现在也是可行的。 这是在浏览器之外创建一个新的运行时层，但仍然尽可能靠近用户。 这使得将当前在浏览器中完成的许多事情移回服务器变得更加容易。 同时，这样做所带来的网络延迟的选择也得到了一定程度的缓解。
像 React Server Components 这样的想法正在探索将服务器组件的输出从这一层流式传输到浏览器的概念。 Deno 和 Bun 等新的 Javascript 运行时不断涌现，旨在简化 Javascript 生态系统，并专为边缘运行时的新世界而构建，并针对速度和快速启动时间进行了优化。
这也导致应用程序框架采用标准 Web API 在这一层进行操作。 随着无服务器功能和流架构的探索。
流媒体是这里的一个大话题。 它允许提前刷新 HTML，以便浏览器可以在收到 HTML 时逐渐呈现它。 在前端同时获取任何数据的同时，开始处理任何阻止渲染的资源，例如 CSS 和 JS。 这有助于并行许多其他顺序往返。
总结
这篇文章说了这么多，但实际上只是触及了表面。 对于本文中提到的最佳框架、架构或模式，没有一刀切的答案，而且还有无数其他我们没有提到的答案。 这仍然是特定指标的权衡。 了解如何权衡取决于您正在构建的内容、您的用户是谁、他们的使用模式以及围绕关键用户体验的任何其他要求（例如性能预算）。
对于我们大多数人来说，真相介于两者之间。 新一波框架和创新的伟大之处在于，它们提供了根据需要扩大和缩小规模的杠杆作用。 对于这些进入这个行业的人和这些有经验的人来说，投资基本面总是一个不错的选择。
框架的演进逐渐将原生Web推得更远，消除了之前对框架的需求，也减少了之前的选择，让我们越来越多地采用它的原生特性。
-结尾-
![css痘-痤疮是怎么产生的[图片]](https://www.wkzy.net/wp-content/themes/ceomax/timthumb.php?src=https://www.wkzy.net/wp-content/uploads/2024/05/1714562068153_1.webp&h=200&w=300&zc=1&a=c&q=100&s=1)
