WebKit 是浏览器引擎的 jQuery(WebKit is the jQuery of Browser Engines)

By | 2018年7月12日

The news has just come out that Opera is switching all of their browsers (both mobile and desktop) to use WebKit (specifically, Chromium). I’ve seen a lot of gnashing of teeth on Twitter and I feel like I can respond because I use to feel the same way back in 2008-2009. However this is 2013 and the Chrome/Chromium team has made it obvious that any form of stagnation or lack of innovation does not need to occur when using WebKit. In fact it possibly gives you the ability to accelerate your development, spending less time worrying about implementing common standards. I would argue that WebKit (a common framework for implementing the standards-compatible portion of a web browser) is exactly like jQuery (a common framework for implementing a DOM standards-compatible experience in a web page) at this point.


These are a few arguments against the switch that I’ve seen so far:

A browser switching to WebKit will result in stagnation

That is demonstrably not true. KDE created KHTML, Apple created WebKit based upon that, Google created WebKit/Chromium based upon that. I don’t think anyone can successfully argue that Chome/Chromium isn’t a better browser than Safari which isn’t a better browser than Konqueror. The Chrome team has proved that stagnation when using WebKit is merely a choice, as a contributor to WebKit you have the complete ability to drive it in a direction you wish (often for the better). I see no reason why the highly-skilled development team at Opera won’t be able to do the same. They can implement a number of their Opera-specific features into WebKit and it’s likely that those features will start to trickle back into other WebKit-using browsers as well.



Twitter Bootstrap
HTML5 Bolierplate

This will affect Opera’s ability to influence standards

I don’t see the switch to WebKit causing this. I do see Anne van Kesteren‘s move to Mozilla as being a massive blow to Opera’s ability to push standards though. I don’t know anything about the situation but if his moving was caused by the switch to WebKit then yes, Opera’s move to WebKit has affected their ability to influence standards.


Anne van Kesteren从Opera跳槽到Mozilla确实是Opera推进Web标准能力的巨大打击。但我对内幕一无所知,但是如果他的跳槽是源自这次浏览器引擎的切换,那么Opera影响Web标准的能力确实遭受到了损失。


Opera switching to WebKit is a slippery slope and/or Opera is a small player, Firefox or IE switching to WebKit would be a bigger problem

I think one this is clear already: WebKit has completely and unequivocally won mobile at this point. They are nearly the only rendering engine used on the vast majority of mobile browsers, including the soon-to-switch Opera Mini/Mobile browsers too. There is no reason to worry about a slippery slope, the slope has already been slid down. In order for any other browser to remain relevant in the world of mobile (which, you must admit, is quickly becoming the only world we live in) they must keep feature parity with WebKit. Let’s follow this to its logical conclusion: In a world in which WebKit is now virtually the only mobile browser vendor Mozilla and Microsoft will feel increased pressure to switch their browser engines over to WebKit in order to keep pace. Google has proved that with Chrome that WebKit stagnation is simply a choice so there’s no reason why these other companies shouldn’t be able to build off of WebKit (and possibly create WebKit hybrids, such as WebKit + IonMonkey).


我认为有一点已经非常清楚了:目前WebKit在移动端已经非常明确的大获全胜。包括即将切换到WebKit上的Opera Mini/Mobile,WebKit几乎是市面上绝大多数移动浏览器所选用的唯一渲染引擎。如果任何其他浏览器想要在移动世界占据一席之地,那它必须和 WebKit在功能上保持一致。让我们在此得到一个逻辑上的结论:在移动世界已经被WebKit统治的情况下,为了保持同步,Mozilla和 Microsoft将会感受到巨大的压力来迫使他们将自己的浏览器也切换为WebKit。Google已经通过Chrome证实了使用WebKit并不会 导致发展停滞,其他公司更没有理由不来继续打造WebKit(有可能会创造WebKit的混合体,比如WebKit+IonMonkey)。


The big question becomes: Should they switch?

At this point it’s honestly a business/engineering decision for Mozilla and Microsoft (as it always has been). If some percentage of your developer force is spending all of their time implementing the same standards that everyone else is implementing then switching to a common code base will give you the ability to free up some of your developers to work on something else. You saw what happened in the case of Chrome: They used their extra developer time to completely crush the competition on performance. This resulted in the everyone-wins race to become the fastest browser.


老实说,在这一点上,对Mozilla和Microsoft来讲,这成了一个商业问题,或者是工程问题。如果你的一些开发者要花他们所有精力去实现 别人正在实现的相同标准,那么切换到一个公共的代码库(指WebKit,编者注)将会解放你的劳动力,让你可以做点儿别的事情。你可以看到Chrome的 例子:他们解放出的生产力全面投入到了性能的竞赛上。这个打造最快浏览器的比赛促进了大家共赢的结局。


Ultimately it’s important to remember that WebKit is not a monolithic entity. It’s a shared codebase that a number of corporations contribute to. (In this respect it’s different from jQuery: Almost all contributions to jQuery comes back into the main codebase, whereas with WebKit some come back to the main codebase and some stay in a fork.) There is a lot of code sharing going on but it isn’t the be-all and end-all of browser development. Innovation can clearly still occur when working on a shared codebase and performance will almost certainly continue to improve.

最后,我们一定要了解,WebKit并不是一个完整的实体。他是一个有多家公司贡献代码的共享代码库。(从这方面来说,这和jQuery并不相同:几乎所 有的jQuery代码贡献最终都回到它的主代码库,而WebKit的有些更新则只保留在分支之中)。使用一个共同的代码库并不意味着这是浏览器开发的一 切,更不是浏览器开发的终结。在一个共享的代码库中仍然可以有持续不断的创新,它的性能也当然会一直提升下去。



电子邮件地址不会被公开。 必填项已用*标注