[bostik]

> root cause is that Chromium is well suited to being embedded

Bingo. Let's not forget, Chromium itself is built off a fork of kHTML, the rendering-engine-as-a-library originally developed and used by KDE project.

Apple forked kHTML and released WebKit. That gave the world Safari. Not long after, WebKit became the engine powering Chromium/Chrome, but with process isolation and high-octane JavaScript interpreter (V8). Then quite some time later, frustrated by Apple's control over the engine, Google forked WebKit and came out with Blink.

Sometimes the only difference between provenance and history is the written narrative.

[toyg]

Yeah, WebKit really tilted the scale. KHTML had been built to be easily embeddable already (since it was supposed to be used across the whole KDE desktop, following what MS had done with "Active Desktop" in Windows 2000/XP), and Apple gave it the polish and popularity to make it the obvious choice. Any org or ecosystem who needed a rendering engine rushed to wrap WebKit, and that included Google.

[darklion]

> Then quite some time later, frustrated by Apple's control over the engine, Google forked WebKit and came out with Blink.

I see you've bought into Google's historical revisionism.

When Google introduced multi-process rendering into Chrome, it was a massive technical innovation, but it was built at such a low level that it was effectively proprietary to Chrome. No one else could use it without pretty much adopting all of Chrome.

Apple (along with the rest of the technical world) recognized the benefits of multi-process, but Apple wanted to ensure that literally anyone building a WebKit-based browser could gain the benefit of multi-process rendering. So they created WebKit 2 [1]:

"WebKit2 is designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process. This model is similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients to use it."

In other words, Google's main technical advantage would be baked into the browser engine itself and made available for everybody.

As you can imagine, Google was less than thrilled, and the differing natures of the multi-process implementation led to duplication and complexity. So, when Google decided that supporting multiple architectures was too much work, it had a choice.

Google could do the hard work of switching Chrome's multi-process rendering to WebKit 2, which would mean a significant browser rework, but it would mean that any and all browsers derived from WebKit would have all of the same basic capabilities, and at the same level, as Chrome itself.

Or, Google could use it as an excuse to proprietize its work by forking, thus ensuring that any future stream of enhancements made to the browser would only benefit Google and Chrome instead of everybody.

In the end, Google decided that the only thing it cared about was itself:

"However, Chromium uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects. This has slowed down the collective pace of innovation - so today, we are introducing Blink, a new open source rendering engine based on WebKit."

So remember, when Google made a proprietary technical leap in an otherwise open source project, it was Apple, not Google, who made sure that everyone could benefit from the same technical leap. And when it became too difficult to maintain two versions, it was Google, not Apple, who forked the engine and the community in order to proprietize improvements for their own gain.

--

[1] https://lists.webkit.org/pipermail/webkit-dev/2010-April/012... [2] https://blog.chromium.org/2013/04/blink-rendering-engine-for...

[magicalist]

> 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/012...