参考：Why blink
在多进程架构上，Google一开始就独自开发了一套沙盒多进程架构，它和后来由Apple主导的WebKit2多进程架构差异很大，为了支持WebKit2架构而加入WebCore的大量代码，对Google不但一点用也没有，还不得不花时间去处理兼容性的问题，而Google需要修改WebCore来支持自己架构的代码又很难进入WebKit主干，必须很小心处理避免影响其它的Port，大量的代码不得不通过迂回的方式放在外部处理，一些没方法在外部处理而需要对WebCore进行大改的特性不得不暂时放弃。
并且，因为历史原因，WebCore本身一开始就没有多线程或者多进程的概念，现有的架构对并行处理的支持非常困难，Google也认为必须对WebCore进行整体架构上的大改才能更好的支持并行处理，更充分利用多核CPU的能力，避免主线程过度拥挤（虽然现在大部分的WebKit Port都把主要的渲染工作分离到其它线程，但是主线程仍然需要负担HTML解析，CSS样式计算和匹配，排版，JS执行等繁重的任务，为了避免单项任务长时间阻塞主线程，WebCore目前是用延时Timer的方式将一个复杂任务分解成多段来顺序执行，这种方式即不优雅，更无法充分利用多核的能力）。
另外，WebCore现在的模块化比较混乱；一些历史遗留的代码和仅仅用于支持某些特定平台的代码导致WebCore代码臃肿不堪；平台相关的处理也没有一个统一的标准和方式，没有一个很好的抽象层去隔离平台相关和平台无关的部分；WebCore为了可以同时支持不同的JS虚拟机（如JSC和V8）导致了额外的性能开销和妨碍了对JS性能更多的改进；除此以外，更安全的隔离机制；对现有的网络层进行更大的结构优化等等这些原因也是Google需要自己发展Blink的主要原因。
总之，Chrome有太多激进的改进需要对WebCore进行大改，而原来那种在外围做文章，曲线救国的方式再也行不通，为了能够自行主导架构的演进方向，避免跟其它Port相互干扰，相互扯皮给双方带来的困扰和痛苦，加快开发的速度，从WebKit主干分离，自己发展新的浏览器引擎就成了必然的选择。
