距离我在 Chrome 项目工作已过去约 10 年了。这期间发生的一些故事，因为年代久远而变得模糊，我想趁着自己还没有完全忘记之前将它们记录下来。

我做了什么

2007 年～2012 年，我一直在从事 Chrome 开发，当时的我还未满 30 岁。当然，我的生活中还有其他事情发生，例如结婚，但就我一生所做的事情而言，受到更广泛关注的是 Chrome。如今，Chrome 拥有超过 25 亿用户。每当去咖啡馆，看到邻桌的人在使用“我开发的”软件，就会感觉很奇妙。

我加入这个项目的目标是开发 Linux 版的 Chrome，也就是说，我首先要在 Windows 版的 Chrome 上工作几年，之后再去领导 Linux 版 Chrome 团队。加入一个全新的项目意味着每段代码都要亲力亲为，至今我仍然记得，我编写的那段代码可以在用户点击“星星”按钮时让它亮起。其实，背后不过是一个新的状态布尔值以及一个额外的图像资源。

那些年里，我一直在更新一个关于 Chrome 的博客（https://neugierig.org/software/chromium/notes/archive.html），里面有很多技术细节，包括我的第一篇帖子，以及我离开时跟大家告别的帖子。

我为什么加入Chrome项目

我加入 Google，后来又加入 Chrome，因为我认为自己是自由软件社区的一员。大学期间，我们为了拥有一个能正常使用的浏览器而绞尽脑汁，甚至在 Linux 电脑旁边再摆一台 Windows 电脑，只因为当时的 Web 只能用 Windows 上才有的 IE 来浏览。正如 Brad 写道：“我等了一年之久，Mozilla（改名 Firefox 之前的开源版本）才变得不那么难用了。”我记得，我曾在宿舍里尝试在 Linux 上构建 Mozilla，结果失败了，当时我心里默默地说，终有一天我一定会解决这个问题。而 Chrome 给了我这个机会。

然而，很讽刺的是，最终事态却滑向了相反的方向。我从痛苦的经历中得到了教训，明白了为什么 Linux 上面向用户的软件（包括 Mozilla 和我的软件）通常都不太理想的深层原因。同样，我明白了免费软件来自无私的付出和感恩的心，但最终都变成了企业的另一种武器。回想起来，这是一个古老的比喻，我试图“从内部改变系统”，但最终被它吞噬了。

为什么Goole决定开发Chrome

如今回想起来，感觉 Chrome 的成功是很自然的事情，但在当时看来，Google 开发浏览器似乎是一件疯狂的决定。（当时，即便是公司内部也反复开玩笑说，这永远不可能。）

透过历史，我们可以清楚地看到这是一场篡夺网络控制权的阴谋，但当时这个事情非常简单，至少像我这样天真的小卒看来是这样。Google 希望 Web 能取得成功，甚至派出了一个团队协助 Firefox 开发。Google 希望能够对 Firefox 发挥更大的影响力，Mozilla 对此很不满，所以我们决定另辟蹊径。这中间肯定有巨大的冲突，只不过我看不出来。据我所知，WebKit 分支也经历了一段相似的历史：他们希望 WebKit 提供苹果没有的功能，但最终发现过犹不及。

还有一个小插曲，有人说微软对 Google 展开了恶意报复，而且还有人担心微软会借助 IE 来建立反 Google 阵营。那时，每次 Windows 自动更新都会重置搜索引擎设置，不过这是微软一贯的作风。你甚至可以把当时 Valve 开发基于 Linux 的操作系统的尝试解读为对 Windows 应用商店的防范。我知道如今的微软会重振雄风，但我仍然记得在 90 年代，经常有报道说这些大公司有多么不堪。

第三，即便 Chrome 失败，人们也希望它能够为其他浏览器点一把火，我认为 Chrome 做到了，在版本 8 发布之前，根本没有人在意 JavaScript 基准测试。人们很容易忘记当时的网络有多糟糕，但 Chrome 的问世介于 IE7 和 IE8 之间的三年停顿期间。

为什么Chrome成功了

