都用 WebKit 也并不意味 Web 的统一：WebKit 的前世今生

由 Opera 引发的 WebKit 话题正在网络上引起巨大的争论。知名网评人 Robert Nyman 也在他的博客发表了自己的见解。和别人不同的是，用他自己的话说，他希望用尽可能实事求是的态度，来客观的分析，对于开发者来说，如果当市面上的大多数浏览器都采用WebKit 核心，那会有哪些可能的后果。

WebKit 究竟是什么？

最近 WebKit 这个词铺天盖地，它究竟是什么意思呢？

官方解释：WebKit 是一个开源的 Web 浏览器引擎。WebKit 同时也被 MacOS X 系统的 Safari、Dashboard、Mail 和很多其他 OS X 程序选用为引擎。WebKit 的 HTML 解析器和 JavaScript 解析器代码分别源自 KDE 的 KHTML 和 KJS 代码库。

这就是在说，WebKit 是 Safari 背后的浏览器引擎。还需要补充的是，Apple 在 Safari 里面使用了自己的 Nitro JavaScript 引擎（只用 WebKit 来渲染 HTML）。

有意思的是 WebKit 现在已经不仅仅是苹果在使用，它现在还是 Google Chrome 的内核：

Google 官方说明：Chromium 使用 WebKit 做为渲染引擎。与其打造 Chromium 特有的实现方式，我们更希望去尽可能多的去为使用 WebKit 核心的浏览器做贡献。

这是说 Chrome 也在使用 Nitro JS 引擎？不，Chrome 有他自己的 V8 JavaScript 引擎。简单的说，Chrome 也使用 WebKit，但是它也实现了自己的 JavaScript 处理方式。V8 同时还是驱动 Node.js 的 JavaScript 引擎。

Opera 会使用 Chromium 实现的 WebKit，也会使用 V8 引擎。这就是说虽然 Opera 在宣称自己使用 WebKit，但事实上它使用 WebKit 和 Safari 与其他浏览器使用的 WebKit 并不完全一样。如果你想客观了解现状，这是必须清楚的概念。

现在 WebKit 究竟有多少分支？

所以我们知道现在 WebKit 正在驱动，或者将会驱动 3 个主流浏览器。但是 WebKit 还有多少其他类型的实现？

确实还有很多很多 WebKit 的变种，特别是在移动领域。他们都是 WebKit 的分支。

这些 WebKit 的分支有多少差别？

有一种假设：因为这些浏览器都在使用 WebKit，所以他们也会以同样的方式去支持相同的特性。对于很多基本的特性来说，确实是这样。但是对于很多小众特性，就未必如此了。

举例来说，当 Chrome 开始支持游戏手柄 API 的时候，Safari 不但还没开始支持，而且以后也不太可能支持。另一个例子是 WebGL。做为在 Chrome 已经支持了很久的特性之一，Safari 却才刚刚看到了曙光（而且还是在开发者选项里）。当然，这些还都是比较出名的例子。还有很多试验性的例子潜伏在大众的视野之下。

甚至很多基础的、日常的功能，在不同的代码分支下都有所不同。PPK 完整的总结了这些 WebKit 的差异。

新特性如何加入到 WebKit 中，谁又来负责审核？

现在有许多公司正在为 WebKit 项目贡献自己的力量。

WebKit 项目提交和审查页面提到只能有老的代码提交员和审核员才能提名新的新的代码提交员与审核员。这比较合理。然而，无论 WebKit 项目决定让谁参与进来，最终都还是要让 Apple 来做审核：

当有人被 WebKit 代码提交员成功提名后，Apple 会处理发送代码提交员协议，在签署协议之后，Apple 会继续开通 SVN 账户。

对于这一点并没有什么隐秘的动机，但这确实在告诉大家，WebKit 和很多开源项目一样，并不是真正分散和民主的。权利是且必须是集中的——只有这样才能保证能做出决定，并且把事情做成。

如果一个浏览器迁移到了 WebKit，那是不是意味着（在编写代码的时候）可以少测试一个浏览器了？

不。每个浏览器都有它自己的怪异模式、性能差异、设计，和功能。所以每个浏览器都要测试。

当一个功能加入到 WebKit 的时候，是不是意味着在其他浏览器里就可以使用这功能了？

当然不是。比如游戏手柄 API 的例子。Paul Irish 强调了这样一个事实：WebKit 浏览器们可以挑选究竟把哪些 API 放入他们的版本。比如 Chrome 选择支持游戏手柄 API。很多 API 在 WebKit 的层面就已经被实现了，但是 WebKit 项目书允许关闭这些功能。（编者注：Paul Irish 是 Google Chrome 的员工，他曾在 jQuery 团队工作两年。）

Opera 迁移到 WebKit 究竟意味着什么？

