The actual phrasing is "antiquated style of process isolation", which leads me to believe that he's not saying that process isolation is inherently antiquated, but that the way Chrome does it is.
In that case, it still needs some explanation. Chrome's process allocator is apparently pretty complicated, so assuming a reader knows enough to just take it as read as "antiquated" is a bit much.
> The actual phrasing is "antiquated style of process isolation", which leads me to believe that he's not saying that process isolation is inherently antiquated, but that the way Chrome does it is.
That was my assumption too. Chrome's IPC was developed in secret and never made it into WebKit, instead, Apple later developed WebKit2 - in part as a response to Chrome's IPC - that does IPC for WebKit in a different way. It sounded like the author was saying that Google's way, which is older than WebKit2, is inferior.
I don't see how the fact that Chrome was secret prior to its 9/2/08 launch matters much here. It's existed publicly for ~4.5 years at http://src.chromium.org/viewvc/chrome/trunk/src/ and all of the code is pretty actively developed [1] & [2]. Chromium has now been public much longer than it existed privately, and for any particular file in Chromium, the odds are good that it's substantially different from launch day.
Chromium WebKit does not directly provide a multiprocess framework, rather, it is optimized for use as a component of a multiprocess application, which does all the proxying and process management itself. The Chrome team at Google did a great job at trailblazing multiprocess browsing with Chrome. But it's difficult to reuse their work, because the critical logic for process management, proxying between processes and sandboxing is all part of the Chrome application, rather than part of the API layer. So if another WebKit-based application or another port wanted to do multiprocess based on Chromium WebKit, it would be necessary to reinvent or cut & paste a great deal of code.
> I don't see how the fact that Chrome was secret prior to its 9/2/08 launch matters much here.
It might not, yeah. But I've heard theories that part of the reason it never made it into WebKit was how it was developed in secret and how that annoyed Apple. Together with v8, another secretly-developed project that also did not replace it's parallel in WebKit.
I won't speculate on why people make the technology decisions they do - and in this case I'm somewhat distant from the WebKit team.
I am pretty familiar with Chrome's multiprocess webview harness. This is one case where approx. 2 years ago it was incestuously tied with a lot of Chrome-the-desktop-browser internals. Part of the technical debt accumulated with the sprint to ship something. So I can see why back then it wasn't appetizing as-is.
A heroic effort by a team of engineers finally managed to separate it in 2012 into "content" (not Chrome, get it?) and set up its own shell, suite of tests, and public API for use by embedders (one of which is src/chrome, but there are others now even within Chromium). It's still not as elegant as I think any of us would like, but it is now usable from a standalone app.
One of these days I need to write a series of posts about some of the "big C++ app design" lessons we've learned as a team over the past few years.
It would be pretty ironic if Apple were actually annoyed that Chrome was developed in secret considering they forked KHTML and developed it into Safari & WebKit in secret in essentially the same way.
In that case, it still needs some explanation. Chrome's process allocator is apparently pretty complicated, so assuming a reader knows enough to just take it as read as "antiquated" is a bit much.