> In other words, Google's main technical advantage would be baked into the browser engine itself and made available for everybody. This is a bit of a silly na

> In other words, Google's main technical advantage would be baked into the browser engine itself and made available for everybody. This is a bit of a silly narrative built on what's basically different architectural decisions. Chrome embedding was intended to be through CEF (which was fully multi-process), while WebKit through WebCore. You could just as easily say that Apple decided not to do the hard work of migrating Chrome's multi-process architecture into WebKit and instead made a hard break and just started landing incompatible changes. From the thread you posted, you can even see a WebKit embedder at KDE blindsided by the news[1]. But in reality, browsers are hard, and in a way WebKit and Chrome were always forks but with shared components. The Blink fork was just a fork of one of the biggest of those components and a formalization of what was pretty much always the case by moving to separate source control, code review, etc. [1] https://lists.webkit.org/pipermail/webkit-dev/2010-April/012248.html https://lists.webkit.org/pipermail/webkit-dev/2010-April/012...