Google 投入了大量资源（工程以及广告）是一个重要因素。但 Google 投入大量资源，最终却未能成功的例子也不罕见。

每当我对技术感到沮丧时，能让我感到些许安慰的事情之一便是，X 公司那么有钱，仍然无法做出让客户喜爱的产品 Y。有趣的是，在我写这段的时候，正传出了 Google 放弃克隆 Facebook 的消息，似乎完美地证实了这一点。你也可以想想微软和亚马逊在手机领域的尝试。

我认为我们最初推出的产品才是真正的好软件。我们所做的一些事情，比如页面之间的操作系统级沙盒隔离，其他浏览器需要花费数年时间才能实现。

其中很大一部分是因为当初我们之中有一些很伟大的工程师。想一想，有多少超级聪明的人才是你从未听说过的，这些人就好像一种“暗物质”，永远不会步入大众视野。举个例子，Antoine 是一位非常有才华的工程师，也是 ChromeOS 的功臣之一，但互联网上几乎听不到他的任何消息。

然而，我也见过很多优秀的工程师开发出并不怎么成功的软件。如果非要找出合作过的其他项目都缺乏的 Chrome 特有的优势，我想大概是一致性：这款产品有一个明确的目的，每个人都知道并且都在朝着这个方向前进。我依稀记得一些设计细节，我们的设计师 Glen 为制定某个设计决策而权衡的所有因素。从那以后，我就坚信他非常清楚自己在做什么。

也许这只能说明我们有很好的领导班子。很抱歉，无法在此给出更具体的成功秘诀。当然运气也占很大一部分。

一些回忆

最初，Chrome 只能在 Windows 上运行，而且自定义标题栏中的按钮一看就是 Windows 风格。我一直催促 Glen 给我设计一些 Linux 风格的按钮，我甚至搞了一出恶作剧，用他的头像代替了关闭按钮。

回想起来，真是有趣。

打磨

在即将发布第一版 Chrome 时，我们选择了一个发布日期，并计划抓紧最后的一段时间消灭所有 bug，来不及完成的功能只能统统放弃。例如，我曾付出了很大努力开发一项与 RSS 相关的功能，但发布前暂时放弃了，之后再也没有机会继续。后来，项目出现了一些危机，我不记得具体情况了，但一些新闻报道给我们带来了很大的负面影响，最终导致发布推迟了一个月。

虽然我们多出了一个月的时间，却无法添加真正的功能，我们只能利用这些时间来打磨产品，修复所有通常在发布最后一刻没有时间处理的细节问题。回想起来，这对产品来说是也许是一件好事。打磨产品其实非常重要，只不过一般我们更愿意将精力投入到功能开发上。

漫画

这则漫画中竟然提到了我（https://www.google.com/googlebooks/chrome/small_02.html），作者是 Scott McCloud，他的漫画真的很棒。

原本我们打算在发布浏览器的时候同步发布漫画，作为发布时的支持文档之一。但由于（发行？）出了问题，有人在我们发布实际产品之前拿到了漫画，因此有关漫画和浏览器的评论分别出现在新闻中。现在回想起来，这也不错，因为一些感兴趣的用户会被产品的创意所吸引，不会太过在意产品的视觉细节。

版本控制

最初，Chrome 使用的是 Google 管理代码的版本控制系统 Perforce，后来我们换成了内部托管的 SVN，为的是发布时通过 Google 的公共 SVN 托管服务开源代码。然而，真正到了发布的时候，我们却发现这个服务无法扩展到为 Chrome 这样大的项目提供服务，导致我们不得不自行研究怎样发布代码。

最终，我们租用了 Google 网络之外的服务器，系统管理也只能靠自己。对于在创业公司工作的人来说，这些工作都很熟悉，但在 Google 就很不正常，因为 Google 的服务器管理是高度自定义的、集中管理的，而且我们清楚这些服务器的每一个细节。我记得我甚至无法使用 Google 的硬件，因为在我们的数据中心或类似的地方运行非 Google 的软件是一个很陌生的想法。

