重新思考现代网络

前端出现工程问题！

从增长率到技术魔法，这个领域几乎从各个方面都打造出了最令人羡慕的工具生态系统，并且在其每一个举措上都体现了令人难以置信的思想领导力。

但其底线是：

• 我们网站的平均性能只会下降！
• 平均开发人员的生产力正陷入停滞！

事实证明，所有这些“充满活力的生态系统”并没有真正转化为用户方面更“易于访问”、“功能更强大”的应用程序，也没有转化为开发人员方面的更多“速度”和“生产力” ！

你越接近前端的瓶颈，以及其中有多少是由工具引起的，你就越想知道我们用工具制造的问题是否比我们解决的问题还多！

目录

• 违反直觉的方程式！
  • ...在用户方面
  • ...在开发人员方面
• 回顾：范式转变！
  • ...从 HTML 到 JavaScript
  • ...从 Web 平台到抽象
• 迈向更快的网络：新的探索！
• 介绍：Web 原生开发！
  • 和我一起探索...
• 笔记
• 致谢
• 参考

违反直觉的方程式！

想想这是多么的弄巧成拙……

...在用户方面

考虑到现实世界的网络和设备性能因素，性能提升始于传输更少的字节，尤其对于 JavaScript——你最昂贵的资产而言。（事实上，所有额外的功能，例如即时导航和过渡效果，都会让你的用户感到愉悦，但这首先需要你的应用具备可访问性！）

不幸的是，SPA 框架虽然以此为主要诉求，但其工程模型却走向了相反的方向：更加倾向于 JavaScript！它们可能遵循不同的编程范式……但都秉持着相同的JavaScript底线！

• [HTML, CSS, JS]>>Build_Step例如[JS, JS, JS]Svelte、Vue
• [JS, JS, JS]>>Build_Step例如[JS, JS, JS]React

这里的最终捆绑包是框架捆绑包、基本JS 以及页面结构、内容和样式引起的（通常较大）JS 的总和- 这是前端可怕有效载荷的明显数学！

现在，你的应用程序的全部重量都集中在 JavaScript 上……而它的非 JS 方面——页面结构、内容和样式——现在都用 JS 来处理，这说明你对现实世界的定位是错误的！随着你的应用程序逐渐成熟，随着重量的增加，性能开始下降，你很快就会明白自己正处于多么危险的境地！

毫不奇怪......“高度优化”、“可访问”、“功能性”应用程序的想法很快就崩溃了！

Alex Russell在《2017 年真实世界 Web 性能预算》（此处）中对此进行了报告，其中提到：

“我见过一些团队，他们刚刚在现代技术栈上完成了重建，当我们向他们讲解在现实条件下使用‘更好’、‘更快’的体验时，他们畏缩了一个小时。”

Tim Kadlec 还根据现场经验指出：

“目前很明显的是：如果你使用框架来构建你的网站，那么你就需要在初始性能方面做出权衡——即使在最好的情况下也是如此。[...]如果你要使用其中一个框架，那么你必须采取额外的步骤来确保你不会在此期间对性能产生负面影响。”

这个问题在讨论中经常被忽略，但许多人最终却遭遇了更多由工具引发的性能问题！这完全适得其反！

...在开发人员方面

性能的关键在于能够以最小的开销控制复杂性。这就要求管理复杂性的抽象/工具必须遵循“‘首先不造成损害’的原则……确保在有开销的情况下，你的生产力至少不会比没有开销的情况下低。”（Swyx）

问题是：我们在管理复杂性方面真的进步了吗？我们感觉自己正被比以往任何时候都更加复杂的问题淹没，一整套深奥的编程概念取代了过去“HTML”类型的问题，此外还有一堆编译器——它们本身还必须迎合各种新的范式、神奇的语法和方言！

现在，我们必须严格控制代码级的复杂度，并付出编译步骤的代价（使用Webpack和Babel（或类似的工具），以及大量的配置、插件和扩展），才能拥有一个可以正常运行的网页！但这还不是全部，我们还必须适应令人费解的运行时行为（包括钩子和相关函数），并通过难以理解的代码转换进行调试！

