实际上已经不算「新闻」了，好几天前，Google宣布他们从WebKit项目fork出来的项目——Blink！以便更方便、快速地实现Google工程师的目标。毕竟控制WebKit项目的是苹果而不是谷歌。
可是，我想提醒各位读者，Google的Blink是源于WebKit而不是WebKit2，而WebKit2这个全新的API层已经有几年历史了。WebKit2的实际控制者当然也是苹果，苹果给出的解释是谷歌不愿意把Chromium的多进程等代码合并到WebKit分支，所以苹果着手开发了一套新的多进程机制以及一些其它一些大的变化。
其实Chromium和Apple Safari并不完全相同，虽然都是WebKit，但是Chromium使用的是V8 JavaScript解析器，而Safari不是。我的观点就是这个分裂的祸根早就埋下了，苹果和谷歌不可能可以手拉手一起捣鼓WebKit！
可能有人不知道，WebKit是从KDE项目团队开发的KHTML fork出来的（壮哉我大KDE！）。
现在的情况自然是WebKit那边要开始清理Google的诸如V8、WebLayer、Skia等代码（Google fork了Blink自然不会再维护WebKit的代码，清理无人维护的代码是自然的事情），然后Blink开始精简瘦身，去掉Google不需要的代码。
一个月前Opera宣布放弃Presto转用WebKit/Chromium的时候，本以为浏览器渲染引擎要大一统，WebKit完胜。结果Google突然抛出Blink项目（Opera马上表示跟进使用Blink，严重怀疑Opera化身Google的桥头堡），估计往后WebKit和Blink的差异将越来越明显，就像现在的WebKit和KHTML已经截然不同了。
我太不同意36kr上的观点，即Blink会体现出对WebKit的优势，也不认为多数开发者都会跟进Blink。大多数网站考虑的还是兼容性，不大可能去支持一些Blink独有的功能，想想那个Native Client，至今没看见使用这个技术的大型网站。
此外，像GTK+和Qt对WebKit2的移植也是两三年的工作了，基本成熟稳定可用了。对于GNOME/KDE来说，不大可能抛弃WebKit2改用Blink，苹果、微软、Mozilla更是100%不会，这样来说，只有Google和Opera两家会使用Blink引擎。开源浏览器对浏览器市场份额固然贡献极其微弱，但是开源项目的工程师贡献还是不容忽视的。所以我的观点就是Blink和WebKit2半斤八两，加上Google杀死Google Reader的作法，结局难说。
Google fork Blink倒是有一个比较重大的好处的，保持浏览器渲染引擎的多样性——死掉Presto，来一个Blink，正好引擎数量不增不减。倒是前端工程师还得继续装N个浏览器的日子了！
Comments
7 responses to “Blink和WebKit2，谁代表下一代WebKit？”
事实比楼主判断的来得更快一些，http://www.zdnet.com/apple-out-google-in-as-qt-dumps-webkit-for-blink-7000020637/，QT已经转向Blink了，开源精神不是YY，那些想利用开源的闭源公司必将被人所失信!
我这篇文章是四月写的，Qt转向Blink/Chromium是九月的事情。怎么说呢，Qt并非完全社区驱动的（背后有Digia），这也是Digia作出的决定，为了省事……而GTK+暂时还没投奔Blink的，Qt启用Blink/Chromium至少要到Qt 5.3，现在Qt 5.2还没release呢（不过只有几天就要发布了）。
P.S. 开源社区对Google的恨的人不一定比爱的人少。不少人认为现在的Google正是利用开源的商业公司，想想其开源并非开放的软件（Chromium、Android、Chromium OS都是）。
Firefox 的 Gecko 和 Google 的 Blink 都在为消除 CSS 中的实验性功能的前缀 -webkit- -moz- 而战 =_= 倒是方便了前端工程师，现在 Opera 跟进 Webkit 和 Blink ，也是在为消灭 -o- 前缀而战。好一伙战友
啊哈，这我倒不知道，我不搞前端，对这方面没研究呢。倒是觉得各平台WebGL的实现可能更紧要吧。
没了前缀，对于喜欢紧跟 HTML5 的网站，CSS代码和兼容的JS代码可以省掉一大堆～
WebGL还要考验硬件性能呢，电量和CPU和内存暂时有点耗不起啊……不过那个P2P通讯功能，在国内不知道会怎么样，不知道会不会搞出什么类似以前的MSN和QQ大战的问题，囧。
啊，P2P 应该是 WebRTC 的，我说错了……
嗯，那倒是。总之HTML5任重道远，可能要再过一两年才会集中爆发吧。