工程师对 Web 开发的 8 个误解！
在很多人眼中，Web 开发是最简单的编程工作之一。
不过，对自 2004 年一直从事 Firefox 开发而后于 2019 年离开 Mozilla，如今创了一家小公司的全职 Web 开发者 Brian Birtles 而言，他发现众人对 Web 开发存在很多误解。在本篇文章中，他结合其在浏览器多年的开发经验从 8 个维度进行了分享。
原文地址：https://birtles.blog/2024/01/06/weird-things-engineers-believe-about-development/
本文为 CSDN 翻译，未经允许禁止转载
作者 | Brian Birtles
翻译工具 | DeepL 责编 | 苏宓
出品 | CSDN（ID：CSDNnews）
这篇文章的大部分内容是我在 2022 年的某个时候写的，但我认为它在 2024 年仍然适用，所以我决定将其整理分享给当代的工程师。
自从我退出 Mozilla 并重新开始全职 Web 开发以来，我发现了一些让人惊喜的事情。事实证明，Web 开发实际上相当困难，Web 开发人员其实非常聪明，而我们作为浏览器工程师所嘲笑的一些框架和技术也并没有那么糟糕。
与此同时，一些 Web 开发人员对浏览器和 Web 有着一些想法，也让我这个曾经负责浏览器和标准构建方面的工程师感到有些不解。
以下是一些令我惊讶以及在我看来是误解的事情。
“Web 浏览器工程师非常了解 Web 开发”
我们不难想象，编写构成 Web 平台代码的 Web 浏览器工程师一定比其他人更了解 Web。
问题是，编写 Web 浏览器很困难。
大多数浏览器工程师都专注于某个特定领域，对该领域非常了解，而对其他领域只有肤浅的了解。此外，浏览器平台工程师整天都在编写 C++ 和 Rust 代码，以及一些非常简单的 JavaScript 测试用例。最重要的是，他们还要为一个庞大的存储库做出了贡献，而这个存储库中的所有工具都由其他人负责。
因此，在日常工作中，浏览器工程师不会与 webpack 作斗争，不会尝试去理解整页 TypeScript 错误（他们用 C++ 模板错误来填补生活中的漏洞），也不会尝试让 iOS 上的 Safari 表现得像其他浏览器一样，不会纠结于大规模的 CSS，不会尝试评估最新的 SSR/SSG/island 框架是否值得投资，不会重构大量 JS 代码库以实现更优化的分块，不会因为某个依赖项的最新版本导致应用程序崩溃而在 GitHub 上提交令人恼火的问题，不会试图让所有工具在 ESM 与 CJS 达成一致，也没有因为他们是否选择了正确的状态管理方法或者是否应该第十次重写整个事情而寝食难安。
简而言之，他们并不是日复一日地进行 Web 开发，因此他们对现实世界 Web 开发的了解没有众人想得那么多。
现在，从事浏览器开发工具和浏览器前端工作的工程师通常每天都在使用 JS，当然他们对这些问题也有更多的认识，但这与普通的 Web 开发仍有一定的差距。
例如，他们只需要针对单个浏览器引擎的平台功能，并且通常只需要单个浏览器版本，不需要担心捆绑包的大小，或服务器、离线等其他许多使 Web 开发变得困难的问题。
显然，一些浏览器工程师有业余爱好项目，但业余爱好项目所受的限制与在初创公司中的限制相比简直是天壤之别，在初创公司中，Web 应用程序的成功与否决定着公司的生死。
我的职业生涯始于平面设计和 Web 开发，甚至在开始为 Firefox 做出贡献之后，我还在大阪的一家 Web 开发公司工作了一段时间，并也在 Mozilla 日本公司制作了一些 Web 应用程序。然而，当我从 Mozilla 辞职并全职重新投入 Web 开发之后，我对这一领域发生的巨大变化以及我对它的了解是如此之少感到震惊。
作为一名浏览器工程师，我的经验在 Web 开发中非常有用，尤其是因为我知道该去哪里找、向谁询问以及该去哪里报告 Bug，但如果我说成为一名浏览器工程师就自动成为了一名 Web 开发者，那我就太自欺欺人了。
我在 Mozilla 工作期间，使用 Firefox OS 的日子是迄今为止最愉快的。我们的内部团队正在开发真实世界的移动 Web 应用程序，而作为平台团队，我们的首要任务是调试并使其成功。我看到 transitionend 事件是如何变得不可靠并导致 Web 应用程序出现错误且过于复杂，因此我提出并实现了该 transitioncancel 事件和 Web Animations 的 Animation.finished 承诺。
但是，即使与 Web 开发人员并肩工作，我也无法为再次成为一名全职 Web 开发人员做好准备。大多数情况下，浏览器工程师的工作环境与 Web 开发者不同，他们可能并不是我们想象中的 Web 开发超级英雄。
“制定 Web 规范的人非常了解 Web 开发”
承接上一个讨论，也许你会认为从事 Web 标准和规范工作的人（事实证明，他们大多是浏览器工程师）肯定精通 Web 开发，对吧？
早在 2012 年，Brendan Eich 就指出 ，“制定标准就像制定法律一样，肯定是在制作香肠”，引用了 John Godfrey Saxe 的以下言论：
法律和香肠一样，一旦我们知道它们是如何制作的，就不再能引起人们的尊重。
作为一名 Web 开发人员，我们很容易想象有这么一群人，他们对所有与 Web 技术相关的事情都有着无穷的智慧，他们会根据每项提案的技术优点，并结合对行业需求的透彻理解，做出冷静、理性的决策。
但这种幻想通常不会持续到第一次工作组会议。尽管出发点是好的，但有时做出的决策至少部分是基于一个人的魅力或强势的个性，也有可能是当时恰好在房间里的人、每个人的疲劳程度，或者，我敢说，甚至可能是基于某人为了填满自己的晋升资料包而需要发布一项功能。
这听起来很愤世嫉俗，所以让我做两点澄清。
首先，这些团体中的人都是善意的、优秀的人。此外，他们常常意识到自己的局限性，并尽力征求 Web 开发人员的反馈意见。不幸的是，我还没有看到一个团队能够非常成功地做到这一点。例如，有 Twitter/X 民意调查，但它们往往只能由最前沿的 Web 开发人员回答，并且很容易被传播民意调查的人所扭曲。
其次，我对 HTML 和 DOM 等 WHATWG 规范没有太多经验，这些规范中的决策似乎是异步做出的（在面对面会议期间做出的任何决策都将被视为不具有约束力——WHATWG 会议），但我的印象是他们似乎能做出更好的决定。像 Anne van Kesteren、Simon Pieters 和 Domenic Denicola 这样的人可能比地球上的任何人都更了解 Web。但即便如此，也与了解 Web 开发不同。
“Web 开发人员非常了解 Web 开发”
作为一名浏览器工程师，发布新的平台功能真的很令人满意。《Smashing Magazine》、《CSS 技巧》和 Twitter/X 上都会有相关的文章。我们很容易想到，现在全世界都知道了 Web 最新的进步。
几年前的某个时刻，Mozilla 日本团队的一些人决定采访东京当地的 Web 开发人员，了解他们可以从哪些开发工具中受益。
结果令人惊讶。
许多人不知道 10 年前发布的新 CSS 功能。更重要的是，即使我们告诉他们这些事情，他们似乎也不太兴奋。他们表示使用 jQuery 和 WordPress 就可以了。
相反，他们在用 CSS 时遇到了很多麻烦，比如：“当我向客户展示响应式设计模式的网站时，如果窗口周围没有 iPhone 的模拟图，客户就无法理解他们看到的网站在智能手机上的预览效果。我真的需要那个 iPhone 模拟。”
作为一名参与开发新 Web 标准的浏览器工程师，我有点失望，但我印象深刻的是，这些靠发布网站和 Web 应用程序为生的人受到了很多限制。
与浏览器工程师或资金雄厚的硅谷初创公司不同，他们中的许多人都是在小公司里工作，面临着巨大的压力，必须快速交付成功，然后进入下一个项目以支付账单。他们没有闲情逸致花一上午的时间去研究即将到来的技术，而是选择他们有经验的、经过考验的、值得信赖的解决方案。
”浏览器不是为运行 SPA 而生的“
从浏览器开发转回 Web 开发的另一个惊喜是关于浏览器如何工作的一些断言。
当我从事动画工作时，我对很多人认为某些动画“在 GPU 上运行”感到惊讶（浏览器可以将一些动画卸载到单独的进程或线程，该进程或线程会使用 GPU 更新动画，以合成甚至绘制每一帧，但它不会将这些动画全部卸载到 GPU 上），但与”浏览器不是用来运行 SPA（单页面应用程序）的“等其他一些误解相比，这只是一个相当小的误解。
我认为这里的论点是，浏览器最初是通过网络加载内容，然后逐步布局和渲染，并且已经为此进行了大量优化。动态内容出现得较晚，因此优化程度较低。
在断断续续地研究浏览器近二十年后，我不相信情况是这样，或者至少现在不再如此。
毕竟，Firefox 前端和开发工具实际上就是 SPA，尤其是开发者工具是使用 React 和 Redux 编写的，从任何意义上来说都是 SPA。
有人认为，浏览器在处理复杂且长期存在的 DOM 树以及通过 JavaScript 进行的动态更改方面存在缺陷，而浏览器本身就与这一说法相悖。
有人会说，在移动设备上，浏览器并没有针对运行 SPA 进行优化。毕竟，在 Android 上，Firefox 为了提高性能，从 HTML 渲染的浏览器 Chrome 切换到了本机浏览器 Chrome。我无法评论导致这一改变的具体性能限制因素是什么，但当时的一篇博客显示，这与改进应用程序启动时间以及平移和滚动性能有关，这两者都表明浏览器正在受到影响。
”好吧，也许浏览器可以处理频繁动态变化的复杂、长期存在的 DOM 树，但 SPA 往往有大量 JS 捆绑包，下载和解析速度很慢，从而阻碍了初始渲染。“这种说法有点道理，但它是支持较小的渲染阻塞初始捆绑包的论点，这同样适用于普通的 WordPress 网站，而不是浏览器在某种程度上不适合运行 SPA 的论点。
“MPA 将取代 SPA”
当我们谈论 SPA 和“编写 Web 应用程序的唯一真正方法”时，“浏览器无法处理 SPA”的说法已经演变为“MPA（多页面应用程序）将取代 SPA”。
我对 MPA 感到非常兴奋。更具体地说，作为参与大量标准规范的人，我对视图转换规范感到兴奋。这是我们在 Mozilla 一直想做的事情，特别是在 Firefox OS 时代，并为此提出了一个建议。
视图转换最初是为 SPA 实现的，但现已适应 MPA。
然而，基于“SPA 不好”的想法，似乎有一种倾向认为：MPA 是未来，而 SPA 即将被淘汰。
与本文前面的观点不同，我对此感到惊讶并不是基于我在浏览器方面的工作经验，而是基于我最近在 Web 应用程序方面的工作经验。
首先，了解一下 MPA 到底是什么意思？
我的理解是，SPA 的特点是拥有一两个长期存在的 DOM 树，并且经常通过脚本进行更新，而 MPA 主要通过导航到网络提供的不同 HTML 资源来更新内容。这些导航不一定是最重要的导航--例如，它可以通过导航