最近Opera宣布，它将推出新的浏览器，不再使用自己的Presto引擎，而是使用眼下越来越留下的WebKit引擎。WebKit要一统Web了吗？对于这个问题，知名网评人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在这一点来说，同样会表现的很棒。