I also worked on web browsers (my name is still there in Chromium AUTHORS, for example, and I think Evan even reviewed my patch once) in the similar time frame, so here are my comments as I remember, mostly related to Apple, probably representing more of Apple’s point of view.
WebKit fork mainly happened over multiprocessing. Chrome wanted to ship with multiprocessing, and for many reasons the best place to implement it is in WebKit layer, but such large changes would have been impossible to integrate back, so Chrome’s multiprocessing is built on top of WebKit, even if it is a layering violation. When Apple implemented multiprocessing, naturally they implemented it in WebKit layer and named it WebKit2 (retrospectively renaming the original WebKit1), and at that point Google was uninterested in migrating to WebKit2. And then some changes had to be made twice in WebKit1 and WebKit2 and Google didn’t want to touch WebKit2 and Apple didn’t want to touch WebKit1, etc. I don’t feel like “Google wanted WebKit to do things Apple didn’t” is a good description of the situation, although of course it was ultimately that. It’s closer to “Apple didn’t want codes they don’t use at all”.
I also object to “Apple cares about making a browser that renders web pages just adequately enough to be acceptable”. I think conflict of interest is genuine, but it’s closer to “Apple cares about rendering currently existing web pages superbly” vs “Google also cares about rendering future web pages”. JavaScriptCore vs V8 is a perfect example. V8 didn’t have an interpreter for a long time, and while V8 won benchmarks, JavaScriptCore rendered the web (but not demos) faster, because actually existing JavaScript at the time wasn’t executing long enough to compensate JIT overhead. In other words, Apple optimized over Web-2010 in 2010, and Google optimized over Web-2020 in 2010, sometimes even to the detriment of Web-2010. There’s also latency vs battery. Executing already fast JavaScript faster saves battery (which Apple cares about) but doesn’t improve latency if the goal is to get below some threshold human perceives as immediate (which Google cares about) and it was already below the threshold. And so on.
Yeah the way I would look at it is that Google was building Docs, Sheets, and Slides in the browser, not to mention GMail and Maps (and even full-blown Google Earth, which used to be a desktop app !)
Also I believe ChromeOS design requirements even pushed a SSH client into the browser codebase
Those are all extremely taxing workloads for a browser (and arguably putting lipstick on a pig, etc.)
Whereas for Apple, the equivalent of all those are native apps for OS X (except maps I guess). They have iCloud but I think it’s mainly a backend for native apps
From my naive outside perspective, I think both of the perspectives on Apple’s relationship with browser development can be true at once. In particular, I think
“Apple cares about making a browser that renders web pages just adequately enough to be acceptable”
has been true at a business level (i.e., that’s where the financial interests lie, so that’s what non-technical leadership will incentivize) and
“Apple cares about rendering currently existing web pages superbly”
has been true at an engineering level (i.e., people whose job it is to work on WebKit will naturally focus on that, since they have the time to do it and it matches Apple’s user-facing product ethos).
On saving newspapers: I don’t think newspapers need saving. Newspapers have great influence, and they will be funded for that. Let’s say, ads go to zero and all newspapers are bankrupt, except BBC, NHK, NPR, and Al Jazeera. Is that a problem? I don’t see a problem.
Newspapers as they currently exist arguably don’t need saving, because they are mostly putting out flamebait, and recycling content from other sources.
Newspapers as they existed in 1990 or 2000 were useful – they funded investigative research when there was no alternative.
A great retrospective!
I also worked on web browsers (my name is still there in Chromium AUTHORS, for example, and I think Evan even reviewed my patch once) in the similar time frame, so here are my comments as I remember, mostly related to Apple, probably representing more of Apple’s point of view.
WebKit fork mainly happened over multiprocessing. Chrome wanted to ship with multiprocessing, and for many reasons the best place to implement it is in WebKit layer, but such large changes would have been impossible to integrate back, so Chrome’s multiprocessing is built on top of WebKit, even if it is a layering violation. When Apple implemented multiprocessing, naturally they implemented it in WebKit layer and named it WebKit2 (retrospectively renaming the original WebKit1), and at that point Google was uninterested in migrating to WebKit2. And then some changes had to be made twice in WebKit1 and WebKit2 and Google didn’t want to touch WebKit2 and Apple didn’t want to touch WebKit1, etc. I don’t feel like “Google wanted WebKit to do things Apple didn’t” is a good description of the situation, although of course it was ultimately that. It’s closer to “Apple didn’t want codes they don’t use at all”.
I also object to “Apple cares about making a browser that renders web pages just adequately enough to be acceptable”. I think conflict of interest is genuine, but it’s closer to “Apple cares about rendering currently existing web pages superbly” vs “Google also cares about rendering future web pages”. JavaScriptCore vs V8 is a perfect example. V8 didn’t have an interpreter for a long time, and while V8 won benchmarks, JavaScriptCore rendered the web (but not demos) faster, because actually existing JavaScript at the time wasn’t executing long enough to compensate JIT overhead. In other words, Apple optimized over Web-2010 in 2010, and Google optimized over Web-2020 in 2010, sometimes even to the detriment of Web-2010. There’s also latency vs battery. Executing already fast JavaScript faster saves battery (which Apple cares about) but doesn’t improve latency if the goal is to get below some threshold human perceives as immediate (which Google cares about) and it was already below the threshold. And so on.
Yeah the way I would look at it is that Google was building Docs, Sheets, and Slides in the browser, not to mention GMail and Maps (and even full-blown Google Earth, which used to be a desktop app !)
Also I believe ChromeOS design requirements even pushed a SSH client into the browser codebase
Those are all extremely taxing workloads for a browser (and arguably putting lipstick on a pig, etc.)
Whereas for Apple, the equivalent of all those are native apps for OS X (except maps I guess). They have iCloud but I think it’s mainly a backend for native apps
From my naive outside perspective, I think both of the perspectives on Apple’s relationship with browser development can be true at once. In particular, I think
has been true at a business level (i.e., that’s where the financial interests lie, so that’s what non-technical leadership will incentivize) and
has been true at an engineering level (i.e., people whose job it is to work on WebKit will naturally focus on that, since they have the time to do it and it matches Apple’s user-facing product ethos).
On saving newspapers: I don’t think newspapers need saving. Newspapers have great influence, and they will be funded for that. Let’s say, ads go to zero and all newspapers are bankrupt, except BBC, NHK, NPR, and Al Jazeera. Is that a problem? I don’t see a problem.
Local news matters a lot, and is rarely funded as much as it should be.
Yes, please give money to my employer: https://spotlightpa.org/donate/
Newspapers as they currently exist arguably don’t need saving, because they are mostly putting out flamebait, and recycling content from other sources.
Newspapers as they existed in 1990 or 2000 were useful – they funded investigative research when there was no alternative.
e.g. Journalists told the public about Watergate, and that takes funding and talented people - https://en.wikipedia.org/wiki/Bob_Woodward
There can definitely still be smaller local news media companies, but maybe the model needs to be rethought? https://www.theguardian.com/world/2021/may/03/local-media-can-survive-the-canadian-team-building-a-future-for-community-news