Google with it’s popular browser, Chrome, had taken over the contribution to the WebKit browser base. Apple now seems to have been throttling the contribution by announcing evolution of the WebKit project called WebKit2.
WebKit2’s aims to bake both “split process model” and a non-blocking API into the WebKit product—and by extension into Safari and any other client which takes advantage of the WebKit2 framework. This means that when a bad plugin or a bug in the renderer causes an error, only that tab (at max) will crash instead of the entire browser.
In fact, IE8 has a similar system (I know you’re surprised) and unfortunately Firefox is still beta-testing it with Electrolysis. Apple had long complained about the unstable or as Steve Jobs calls it “Buggy” Flash implementation on Mac OS. the issue was partially handled in Safari 4 where flash crash didn’t crash the browser itself. Taking a step further, WebKit2 split processes directly into the rendering engine and separates each plugin and its instance to separate processes.
Another goal of WebKit2 is to implement the API to the framework in a completely non-blocking manner. This means that developers can hook into API methods with various kinds of callbacks in order to receive notifications from WebKit views.
Basically, this is achieved using 3 techniques:
- Notification-style client callbacks,
- Policy-style client callbacks, and
- policy settings.
The detail is available on the project page.
What does this means for All WebKit based Browsers?
Apple has done something that would help every webkit-based browser out there. Now this is something way better than what Google has done with Chrome, where the system is closed, benefits cannot be leveraged in other browsers.
WebKit2 is currently available on Windows and OS X– Obviously the two platforms Apple supports its Safari browser. Linux support is not mentioned at this time and I see no reasons why Apple would port it, but the Open source community will, eventually.