3 ms·

Google forked WebKit and called it Blink, which Chrome uses. It might be partly this but I guess also that Google prioritized implementing a multi-process archi

Google forked WebKit and called it Blink, which Chrome uses. It might be partly this but I guess also that Google prioritized implementing a multi-process architecture.

kitsunesoba 9y ago
As I understand, the fork was more about architectural disagreements between Google and the WebKit team. For instance, in Chrome the multiprocess system is part of Chrome whereas WebKit does multiprocess within WebKit itself. This means that anything embedding WebKit2 automatically gets multiprocess, where to get the same with Blink you've gotta fork Chromium. Now that I think of it, Google seems to take this approach with a lot of features. I guess that's why everything based on Blink forks or embeds Chromium instead of using bare Blink.
- rlanday 9y ago
  A couple clarifications: - My understanding is that the Blink fork happened because Google was the primary contributor to WebKit prior to the fork, and Google engineers were spending a significant amount of time trying to make Apple engineers happy. Additionally, there was a lot of code needed to support both Apple's and Google's JavaScript engines and multi-process implementations, which was no longer needed after the fork. WebKit2 and the Chromium multi-process architecture did exist for some time before the fork. - WebKit2 is a layer on top of WebCore, which is the part Blink forked. So both WebKit and Chrome implement multi-process in another layer on top of the renderer. I'm not familiar with WebKit2, but in Chrome, this is done in the content layer, which provides most of the core rendering code (including the multi-process stuff), but without all the browser-specific features (e.g. autofill, extensions, spell check, etc.). I believe Opera is currently built on top of the Chromium content layer.
  - gsnedders 9y ago
    This is more or less my memory of the fork. Google were a major contributor, wanted to make some different decisions in various places to Apple and spent lots of time trying to make Apple happy, and concluded the quickest way to make progress was to fork and not have to convince other contributors (even with the resultant loss of contributions from others). Opera is indeed built on the Chromium content API (v. the Chromium Embedded Framework, which provides a stable API but was less power), and that was a design choice made prior to the Blink fork and hence why Opera followed Google to Blink.

Google forked WebKit and called it Blink, which Chrome uses. It might be partly this but I guess also that Google prioritized implementing a multi-process architecture.

kitsunesoba 9y ago

As I understand, the fork was more about architectural disagreements between Google and the WebKit team. For instance, in Chrome the multiprocess system is part of Chrome whereas WebKit does multiprocess within WebKit itself. This means that anything embedding WebKit2 automatically gets multiprocess, where to get the same with Blink you've gotta fork Chromium. Now that I think of it, Google seems to take this approach with a lot of features. I guess that's why everything based on Blink forks or embeds Chromium instead of using bare Blink.

rlanday 9y ago
A couple clarifications: - My understanding is that the Blink fork happened because Google was the primary contributor to WebKit prior to the fork, and Google engineers were spending a significant amount of time trying to make Apple engineers happy. Additionally, there was a lot of code needed to support both Apple's and Google's JavaScript engines and multi-process implementations, which was no longer needed after the fork. WebKit2 and the Chromium multi-process architecture did exist for some time before the fork. - WebKit2 is a layer on top of WebCore, which is the part Blink forked. So both WebKit and Chrome implement multi-process in another layer on top of the renderer. I'm not familiar with WebKit2, but in Chrome, this is done in the content layer, which provides most of the core rendering code (including the multi-process stuff), but without all the browser-specific features (e.g. autofill, extensions, spell check, etc.). I believe Opera is currently built on top of the Chromium content layer.
- gsnedders 9y ago
  This is more or less my memory of the fork. Google were a major contributor, wanted to make some different decisions in various places to Apple and spent lots of time trying to make Apple happy, and concluded the quickest way to make progress was to fork and not have to convince other contributors (even with the resultant loss of contributions from others). Opera is indeed built on the Chromium content API (v. the Chromium Embedded Framework, which provides a stable API but was less power), and that was a design choice made prior to the Blink fork and hence why Opera followed Google to Blink.