工程师对 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 资源来更新内容。这些导航不一定是最重要的导航--例如，它可以通过导航 <iframe> 来实现。同样，SPA 也可能使用 <iframe>s 作为分块的手段，但内容更新的方式通常是不同的。

根据这个定义，Google Docs 属于 SPA，因为虽然每个文档都作为单独的资源提供，但大多数时候你都在与一个通过 JavaScript 不断更新的文档进行交互。YouTube 可能会被视为 MPA，但实际上它可能会被实现为 SPA，以便平滑内容的更改、拦截导航并通过脚本替换内容。

无论哪种情况，我对 MPA 将取代所有SPA 的想法感到惊讶很简单：Figma 或 Photoshop for Web 将如何作为 MPA 工作？或者 Slack、Discord 或 Google 地图？

我目前正在开发一个离线优先的移动 Web 应用程序，该应用程序在本地存储数据并同步到服务器。为了走在网络技术的最前沿，我研究了如何拥抱 MPA。

长话短说，如果我们要保留所需的用户体验（具有独立的可导航面板）和离线优先的要求，我们可以引入一些 <iframe>s 将某些功能分割成单独的 HTML 请求（而不是单独的脚本块请求），有时我们甚至可以预渲染一些块。问题是，这将使复杂性增加十倍（首先，双向同步变成了三向同步），同时不会给客户带来任何好处--相反，这几乎肯定会导致更多的错误、更多的延迟以及更慢的功能发布速度。

鉴于我们的应用程序目前尚未发布，我意识到这是一个相当薄弱的论点，因为没有人可以查看应用程序并提出更好的建议，所以我只请求你们相信我。我试过了。我真的试过了。只是这种架构并不适合这个特殊的应用程序，我很惊讶有人会建议一切都应该是 MPA。

“所有网站都应该在没有 JavaScript 的情况下运行”

在很多人看来 Web 开发最佳实践之一，就是构建一个无需 JavaScript 即可运行的网站。这样做可能意味着它可以优雅地降级，没有 JS 阻止初始渲染，并且可以在多种浏览器上运行。但令我惊讶的是，这种说法经常变得教条化，慢慢变成：“所有网站都应该在没有 JavaScript 的情况下运行”。

我想如果你的网站能够在没有 JavaScript 的情况下运行，那么很容易得出这样的结论，但对我来说这感觉有点短视。

我之前提到过 Figma 和 Photoshop for Web，很难想象如果没有 JavaScript 他们如何工作。对于浏览器的开发人员工具也是如此。

此外，尽管许多反对 JS 的人也关注可访问性，但要使应用程序具有可访问性，JavaScript 往往是必不可少的。

Mozilla 的无障碍人员教给我关于键盘导航的一件事是，Tab 导航应该相当粗糙。也就是说，你可以使用 Tab 键导航到控制组（例如工具栏），然后使用箭头键在该组内移动。这样，你就可以更快地浏览应用程序，而无需先用 Tab 键浏览每一个控件。。

不过，为了实现这种粗粒度的键盘导航，你需要使用 JavaScript。如果要实现基于箭头键的导航变成二维的，则需要更多的 JavaScript。也许有一天我们会填补平台中的这一空白，但现在你不应该为使用客户端 JavaScript 来使你的应用程序易于访问而感到羞耻。

老实说，我认为有些网站应该更多地使用 JavaScript。

例如，Eleventy 文档似乎在很大程度上避免使用客户端 JavaScript。由于 Eleventy 支持各种模板语言，因此它提供了每种不同语言的代码示例。不幸的是，它不会记录你选择的语言，因此如果你选择的语言不是默认语言，你将被迫更改每个代码示例上的选项卡。这里的一点客户端 JavaScript 将使用户的体验更加愉快。

“Web 开发不应该需要 Build 流程”

虽然这篇文章中的所有内容都来自 2022 年，但在整理它时，我忍不住添加了一个令我吃惊的最新看法。

我最近看到一个新的观点：“我们太盲目、固执了，以至于最终得到了一个极其复杂的工具链，但我们真的应该能够在没有 bulid 流程的情况下就能发布 Web 应用程序”。

作为一个在职业生涯大部分时间都在使用编译语言的人，不使用部署流程无疑不现实。编译器工程师所做的事情让我感到惊讶。他们是天才，他们在巧妙的优化之上又做了改进，将我非常普通的代码转变为难以辨认且速度惊人的代码。如果有的话，我希望在我的 Web 开发中能发挥编译器的魔力。

显然，JavaScript 也在面临新的挑战，因为它很难静态地确认某个操作的副作用，但我确信在编译时优化 JavaScript 方面仍有更多探索空间。

Web 开发人员似乎都同意在合理的情况下优化图片资产和预生成静态 HTML 页面，但为什么对优化代码资产也有了抵触情绪呢？为什么要把本可以在编译时完成的计算和 I/O 推迟到运行时呢？如果不出意外，我不想在每次请求时都向每个用户发送长达数兆节的评论，咒骂 iOS Safari。

也许到了 2024 年，客户端 Rust/WASM 前端框架开始受到关注的一年，如果是这样的话，我们最好习惯 bulid 流程！

“我的博客代表了整个 Web 开发”

上述几点可以概括为“我的博客代表了整个 Web 开发”。也就是说，从浏览器工程师到 Web 开发人员，大多数令我惊讶的 Web 开发概念都是人们以一种与我的经验并不重叠的方式推断他们的 Web 体验的结果。

自从我四年多前离开 Mozilla 以来，我的大部分时间都花在了 Web 应用程序上。我也花了太长时间建立这个博客。令人惊讶的是，在使用的工具、架构或 Web 平台功能方面，我发现两者之间几乎没有重叠。就好像博客和应用程序存在于 Web 开发领域完全不同的角落一样。

我的应用程序使用了大量 TypeScript 代码，我的博客几乎不使用客户端 JavaScript。我的应用程序因双向数据同步而变得非常复杂，我的博客是只读的。我的应用程序使用 webpack、Playwright E2E 测试、组件框架和状态管理库，但我的博客没有使用这些。

如果你大部分时间都在使用其中一种，那么你很容易就会认为这就是 Web 开发的样子。事实上，Web 开发可能比我们想象的更加多样化。

结论

仅是以上的几点内容，就足以证明我们对 Web 的简单体验无法代表整个 Web 开发。

从过往专注于浏览器开发到现如今转向 Web 开发，让我深深地明白 Web 开发远比自己所知道的要更广泛、更深刻。我对 Web 开发者也有了更多的敬意，尤其是那些小型 Web 网站和初创公司的开发人员，他们所开发的 Web 应用程序成功与否决定了整个公司的发展。

推荐阅读：

▶曾遭 Linus 炮轰“很烂”的 C++，现受开发者支持：Linux 内核应从 C 转到 C++！

▶比尔·盖茨对话 OpenAI 创始人 Sam Altman：现有模型都将变成最愚蠢的模型

▶OpenAI CEO奥尔特曼与男程序员Oliver结婚；荣耀回应抄袭锤子争议；Python 3.13将引入JIT编译器｜极客头条