到了这一步……你现在完全是在攻克一个全新级别的难题！一切易事又变难^了！

Jelan分享了她的挫败感：

“使用大多数常见前端框架时，需要面对层层递增的复杂度，这让我越来越沮丧。我已经到了这样的地步：在大多数情况下，为了达到目的，不择手段似乎已经不再合理了。”

Chris Coyer对此给出了一个恰当的比喻：

讽刺的是，虽然大量的工具增加了复杂性，但它们被使用的原因却是为了对抗复杂性。有时候，这感觉就像为了解决蛇的问题而把美洲狮放进森林里。现在你又遇到了美洲狮的问题。

^{看看是什么让你掉进了“成功2”}的陷阱，让你的复杂性比一开始还要高！（在“本质/意外” ^3级量表中，你的“意外”（工具引发的）复杂性超过了你的“本质”（实际问题空间）复杂性！）再说一次，这完全适得其反！

如果有什么是显而易见的，那就是每次都会破坏体验的一件事：“JavaScript”；这一次，不是传统的“HTML，CSS，JS”方法中的“JS”，而是我们新的“全 JS”等式中的“JS”：

• “全 JS底线”工程模型 - 将所有页面结构、内容和样式都交给 JS（Build_Step => [JS, JS, JS]）！
• “全JS一线”工程模型——默认使用JS来创作页面结构、内容和样式（[JS, JS, JS] => Build_Step）！

回顾：范式转变！

早在 2013 年 3 月， React 就发布了“重新思考最佳实践”的演讲，预示着前端新时代的到来，而这在很大程度上建立在一条看似普遍适用的公理之上：传统的 Web 很糟糕；应该抽象化它！Web 应用领域中所有“传统”的东西——从编写到运行时——都注定要被抽象化或重新设计——传统的“HTML、CSS、JS”和 DOM 成为这场战争的首当其冲的牺牲品，而 JavaScript 则成为了新的默认语言！

一个个由独立技术组成的全新生态系统已经形成，每个生态系统都与网络基本面保持着一种虚假的二分法，并对此保持防御态度！让我们来深入了解一下这个思考过程……

从 HTML 到 JavaScript：

• Mike Turley（关于 JSX）：JavaScript 为何正在吞噬 HTML
• Mark Dalgleish（关于 CSS-in-JS）：一种统一的样式语言

从网络平台到抽象：

• Rich Harris：我为什么不使用 Web Components
• Ryan Carniato：也许 Web 组件不是未来？

...从 HTML 到 JavaScript

令人惊奇的大规模外逃随之而来！

“HTML 最近一直是 Web 开发社区的笑柄。[...] 我们正处于 Web 开发领域一个非常严重的问题之中，HTML 正在被 JavaScript 取代，被遗忘在历史的长河中。” Mark Steadman 写道。

React臭名昭著的运动最初可能只涉及JSX，后来又涉及 CSS-in-JS！但不幸的是，这场运动席卷并颠覆了前端工具领域更广泛的思维方式！现在，到处都有各种 JS 优先的议程——甚至在 Web 平台提案板上也是如此！

考虑提名：

• HTML 模块-针对“HTML”提出的“JS-first”导入机制。
• CSS 模块- “CSS” 的“JS-first”导入机制。

慢慢地，一些属于 HTML 问题空间的内容现在开始以 JavaScript 功能提案的形式出现 - 有时甚至是彻头彻尾的抢注 HTML！

但为了避免你问“HTML 模块”之类的东西为什么不能解决问题：也许它们能！但那些肯定不是“HTML”类型的问题，而是 JS 优先世界中“意外限制”类型的问题！这类提案只是走上“非传统”道路的征兆；你必须无休止地构建 JS 优先的桥梁，为所有其他 HTML/CSS 内容寻找 JavaScript 隐喻，并希望网络的其余部分都涂成黄色！（你可以清楚地看到，这些不是功能，而是达到目的的一种手段！）请注意，这甚至冒着将所谓的通用DOM 无关编程语言与 DOM紧密耦合的风险！（看看 HTML 模块在原则上是如何折磨 JavaScript 语言来生成 DOM 原语的！）