它意味着 Opera 将会为 WebKit 项目投入开发精力，但是更可能的是，意味着这 Opera 将会在有经历为自己的浏览器打造一些其他的功能。

迁移到 WebKit 意味着我们可以把更多开发资源投入到新功能和增进用户体验的解决方案上去。

这也意味着他们不会再继续开发他们的自有 Web 渲染引擎 Presto。

同源和多样化

上面的问题和回答告诉我们，WebKit 们很明显有着相同的源头。在不同的浏览器版本里他们又有着不同的实现，但是归根结底，他们共享着相同的代码库。

这意味着你可以为移动互联网、为性能、为任何你能想到的目标来优化 WebKit。这是件好事儿。而且这必然会带来各种各样的 WebKit 实现，并为解决问题引入更多资源。在最理想的情况下，这些进步会回馈给每个人。

这会带来非常多好处。这也是我们为什么相信，有完全不同的一群人，来打造一个浏览器渲染引擎是非常重要的。

Apple 在 KHTML 上构建 WebKit 是一件好事情。他们当初也可以选择在 Gecko 上做这件事情（编者注：Gecko 是 Firefox 的引擎），但他们选择了创新，给市场增加了多样性，还带领浏览器在过去几年里取得了巨大的进步 —— 这就是竞争带来的直接结果。

如果他们只是做了另一个版本的 Gecko，那我们也不确定我们今天会是个什么情况。

渲染其实并不相同

把 WebKit 先撇一边儿，如果所有的浏览器都使用相同的引擎，这对程序员来说意味着什么？这种情况真的会发生吗？Web 会因此更加美好吗？对开发者来说工作会不会更轻松一些？

最大风险在于程序员们如果相信这些浏览器如果都在使用完全相同的渲染引擎，那么：

• 开发者不会再测试那么多浏览器了，因为他们认为反正浏览器都是 WebKit 核心的
• 开发者也不再测试其他的浏览器引擎了，反正 WebKit 占据了主流
• 开发者将会更多使用 WebKit 引擎独有的代码，而不是专注使用 Web 标准

最可能的后果是程序员会选择——或者被导向——相信内核的统一会让工作变轻松。但是随着时间的流逝，他们会意识到尽管同是 WebKit，也会有很多不同的东西。（编者注：见 PPK 总结的 WebKit 之不同）。

这给 IE 和 Firefox 留下了什么局面？

让我们来清醒一下，看看这对 Microsoft 和 Mozilla 来说意味着什么。现在有很多声音，认为他们应该用 WebKit 来实现 IE 和 Firefox。

但这真的那么容易吗？如果这样的话，所有主流浏览器都会构建于一个相同的代码库。但是还会有很多的可变因素，代码分支，插件，等等。对我们来说，这似乎并不是达到多样性的最佳方式。

如果 IE 和 Firfox 不切换渲染引擎呢？这很可能会是一场精彩的竞赛，并会为我们带来一个光明的未来。但与此同时，这也给 MicroSoft 和 Mozilla 出了难题：他们将在实现各个层级的 Web 标准，提升性能，和很多其他方面耗费很多精力，并遇见重重挑战。

如果市场份额逐渐萎缩，让 WebKit 完全统治？也许人们将会使用 IE 和 Firefox，而不使用 WebKit？

在未来的岁月里，Firefox 和 IE 有没有被逐渐淘汰的风险？或者他们会成为不同的因素留在市场上？

浏览器厂商的动机是什么

除了现在已经有很多不同 WebKit 版本的事实以外，还有很多 Web 浏览器在参与竞争，试图与众不同。其中一些相信竞争很大程度将会体现用户体验领域。这点没错，但是在此领域以外，也有很多竞争点。

在《WebKit 的悲剧》一文中提到的那样，谁会对花钱花资源来为竞争对手修补 bug 呢？

看上去大家更有可能会把精力花在新特性，新功能上，因为这会才让他们在竞争中脱颖而出。

在这一点上，你将如何发现新的元素呢？新功能在某些程度上还会被发现。但是 CSS 呢？一个 -webkit 前缀的 CSS 属性意味着什么？其实什么意义都没有，除了它会支持 IE 和 Firefox 以外的任何其他浏览器。下一步又会发生什么？更多的浏览器厂商的 CSS 前缀吗？

WebKit 是好的

允许我们强调一下，WebKit 是好的。它有开放的流程和强大的贡献者。我们只是想澄清一个当下被广泛接受的错误概念——一个 WebKit 等于所有 WebKit，还有——如果所有浏览器都选择 WebKit，那么对开发者来说，工作会变得更轻松。

我的意思是说，与众多独立的浏览器引擎会为市场带来多样性一样，WebKit 在这一点来说，同样会表现的很棒。