与此同时，我对版本控制充满了热情，而且我非常肯定有一天 Git 会广泛普及。因此，我编写了一个与 Git 有关的工具用于管理 Chrome，以便将 Git 集成到我们基于 SVN 的代码审查流程中。回想起来，我认为这是我作为领导失策的地方。许多年后，Chrome 项目不得不全权依赖 Git，我们花费了几年的时间才将 SVN 去掉。如果我多花点时间来推进，相信能为很多人节省很多时间。

前言与苹果公司合作

Chrome 大约一半的代码来自 WebKit 的分支，在 Chrome 发布后，我们将其重新整合到了苹果的上游。这意味着，在我们发布 Chrome 后不久，我们修改的代码都需要得到苹果工程师的批准。

回想起来，我挺喜欢那段时间的工作，原因有两个。第一，让经验丰富的工程师审查自己的代码是程序员迅速成长的最佳方式之一，而苹果有着完全不同的工程师文化，他们没有单元测试，没有注释，但他们也能构建出高质量的产品。第二，苹果的批准流程相当于一道门槛，为了向 Chrome 添加功能，我们必须向苹果证明添加这项功能非常有意义。

然而，我并没有从事太多这方面的工作，我知道这项工作的压力很大，部分原因是双方的目标有很大不同。虽然个别工程师可能不同意这种看法，但我可以毫不夸张地说，从结构上讲，苹果关心的是制作一款能够充分渲染网页的浏览器，而真正的应用程序不属于浏览器。此外，双方也有很多技术方面的分歧。也许是我很幸运，也许是我忘记了，我只记得当时的代码审查是一段温暖的回忆。

我的采访

有一次，我度假回来收到了一封电子邮件，上面写着：“一家 Linux 杂志想采访你，但你不在，所以我们帮你写了回复，你可以根据需要编辑。”回想起来，他们的这种行为很不恰当，我也不知道为什么当时自己没在意。如今，你仍然可以看到“我的”那篇回复（https://www.linuxjournal.com/magazine/google-chrome-making-cross-platform-browser），文中包含很多让人很无语的言论，比如“之所以构建了 Google Chrome 浏览器，是因为我们可以为用户带来真正的价值。”

奖赏

Google 有一个规定，在正常的薪酬之外，偶尔还会选出某些方面非常出色的项目奖励大笔股票。Chrome 得过一次奖，也许那是最后一次，但我也不是很清楚，因为他们颁布此奖项总是秘而不宣。

我提到这件事，是因为当时我们得知自己的项目获奖了，而且每个人都知道自己能拿到多少奖金，但很快团队中的一位资深人士就宣布他即将离开公司。我记得当时自己特别惊讶，并问了他关于这件事，他的答案令我终生难忘，他说：“现在我知道自己留在这家公司能获得的最高报酬，那么就能与其他选择做比较了。”

一般，公司的奖赏都是为了鼓励员工努力为公司工作，然而这个故事显然是一个反面教训。与之类似，虽然我能理解为什么一家公司为他们想奖励的行为给予超额奖金，但为了留住人才，用奖赏来吊人胃口，这种行为让我深感不齿。

Web应用与原生应用

如今，我们想当然地认为所有软件都应该构建在 Web 之上。但我的经历描绘了一段不同的时代：在推出 Chrome 时，我们有一个搜索功能，浏览器会显示一个选项卡，上面显示了一些链接和文本片段，就像一个网络搜索结果页面。

我记得当时编写了一段原生 UI 代码来自定义文本布局以及链接，尽管页面的外观和行为看起来就像基于 Web 的搜索结果页面。这就是说，在当时使用 HTML 来实现应用程序是一个很糟糕的想法，即使对于我们浏览器开发人员来说，即使对于应该表现得像网页的 UI 也是如此。

后来，我下了一番功夫公开了基于 HTML 的浏览器 UI，我记得自己当时还在团队内大力倡导 Web 开发。从那以来，很多浏览器的 UI 都开始使用 HTML 来实现。当然，现如今在 Electron 的世界中，桌面应用程序不使用 HTML 实现的情况越来越罕见……

Chrome 与 Web