事实证明，不仅有更多 JavaScript 通过后门被偷偷带入，还有更多 HTML 和 CSS 被丢弃！（这或许才是最大的危害！）想想看，规范中移除（而不是改进）HTML导入，转而使用ES6 模块，或者现在可能是上面抢注名称的HTML 模块！用Brad Frost 的话来说，只是“以 JS 为中心的时代思潮赢了”而已！

有人建议移除 Scoped CSS，转而使用基于 Shadow DOM 的 CSS 吗？我们稍后再讨论！

JS-first 就这样点燃了 HTML 领域许多优秀的思考，最终让它们在 JavaScript 中重生！这是一个不可逆转的、全押的命题！

更何况，HTML 中那么多严重缺失的功能甚至在提案委员会的雷达上都找不到！放眼望去，HTML 还有多少“开发者心智份额”来推动这些功能呢？

这种现状根深蒂固，如果你敢于挑战现状，专注于真正的UI开发技能，这意味着更少的工程设计，你就会发现自己身处“大鸿沟”的边缘地带，甚至有可能失去职业生涯！（所以，许多开发者考虑到账单要付，不得不违背自己的意愿默许了！）

...从 Web 平台到抽象

突然间，平台被废弃了！

源于对 Web 平台的轻蔑和误解，现代抽象的焦点似乎变成了重新设计Web 语言、复制平台功能和 API，以及重复浏览器的工作！对于独立技术而言，使用 Web 平台的整个想法仍然缺乏吸引力。用Alex Russell 的话来说，“框架作者的动机与兼容性并不一致”。我经常看到“Web 标准”只有在成为重大新闻或性能提升成为激励因素时才会被吹捧！

回顾 React 及其生态系统多年来如何保持独立，Mikeal Rogers 说道：

我记得 React 刚发布的时候，一切都围绕着 DOM diffing。它的价值就在于虚拟 DOM。后来我们把 DOM 弄得很快，现在谁还会在乎呢？但我们仍然在使用 React，原因……我不知道。[...] 现在我们有了 Web Components，他们无法采用，因为他们有自己的模式，所以我们无法从平台获取这项功能升级。[而且] 我觉得还有很多这样的例子，平台开始迎头赶上，而框架却跟不上。—— JS Party – 第 89 集 | 更新日志

我们似乎只是倾向于交易“规范”，而在抽象世界中寻找“种类”！

那么，框架优先文化的悲哀之处又是什么呢？我们对独立技术和边缘生态系统投入得越多，就越无法真正了解我们面临的问题，也越无法真正抓住推动 Web 发展的所有机会！事实证明，HTML 及其生态系统至今仍处于发展不足的状态，而框架 Web 却持续蓬勃发展！现在，用原生 HTML 和 DOM 构建任何东西，几乎肯定会像身处沙漠一样陷入困境：

令人沮丧的是，如今大多数实用工具都是为 React 项目打造的，并且/或者需要 React 知识才能设置和使用。这把我们这些并非在所有项目中都使用 React 并且仍然喜欢使用原生 React 的人挡在了门外。—— Sara Soueidan

您只是意识到每个人似乎都已经脱离了真正的“问题空间”类型的问题，并陷入了“抽象”问题中，只给我们留下了针对非常常见问题的特定框架解决方案！

事实证明，对于那些渴望体验原生 Web 简易性的人来说，工具不足仍然是一个真正的障碍。（这也应该成为雷米·夏普提出的一个有效挑战：是什么阻止了你今天使用（那种）方法？）

工具领域出了这么多问题，接下来发生的事情也在意料之中：整个社区对 Web 基础知识的理解出现了严重的盲点！现在，各种基本真理都在被争论，“最佳实践”正在变得麻木（你好，Pete），标准在开发者心中的地位也越来越低！（不妨做个调查：你对 Web 标准了解多少？）

