近日有两则与浏览器开发相关的重要新闻：一个是Google和Opera支持WebKit的分支Blink；另一个是Samsung将与Mozilla合作，共同推动Servo。Blink和Servo均以并行架构为目标。
不久之前，Opera宣布放弃自己的浏览器引擎Presto，拥抱WebKit。当时有人还担心，少了一种多样性对Web会有何种不利影响。现在他们不必烦恼了，因为Google从WebKit创建了一个分支——即名为Blink的抽象浏览器引擎，其开发会与Chromium结合在一起，由后者提供该平台的一种实现。Opera的Web布道师Bruce Lawson宣布，Opera将与Google一起开发Blink。
WebKit渲染引擎现在势头很猛，而且或许有机会成为最重要的引擎，那Google为什么要创建一个分支呢？Google认为，尽管“只有一种选择看上去对开发者的效率有利”，但从长期来看，“只有一种选择不可避免地会导致停滞不前”，而“如果有更多的渲染引擎可以选择，这会带来更多创新，也会使Web生态系统更健康”。
据Google介绍，之所以创建WebKit分支，有两个主要的技术原因：
- 与其他基于WebKit的浏览器相比，Chrome使用了与众不同的多进程架构。此举给WebKit和Chrome都带来了一定的复杂性，延缓了创新的步伐。
- Blink提供了一种选择，Google可以根据自身需要改进其浏览器性能，引入并行处理机制也是一个主要方向。
简而言之，Google希望“像V8对JavaScript所做的改进一样，改进网络、渲染和布局。还记得V8之前的JS引擎吗？我们希望带来同样健康的创新，让使用各种浏览器的Web用户都能受益”。
看来Google希望能够根据自己的需要自由推动WebKit的开发，不必遵守WebKit的开发协议，而且能增强自己控制力更强的Chromium。要成为Blink的提交者（Committer）或所有者（Owner），其他开发者必须遵从Google制定的指导原则。
Google的第一步是重新组织所继承的WebKit代码，“移除了7个构建系统，删除了7000多个文件——包含的代码超过450万行”。从长期来看，Google希望向Blink中引入一系列改进，包括：
- 进程外的iframe，支持在单独的沙盒进程中运行不同的页面组件。
- 更快、更简洁的网络，目前受限于“旧的Mac WebKit API条款而无法修改”。
- 将文档对象模型（DOM）整个移到JavaScript中。这有可能大大加快JavaScript DOM访问速度。
Google还考虑了如下可能的改进：
- 让WebCore了解多个进程内的历史记录信息（目前假定的是同步访问同一进程内的历史记录信息）
- 删除Widget树（原来受到Mac WebKit1的限制）
- 将WebCore分到多个模块中
- 尽可能让代码直接使用沙盒Platform API，代替WebCore/Platform API
- 建立一种更简洁、更严格的tree-gardening系统，避免每天需要两个全职工程师参与的情况
- 尝试把DOM移到JS堆中
- 增加对多核的利用（比如，改进HTML解析器、样式引擎和JavaScript解析器等模块）
- 去掉DOM中不够清晰的部分，这些部分可以做一些向后不兼容的修改，这样有利于提高性能或降低复杂性
- 在Mac Chrome中全部使用现代的、速度更快的tcmalloc
- 尝试增量式布局或并行布局
- 因为现在只有一个JavaScript引擎，所以可以移除ScriptValue/ScriptState等抽象概念，以此来修复内存泄漏问题
- 使用WebIDL替换WebKitIDL，移除定制的JavaScript绑定代码
- 改进WebCore，使之赶上DOM3 Event/[DOM]UI Event
新浏览器引擎的出现引发了Web开发者的担忧，他们必须确保其代码能在新的浏览器上正确运行。为缓解开发者的焦虑，Google引入了与Mozilla开发Firefox类似的机制。
我们的目标是推动创新，改进兼容性，开放Web平台，同时避免加入很多特性，避免破坏与其他浏览器的兼容性。关于新特性的添加、厂商前缀（Vendor Prefix）的使用，以及新特性何时才算足够稳定进而可以交付等问题，我们面向开发者引入了强有力的策略。
Firefox今天所用的Gecko引擎并不是基于WebKit的，不过二者高度兼容。我们会采用与Mozilla类似的方式，提供一个独特但兼容的开源引擎。我们也会继续开放Bug跟踪和实现状态，开发者随时可以看到我们在干什么，并做出自己的贡献。
另一个重要策略与厂商前缀有关，Google不打算将其用于新特性中了：
与之相反，我们会暴露一个设置入口（在about:flags 中），以便支持实验性的DOM/CSS特性，用户可以在此看到新添加的特性，进而加以试用并提供反馈，很像目前使用的“Experimental WebKit Features”标记。只有当我们想看看这些特性能否稳定交付时，才会在dev/canary版本中默认启用。
对于遗留的与厂商前缀有关的特性，我们会继续使用-webkit-前缀，因为重命名所有前缀会给开发者带来不必要的麻烦。我们已经着手研究实 际中应用的HTML5和CSS3特性，借助调研数据，可以更好地指导我们如何可靠地弃用相关前缀所指定的属性和API。至于从WebKit继承而来的任何 非标准特性（如-webkit-box-reflect），我们希望具体问题具体分析，随着时间的推移，将其标准化或是弃用。
至于一般性的Android和移动开发，Google希望“整个移动Web平台与Blink同步，甚至走在Blink的前面”。
之后WebKit就主要由Apple掌控了，这是Blink带来的副作用之一。Apple能否快速推进WebKit，使其跟上其他浏览器的步伐？我们拭目以待。
就在Google宣布Blink几小时前，Mozilla宣布与Samsung合作，共同推进Servo的开发。这是用Rust开发的一个并行浏览器项目，作为“利用明天速度更快的多核异构计算架构”的一种尝试。Servo是“完全从头开始重新构建的Web浏览器”，纳入了安全机制，并支持高度并行的硬件。
第一步是让它运行在Android/ARM上，到目前为止，Samsung的主要贡献是“Rust的ARM后端，以及支持Android交叉编译所必需的构建基础设施”。
目前，Servo是运行在Mac OS X和64位Linux上的一个原型浏览器引擎，因为它所用的编程语言尚未成熟，很可能还要承受成长之痛。Mozilla在同一天宣布了Rust 0.6，但该语言要达到稳定，至少还需要一年的时间。在此期间，他们要“争取完成Rust的第一个主要版本——完成库的清理、扩充和文档化，构建改进用户体验的工具，增强性能”。