当 Chrome 还不成气候的时候，各个网站都不会主动解决 Chrome 错误。我们必须去适应他们。当时我们为了解决 MediaWiki（维基百科）中的这个错误（https://bugs.webkit.org/show_bug.cgi?id=28350）花费了不少心思。这个 bug 从 2009 年开始就有了，一直存在了十年。

有一次，我们遇到了一个问题：浏览器应该支持多少次重定向？假设你尝试加载 A，但A重定向到了B，B又重定向到了C，依此类推，直到某个时刻，你必须放弃，然后报告错误。有人选择了一个看似合理的阈值，比如 10 次左右，超过这个数量 Chrome 就会放弃。然而，Darin 曾经从事过 Firefox 开发，他说：“不，至少应该支持30次，否则纽约时报就会出问题——经验之谈。”

后来，Chrome 越来越强大，很多网站开始测试，确保他们能够处理 Chrome 的错误。再到后来，Chrome 足够强大，成为了制定规则的人。但我感到很焦虑，因为我们无从判断这些决定没问题。网络的发展速度很快，但大多数时候我们都依赖于少数几个决策制定者的“善意”。标准流程的失败导致了 HTML 5 的割裂，这正说明了随意让一个机构定义标准也行不通。我认为这是一个需要平衡的问题，没有简单的答案。

ChromeOS

曾有人问我是否愿意加入 ChromeOS 项目，我心爱的Linux Chrome 也是其中的一个重要部分——我对此非常怀疑。

但 ChromeOS 的结果让我感到惊讶，尤其是在安全和更新方面。他们通过某种方式让合适的人在合适的地方做出了卓越的产品。

如今的Chrome

Linux Chrome 基本可以正常工作了，但我并没有意识到自己的工作已经完成了。当时我还开玩笑说：“Chrome 12 [一个旧版本] 才是最佳版本”。但当我意识到真正需要的是一个速度非常快的浏览器之后，就发现大多数后续工作都是在添乱。当然，我们还需要修复渲染崩溃或提高滚动性能等，但大多数添加功能的工作都会让它变得更大、更慢。

从长远来看，我很荣幸自己投入了很多精力在这款产品上，我为自己当时所做的工作感到自豪，但这款产品本身是一种我无法控制的生物，从很久以前开始它前进的方向就与我的意见相左。Google 对隐私的处理让我感到特别失望，旧版的 Google 更值得令人尊敬。

反思我们花了多少时间来制作最简单的雏形也很有趣，最初 Chrome 没有“主页”按钮，我记得有一段时间里，我们一直在争论是否将它作为一个选项添加进来，然而如今的浏览器装满了按钮和设置。

Web的命运

我对 Web 的发展有点悲观。在 Chrome 之后，我在一个产品上工作了三年，其创建目标是试图找出某种“拯救报纸”的方法。

每个人都讨厌广告，但没有人针对新闻业如何获得资金提出合理的计划，我认为那个项目的尝试不会成功。在这类的讨论中，难免有人会说一些没有任何帮助的话，比如“如果报纸有合理的支付系统，我会花钱购买”，但纸上谈兵和实际争取到资金完全是两码事。

如今的 Web 感觉就像一个底部围绕着广告的螺旋。虽然我们可以利用 Web 技术制作一些非常漂亮的东西，例如 Figma，但是制作对用户有敌意的垃圾也更容易，而我们获得的大多数产品也跟垃圾差不多。

人们似乎认为屏蔽广告是浏览器的工作，但我的观点是，如果企业的业务开始让人感到反感，那么用户唯一能做的就是停止使用其业务。不知何故，一旦涉及到技术，人们就会开始谈论他们有权单方面要求重新谈判交易。做一个不太恰当的类比：“我讨厌这家商店一根香蕉卖 10 美元，所以我就付2美元，然后拿走香蕉。”

与此同时，唯一真正的非 Web 平台都是由科技巨头（苹果/Google/微软）运营的，他们会毫不手软地打击竞争对手。也许，我不过是对技术整体的发展方向感到悲观。

原文链接：
https://neugierig.org/software/blog/2022/12/chrome.html

更多精彩内容，关注我们▼▼