去看看那些典型的框架开发者——即使是他们职位的资深人士；去看看下一代开发者的典型学习路径；再去看看招聘网站上现代前端职位的描述！令人惊讶的是，现代开发者的职业生涯已经很少关注 Web 技术本身，而是全神贯注于“最流行框架的复杂性”，用Frédéric Bonnet 的话来说！看到了吗？

现在，破坏性的信息差距和文化侵蚀^也正在向我们袭来！

可以这么说，过去十年，我们的生活与传统智慧格格不入，几乎全部时间都花在了HTML交易上——而且一路上我们破釜沉舟——不可逆转地押注于JavaScript；我们背弃了Web平台，对抽象概念的未来不屑一顾！然而，只有少数人真正在谈论这十年来几乎不可逆转的转变……

在将前端提升到“严肃代码”的境界时，我们不仅让事情变得过度设计，而且还烧毁了我们最初用来到达这里的所有梯子。——劳拉·邦斯

迈向更快的网络：新的探索！

随着框架时代的弊端日益凸显，这十年的花里胡哨已然失去吸引力！人们开始认清现实，许多人甚至主动放弃人生赌注，寻求理智，甚至冒着被人用火把和草叉“招惹”的风险！

• Hajime Yamasaki Vukelic：是什么让我再次编写 Vanilla JavaScript
• Sam Magura：我们为什么要放弃 CSS-in-JS

但是工具层的理念又如何呢？现在是时候重新思考了吗？这取决于你要求的重新思考程度！

一方面，人们一直在努力识别和解决当前系统中固有的开销。（当然，这并不是为了重新思考整体的 JS 优先理念！）

例如，React 及其合作伙伴意识到，将应用程序仅以 JavaScript 的形式交付给用户并没有什么好处，于是他们又回归到能够通过网络发送 HTML 的想法。这需要进行重大的架构改造（例如React 18 的流式 SSR 架构）；这补充了使用Gatsby等构建工具生成静态站点的现有理念。服务器端渲染 ( SSR ) 和静态站点生成 ( SSG ) 对现状来说是一项巨大的壮举！

所以，现在，HTML 和渐进式增强再次成为“要么全 JS，要么全无”阵营的诱人选择。（事实上，Remix已经把这当成了新的炫耀资本！用它自己的话说：谁知道呢？）总而言之，这里所有的新尝试都代表着一个新的游戏计划：回归基础；在最初的尝试上有所妥协，但最终还是为了更大的利益：迈向更快、更实用的前端！

另一方面，新一波创新浪潮正占据着中心舞台，其雄心勃勃的姿态远超目前漫长而痛苦的回归基础之路：这一次，它从一开始就提出了彻底的 HTML 优先、“渐进增强”架构的理念！（SitePen Engineering 提供了完美的HTML 优先前端框架入门指南，其中包括Qwik、Marko、Astro、11ty、Fresh和Enhance；绝对值得一看！）

我觉得这特别有意思，因为终于，每个人都能明白，更快的网络速度并非像我们多年来一直认为的那样，需要大量计算，而且难以实现！现在比以往任何时候都更清楚，我们一直以来是多么的幻想……我们固执地执着于 JS，却又偏爱 HTML，尽管这种做法很巧妙！你还会意识到：网络上的 HTML 并不一定是什么“现代”智慧，也不是什么了不起的创新，更不是什么壮举！毕竟，这可是网络从诞生之初就有的东西！（有人从 PHP 诞生第一天就开始用流式服务器渲染 (SSR) 了吗？）

令人遗憾的是，在工具方面，我们似乎总是事后诸葛亮，但多亏了新一波框架的出现，它们公开挑战了现状！我们终于到达了一个充满希望的阶段：以一半的价格拥有“可访问”、“功能齐全”的应用程序！（希望与之相关的是，自 JS 诞生以来，我们首次记录到JavaScript 交付给用户的数量增长幅度没有那么剧烈！）

