导读：本文深入探讨了从浏览器开发回归 Web 开发的经验，揭示了一些关于 Web 开发的观念和看法。作者提醒我们，尽管我们可能认为自己的 Web 经验已经足够丰富，但实际上，Web 开发领域远比我们想象的要广阔和复杂。通过比较浏览器工程师、标准编辑和其他 Web 开发者的观点，我们可以更全面地理解 Web 开发的全貌。对于小型 Web 商店和初创公司的 Web 开发者来说，他们面临的挑战和约束更是独特。在 Web 应用开发中，他们需要找到自己的定位，充分发挥自己的优势。总体而言，作者希望读者能够对自己的 Web 开发实践充满信心。了解并接受自己的约束可能是取得成功的关键。
自从我离开 Mozilla，全身心投入 Web 开发工作后，我发现了一些令我惊讶的事情。与我之前作为浏览器工程师的认知相比，Web 开发实际上是一个相当复杂且富有挑战性的领域。而且，Web 开发人员普遍都非常聪明，他们所采用的框架和技术并非如我们之前所轻视的那样不堪。
与此同时，我也发现了一些 Web 开发人员对浏览器和 Web 的看法，这些观点在我作为前浏览器工程师和标准编辑的角度看来，存在一些疑问。
以下是我所观察到的一些令我惊讶的事情。
Web 浏览器工程师对 Web 开发非常了解
我曾天真地认为，作为浏览器工程师，我们对 Web 的了解一定比其他任何人都要深入。毕竟，我们每天都在编写构成 Web 平台的代码。
问题在于，编写 Web 浏览器是一项艰巨的任务。
大多数浏览器工程师都专注于特定的领域，对某些领域有着非常深入的了解，而对其他领域的知识可能只是停留在表面。此外，浏览器平台的工程师们主要使用 C++ 和 Rust 编写代码，只有极少数的 JavaScript 测试用例。他们所面对的是一个庞大的代码仓库，其中大部分工作都是由其他人负责的。
因此，在日常工作中，Web 浏览器工程师并不会与 webpack 对抗，也不会去深入理解全页的 TypeScript 错误。他们也不会考虑如何让 iOS 上的 Safari 表现得更像其他浏览器，或者在大规模的 CSS 中挣扎。他们更不会去评估最新的 SSR/SSG/island 框架是否值得投入使用，也不会为了更优化的分块而重构庞大的 JS 代码库，也没有在 GitHub 上因为某个依赖的最新版本破坏了他们的应用而提出沮丧的问题，也没有试图让所有工具在 ESM 与 CJS 之间达成一致，也没有因为选择了正确的状态管理方法还是应该第十次重写整个东西而夜不能寐。
简而言之，由于他们的工作重点和职责范围，他们对于真实世界的 Web 开发所面临的挑战和问题的了解，可能远不如 Web 开发人员所期望的那样深入。
尽管如此，致力于浏览器开发者工具和浏览器前端开发的工程师们通常会更加关注这些问题，并且他们每天都在使用 JavaScript 进行开发。然而，他们仍然与常规的 Web 开发存在一定的距离。例如，他们只需要针对单个浏览器引擎的平台特性进行开发，通常只需要针对单个浏览器版本进行工作（能够使用新的和令人兴奋的功能而不用担心兼容性是非常棒的），不需要担心捆绑大小，服务器，脱机状态，或许多其他使 Web 开发变得困难的问题。
显然，一些 Web 浏览器工程师也会参与业余项目，但这些业余项目的限制与在一家初创公司的情况截然不同。在初创公司，Web 应用的成功与否直接关系到公司的生死存亡。
在我职业生涯的早期，我曾从事平面设计和 Web 开发方面的工作，甚至在加入 Firefox 开发团队之前，我曾在大阪的一家 Web 开发公司工作过一段时间，并参与了一些 Web 应用的制作。然而，当我离开 Mozilla，全心投入到 Web 开发领域时，我对它的快速发展以及我对它的理解程度感到震惊。
作为一名 Web 浏览器工程师的经验对 Web 开发非常有价值，主要是因为我了解去哪里寻找资源、向谁寻求帮助以及如何提交错误报告。然而，如果我认为成为 Web 浏览器工程师就自动使我具备了 Web 开发的能力，那我就是在自欺欺人。
在我在 Mozilla 的日子里，Firefox OS 时代无疑是我最愉快的时光。那时候，我们有一个内部团队专注于构建真实世界的移动 Web 应用。作为平台团队，我们的首要任务是调试这些应用，确保它们能够成功运行。
在这个过程中，我发现 transitionend 事件有时并不可靠，这导致 Web 应用程序出现错误，甚至过于复杂。因此，我提出并实现了 transitioncancel 事件，并引入了 Web 动画的 Animation.finished Promise。
然而，即使与 Web 开发人员紧密合作，也无法让我真正准备好再次成为全职的 Web 开发人员。在很大程度上，浏览器工程师和 Web 开发人员是处于两个截然不同的世界中，这也许并不像我们所想象的那样，都是 Web 开发人员超级英雄。
制定 Web 规范的人对 Web 开发非常了解
是的，那些致力于 Web 标准和规范制定的人，特别是浏览器工程师，通常对 Web 开发有深入的了解。早在 2012 年，Brendan Eich 就曾指出，“制定标准就像制定法律一样，绝对是制香肠的过程” ，引用了 John Godfrey Saxe 的名言：
法律就像香肠一样，我们对制定过程的了解程度与对它的尊重程度成反比。
作为一名 Web 开发人员，很容易将那些致力于 Web 标准和规范制定的人想象成拥有无限智慧的群体。他们能够根据每个提案的技术优点和对行业需求的深刻理解，做出冷静而理性的决策。
然而，这种美好的幻想通常会在你参与的第一个工作小组会议中破灭。尽管大家的出发点都是最好的，但有时决策至少在一定程度上是基于某个人的魅力或强烈的个性，这取决于当时在房间里的人是谁、大家有多疲劳，甚至可能因为某人需要完成晋升材料而急于推出某个功能。
这听起来可能有些愤世嫉俗，但请让我进一步澄清两点。
首先，这些工作小组的人员都是善良、出色的人，他们通常也意识到自己的局限性，并尽力寻求 Web 开发人员的反馈。不幸的是，到目前为止，我还没有看到哪个小组在这方面取得了很大的成功。例如，虽然有 Twitter/X 的投票机制，但这些投票往往只有前沿的 Web 开发人员参与，而且容易被投票者的个人观点所影响。
其次，我对 WHATWG 规范（如 HTML 和 DOM）的经验并不多，这些规范的决策过程似乎是异步进行的（“在面对面会议期间做出的任何决定都应被视为非约束性”——来自 WHATWG meetings），然而，我的印象是他们似乎能够做出更好的决策。像 Anne van Kesteren、Simon Pieters 和 Domenic Denicola 这样的人可能比地球上其他任何人更了解 Web 技术。但即使如此，这并不等同于他们完全了解 Web 开发的实际情况和挑战。
Web 开发人员对 Web 开发非常了解
作为一名浏览器工程师，发布新的平台功能无疑是一种令人满足的体验。当我的工作成果被 Smashing Magazine 和 CSS Tricks 等知名技术媒体报道，并在 Twitter/X 上引发广泛讨论时，很容易让人误以为全世界都已经知道了这一伟大的新进展。
然而，几年前的某一天，Mozilla 日本团队的一些成员决定在东京进行一项特别的调查，我们采访了一些当地的 Web 开发人员，了解他们对最新开发工具的看法和使用情况。
结果令人惊讶。
我们发现许多开发人员对十年前推出的新 CSS 功能一无所知。更令人沮丧的是，即使我们告诉他们这些功能，他们似乎并不感到兴奋。他们表示，使用 jQuery 和 WordPress 已经能够很好地完成工作，对此心存感激。
相反，他们更关心的是一些实际问题，比如：“在响应式设计模式下为客户展示网站时，如果没有 iPhone 模型来模拟设备视图，客户很难理解他们所看到的是该网站在手机上的预览效果。我真的需要那个 iPhone 模型。”
作为一个参与制定新 Web 标准的浏览器工程师，我对这些开发人员面临的现实问题深感失望。但我更深刻地认识到，他们在交付网站和 Web 应用的过程中所面临的限制和挑战。
与从事浏览器开发或资金充裕的硅谷初创公司的人不同，许多 Web 开发人员在小公司工作，面临着巨大的压力，需要快速交付项目以满足客户需求，然后迅速转向下一个项目以维持生计。他们没有时间去探索即将推出的新技术，而是更倾向于寻找他们已经熟悉的经过验证的解决方案。
浏览器并非专门为运行单页面应用而设计
从浏览器开发回归到 Web 开发，我发现关于浏览器工作方式的某些观点令人惊讶。
在从事动画开发时，我发现许多人误以为动画 “在 GPU 上运行”。实际上，浏览器可以将部分动画卸载到单独的进程或线程中，使用 GPU 来更新动画并合成每一帧。然而，这并不意味着所有动画都完全在 GPU 上运行。相比之下，有些观点则更为离谱，如 “浏览器不是为运行单页面应用（SPA）而设计的”。
有一种观点认为，最初的浏览器主要是从网络加载内容，逐步进行布局和渲染，并且针对这一过程进行了大量优化。动态内容的出现相对较晚，因此优化程度可能较低。
然而，我从事浏览器开发近二十年的时间里，并不完全认同这一观点。Firefox 的前端和开发者工具实际上就是一个 SPA。尤其是开发者工具，它们使用 React 和 Redux 编写，各个方面都体现了 SPA 的特点。
关于浏览器在处理通过 JavaScript 进行的复杂和长寿命 DOM 树的动态更改方面存在缺陷的观点，这与浏览器的发展趋势相矛盾。
尽管有人可能会提出移动端浏览器并未针对 SPA 进行优化的观点，但实际上，这并不意味着浏览器在处理 SPA 方面存在根本缺陷。例如，在 Android 上，Firefox 从使用 HTML 渲染的浏览器外壳切换到了本地浏览器外壳以提高性能。我无法评论导致这一变化的特定性能限制是什么，但当时的一篇博客 表明这与改善应用启动时间和平移和滚动性能有关，这两者都不表明浏览器在处理 SPA 方面比其他架构更差。
“好吧，也许浏览器可以处理复杂的长寿命 DOM 树，进行频繁的动态更改，但 SPA 往往具有大型 JS 捆绑包，下载和解析速度较慢，阻塞了初始渲染。” 这是一个合理的论点，但它主要关注的是捆绑包大小和初始渲染的阻塞问题，而不是浏览器是否适合运行 SPA。实际上，这个问题同样适用于普通的 WordPress 站点。
多页面应用将取代单页面应用
在探讨 SPA（单页面应用）和 “编写 Web 应用程序的唯一真实方式” 时，近期关于 “浏览器无法处理 SPA” 的一种观点是 “MPA（多页面应用）将取代 SPA”。
我对 MPA 持有相当积极的态度。更具体地说，作为一名与众多动画规范密切相关的人，我对 视图转换规范 感到十分兴奋。在 Mozilla，特别是在 Firefox OS 时期，我们一直致力于推动这一 提案 的实现。我十分赞赏 Jake 等人最终使这一规范成为现实。
视图转换规范最初是专为 SPA 设计的，但现已适应了 MPA 的工作方式，并为多页面站点带来了更加愉悦的用户体验。
然而，基于 “SPA 是不好的” 这一思想，似乎有一种趋势认为 MPA 是未来的发展方向，而 SPA 将逐渐被淘汰。
与前文中的观点不同，我对这一看法的惊讶并非基于我在浏览器开发上的工作经验，而是基于我最近在 Web 应用程序方面的工作经验。
首先，我们需要明确什么是 MPA。
在我理解中，与 SPA 的特点 —— 拥有一个或两个长寿命的 DOM 树，经常由脚本频繁更新 —— 不同，MPA 主要是通过导航到从网络提供的不同 HTML 资源来更新内容。这些资源不必是最顶层的导航，例如，可以通过导航到