Google shipped their multi-process implementation years before Apple’s huge re-architecture of WebKit (which many forget now but lead to incredibly buggy behavi

Google shipped their multi-process implementation years before Apple’s huge re-architecture of WebKit (which many forget now but lead to incredibly buggy behavior for years too). They were able to ship earlier, and arguably at all, precisely because they just made separate processes that each had WebKit in them instead of doing a major change inside of WebKit. Had they tried to do the latter, the fork would have just happened sooner since everyone would have screamed that they were trying to completely change WebKit as complete newcomers: don’t forget, this was the major feature they shipped Chrome with. I’m personally happy that they set the standard that everyone then followed back in 2008 as opposed to having their initial foray into the browser space be some big RFC to change WebKit. Having worked with it at the time, I was initially skeptical too. However, after working in the code, it definitely felt more natural to have the processes around WebKit instead of inside WebKit (as would be the case with most libraries). Ultimately, Apple’s approach took longer and lead to a big API-incompatible change (A “fork” level change arguably, but when it’s your own repo it’s not a fork, it’s just “2 point 0”). Not saying that’s bad, but Google's goal was to ship Chrome in 2008 and not have some huge incompatible diff with WebKit. Both made decisions appropriate to them, and in the end, gasp, we got two cool multi-process implementations, what a failure story for open source!