那么现在好了么？嗯，还没到时候！

但我们似乎只实现了一半的想法：将页面以 HTML 形式发送，但以 JS 形式编写；解决了用户端的权衡问题及其开销，但在开发者端保持不变！明白了吗？在我们新的 HTML 优先方程式中，大部分“HTML”仍然是工具生成的 HTML，而不是手工编写的 HTML；与之前一样，HTML 被视为编译目标，一个实现细节……你需要抽象出一些好的 DX！“工具”仍然是前端实现其“HTML”端的主要手段！

这种将“HTML”置于编译墙之后，以支持抽象的想法，也开始说明我们可能正以一种新的方式遭受着平台长达十年的盲点——拥抱HTML仅仅是为了性能激励，而不是为了使用平台的整体理念！让我们直接说出来：前端仍然没有与使用平台保持一致，让遗留工具得到应有的休息，并回归到简洁的风格！

Chad Fowler 指出，这种现象根深蒂固：

“随着年龄的增长，我越来越意识到科技领域需要解决的最大问题就是让人们停止让事情变得比实际更困难。”

那么，何不大胆尝试……拥抱整个 Web 平台？现在，我们不仅能提升用户和开发者的性能，还能做更多：释放 Web 的全部潜力！（还有什么比这更雄心勃勃的目标呢？）

其实，这就是我们来这里的原因！我们可以直接跳到精彩部分吗？

介绍：Web 原生开发！

不要将其视为一个新框架或某种反框架运动的名称，而要将其视为释放网络全部潜力的剧本。

Web 原生开发⁵是一种 Web 开发方法，它将 Web 平台视为整个应用程序故事的推动者，事实上，它是整个故事每个阶段（从开发到运行）取得成功的根本关键！这对于长达十年的文化转变及其对 Web 平台的悲观态度来说，无疑是一次艰难的重置！

这实际上关乎拥抱和利用原生 Web 技术、API、语言和约定等，并尽量减少工具的使用！事实上，人生中总有那么一个时刻，你真正想要的就是这些……用更少的戏剧性完成工作！“在我 20 年的编程生涯中，我加入过足够多的团队，因此我几乎比其他任何事情都更重视这一点”，Andrea Giammarchi 写道！

随着平台及其技术和语言的进步，我们常常能找到很多机会“摆脱这些工具”，转而采用原生方法。（JS Party - 第 89 集 | 更新日志）值得庆幸的是，工具的作用仅限于解决未解决问题，而非解决问题！任何异常情况很快就会开始改变叙事，使其变得适得其反！因此，尽管我们一直押注于自定义工具，但现在我们必须克服沉没成本谬误⁶，去探索原生可用的资源！

归根结底，Web 原生开发让您更多地依赖 Web 平台，而不是依赖抽象概念！在 Web 的“动态”发展历程中，您现在站在了胜利的一方，而不是竞争的一方！随着平台的不断发展，您现在正在赢得胜利！

George Katsanos 解释了这如何让我们节省更多的脑力周期来最终做出一些东西：

“我们所有人都应该清楚，如果我们将所有精力集中在平台上，而不是重复做事，我们将有更多的空闲时间专注于我们从事这项工作的真正原因，即提供快速、稳定、安全、用户友好的界面。”

那么，哪里是全面掌握 Web 平台的好地方呢？Chrome 的web.dev开发者中心是一个资源宝库，汇集了各种关键的 Web 设计和开发主题，由 Chrome 团队和其他行业专家共同维护！（这里是学习中心。）如果您需要了解 Web 平台的各个技术，这里是MDN！（这里是学习中心。）以下是一些案例：平台使用- 一篇由 Elise Hein 撰写的精彩文章，讲述了如何使用 ES6 模块实现免构建，以及如何使用 Web 组件实现免框架开发！

接下来是：这在现实生活中能走多远？用零个工具构建一个 Twitter 克隆版？呃，这从来都不是我们的主意，我们可能永远也实现不了！Web 平台本身不是一个框架！在某些时候，我们将需要比原生低级功能更高级的抽象！但似乎有点坏消息的是，HTML 和 DOM 的现状会让这种情况更快发生；用不了多久，平台的漏洞和缺陷就会让我们陷入苦役！但我们可以通过两条路线轻松扭转局面：

1. 底层工具：以平台为中心的举措，旨在标准化并将常见的 Web 开发架构和范例纳入平台。（我们早就应该实现原生级别的响应式开发和更强大的组件模型了——仅举几例！）

2. 更高级别的工具：以社区为中心的举措，旨在通过“Web 原生”库和框架扩展平台的底层功能。（我们需要一波新的、基于 Web 平台的适度抽象，让我们也能做到！）

这是我说到做到的！我想跟大家分享一些我在这方面一直在研究的想法！

愿意接受一些工具想法吗？

和我一起探索...

我们的旅程涵盖了一系列文章！我们从底层方程式开始，然后展示提案和 polyfil、用户空间库和框架！

对于好奇的人，这里是github 上对这个项目的预览。

笔记

• 在创建本文时没有损害任何框架。

致谢

• 特别感谢Alex Russell花时间审阅本文！

参考

• 你能负担得起吗？：现实世界的 Web 性能预算（Alex Russell）
• 2022 年页面重量报告：JavaScript 字节数（HTTP 存档）
• JavaScript 框架的成本（Tim Kadlec）
• 什么驱动了最佳开销？（Shawn Wang）
• 现代 JavaScript 概念词汇表：第 1 部分（Kim Maida）
• 重新思考最佳实践（Pete Hunt）
• 为什么 JavaScript 正在吞噬 HTML（Mike Turley）
• 统一样式语言（Mark Dalgleish）
• 为什么我不使用 Web 组件(Rich Harris)
• 也许 Web 组件不是未来？（Ryan Carniato）
• JavaScript 框架与失落的 HTML 艺术（Mark Steadman）
• 为什么我们要放弃 css-in-js (Brad Frost)
• 《大分水岭》（克里斯·考耶）
• Web 组件：持久战（Alex Russell）
• 现代 JS 工具是否太复杂了？（JS Party – 第 89 集 | 更新日志）
• 网络没有改变，改变的是你（雷米·夏普）
• Web 标准：是什么、为什么以及如何实现（艾米·狄更斯）
• 从古典主义到元现代主义——Web开发简史系列文章（Frédéric Bonnet）
• 炒作驱动开发(Marek Kirejczyk)
• 是什么让我再次编写 Vanilla JavaScript (Hajime Yamasaki Vukelic)
• 为什么我们要放弃 CSS-in-JS (Sam Magura)
• HTML 优先前端框架简介(SitePen Engineering)
• 无需 JavaScript 捆绑或转译的现代 Web 应用程序(David Heinemeier Hansson)

1. 借用 Frank Chimero 的标题：一切容易的事情又变得困难了 ↩

2. 定义成功的陷阱 ↩

3. 参见Fred Brooks：没有灵丹妙药 (PDF)  ↩

4. 参见文化侵蚀 ↩

5. “Web 原生”是跨多个倡议和范式反复出现的主题：  ↩

   • Web Native - Ionic 团队提出的想法，但范围仅限于其Capacitor运行时。
   • Web-Native - Frédéric Bonnet 在《Web 发展第三个时代的后现代主义时期》中对这一思想的提出。
   • 现代网络- 基于网络标准的现代网络开发指南、工具和库。
   • Stackless 方式- Daniel Kehoe 对 Web 开发的乐观看法，建议我们“使用平台”而不是框架和构建工具。
   • Buildless - Pascal Schilp 的无需构建过程即可创建生产网站的范例。

   一些相关标签：

   • #buildless - DEV
   • #vanilla - DEV
   • #useThePlatform -推特

6. 参见沉没成本谬误 ↩