[besson3c]

I found this John Siracusa article, particularly the graphs interesting:

Hypercritical: Code Hard or Go Home

WebKit: Reviewed Commits



WebKit: Active Authors




I've been a little preoccupied lately and haven't been tracking the news, so I was a little surprised that Blink even existed. It's kind of a drag that this fork exists now. While Apple's involvement seems steady but overshadowed by what Google has done, if Siracusa's theory is right that this could have been avoided by one party adopting the other's multiprocess model, it's a shame that Apple didn't adopt Google's model as a compromise given Google's intense involvement. Surely Safari's progress will slow with this fork, unless Apple really wants to spend the time syncing with Blink.

[OreoCookie]

Actually, besson, the Webkit team immediately asked Google to commit its process model to Webkit, but it refused. Instead, they kept it as part of the browser. For Google, it doesn't matter much where this part of the code resides, but for Apple it does, because it wants that all apps which use web views benefit from having the extra safety and extra performance.

But overall, you're right, Apple will have to beef up its efforts.

[OreoCookie]

Actually, besson, the Webkit team immediately asked Google to commit its process model to Webkit, but it refused. Instead, they kept it as part of the browser. For Google, it doesn't matter much where this part of the code resides, but for Apple it does, because it wants that all apps which use web views benefit from having the extra safety and extra performance.

But overall, you're right, Apple will have to beef up its efforts.

[besson3c]

That doesn't make sense though, OreoCookie... You can build Chrome yourself for OS X:

Chromium - The Chromium Projects

Couldn't Apple just check out this code and build this model into Cocoa and/or the iOS SDK so that apps can do the same thing?

[mindwaves]

Those charts are certainly troubling for Apple. It appears that Webkit development will be slowing down or at least not growing at the torrid pace as it once was.

[besson3c]

There is nothing wrong with open source being a competition of ideas and different forks existing when there is a difference of opinion I guess, but after this has played out perhaps it is silly to clutch on to these old ideas at the expense of users and progress?

Even if you think that Apple's model is better, it is clear that the big surging momentum behind the browser is with what Google is doing, so maybe some concessions should be made? New and existing developers not invested in this dispute are probably going to gravitate towards whatever has the most momentum, which appears to be Google now.

Besides, as far as this idea of Google or Apple not doing what will support the platform as a whole, I thought I read that Mobile Safari has an advantage over Chrome on iOS as far as performance goes because of Apple not exposing certain things to the API or something?

I obviously don't know who the bad guy and who the good guy is really, but I hope that both companies will rise above this. Right now, Chrome is kicking ass, so it seems like it is more Apple mired in doing things their way or the highway:

Browser Statistics

[OreoCookie]

Originally Posted by besson3c 

That doesn't make sense though, OreoCookie... You can build Chrome yourself for OS X:

What do you mean, it doesn't make sense? That's simply what has happened and what Syracusa also writes (but I've read the exact same claims elsewhere before): after Chrome appeared, the Webkit people asked Google to integrate the code pertaining to the split process to Webkit so that every Webkit project (not just Apple's Safari) can benefit from it. Google declined.

So the problem is not the availability of the code (just download the source of Chromium), but whether they could actually make use of it. If Apple had integrated GPLed code/open source code into closed APIs, Apple could have gotten into trouble (for good reason), i. e. they would have had to write a copy of Chrome's process model from scratch.

As I see it Apple (as the shepard of Webkit) had three choices:
(1) Integrate Google's process model into a new fork of Webkit (because Google presumably wants to keep the code as it is).
(2) Implement another split process model into Webkit.
(3) Apple implements the process model not into Webkit, but into another part of their APIs.

Clearly, the best option would have been if Google committed this part of the code to the Webkit project, but for some reason or another, they chose not to do it.

As to why Apple chose to make Webkit2 (i. e. pick option (2)), in my eyes, the advantages are obvious: they just have to add (bug and security) fixes to the Webkit project rather than to each of their APIs separately. This is in addition to the GPL/open source license problem.

From that perspective, it's clear to me why Apple decided to create Webkit2.

[OreoCookie]

Originally Posted by besson3c 

There is nothing wrong with open source being a competition of ideas and different forks existing when there is a difference of opinion I guess, but after this has played out perhaps it is silly to clutch on to these old ideas at the expense of users and progress?

So far, nothing has really happened that is to the detriment of users. Chrome and Safari have (to my knowledge) always used different JavaScript engines, and that led to an arms race in this area. The outcome was arguably beneficial for the user: he got better performance from either browser over time. Both, Chrome and Safari have also used different process models before the fork. So to me, the fork is just a smooth continuation of this competition.

Originally Posted by besson3c 

Even if you think that Apple's model is better …

Nobody claimed Apple's design choice is better, in my experience at least, Google's is better (if the renderer crashes, Chrome has to re-render only one tab as opposed to all).

Originally Posted by besson3c 

… I thought I read that Mobile Safari has an advantage over Chrome on iOS as far as performance goes because of Apple not exposing certain things to the API or something?

Apple's iOS browser uses a different, faster JavaScript engine called Nitro which uses JIT (just in time compilation) while web views use the older JavaScript engine. This is for security reasons.

Originally Posted by besson3c 

I obviously don't know who the bad guy and who the good guy is really, but I hope that both companies will rise above this.

I don't get that perspective: Google forked Webkit, because they think it is in their own best interests. As far as I have heard, Apple has done nothing to push Google out. Since some of the advantages are symmetrical (also Webkit can now remove everything pertaining to Chrome/Chromium), we, the users, get more diversity in the browser space. That is a good thing.™

Originally Posted by besson3c 

Right now, Chrome is kicking ass, so it seems like it is more Apple mired in doing things their way or the highway:

If you look at mobile browser statistics, Safari has an edge. This is where Apple's strong suit is.

(Personally, I use both, Safari and Chrome. I use Chrome for when I need flash (e. g. to watch videos on Youtube) and Safari for almost anything else.)

[besson3c]

Originally Posted by OreoCookie 

What do you mean, it doesn't make sense? That's simply what has happened and what Syracusa also writes (but I've read the exact same claims elsewhere before): after Chrome appeared, the Webkit people asked Google to integrate the code pertaining to the split process to Webkit so that every Webkit project (not just Apple's Safari) can benefit from it. Google declined.

So the problem is not the availability of the code (just download the source of Chromium), but whether they could actually make use of it. If Apple had integrated GPLed code/open source code into closed APIs, Apple could have gotten into trouble (for good reason), i. e. they would have had to write a copy of Chrome's process model from scratch.

As I see it Apple (as the shepard of Webkit) had three choices:
(1) Integrate Google's process model into a new fork of Webkit (because Google presumably wants to keep the code as it is).
(2) Implement another split process model into Webkit.
(3) Apple implements the process model not into Webkit, but into another part of their APIs.

Clearly, the best option would have been if Google committed this part of the code to the Webkit project, but for some reason or another, they chose not to do it.

As to why Apple chose to make Webkit2 (i. e. pick option (2)), in my eyes, the advantages are obvious: they just have to add (bug and security) fixes to the Webkit project rather than to each of their APIs separately. This is in addition to the GPL/open source license problem.

From that perspective, it's clear to me why Apple decided to create Webkit2.

But why would it be on Google to commit this code to Webkit? For starters, they probably don't have the authority to actually merge stuff, right? Apple could just integrate Google's code on their own, they don't need Google's permission to do that.

[besson3c]

Originally Posted by OreoCookie 

If you look at mobile browser statistics, Safari has an edge. This is where Apple's strong suit is.

(Personally, I use both, Safari and Chrome. I use Chrome for when I need flash (e. g. to watch videos on Youtube) and Safari for almost anything else.)

Yeah, but Safari will always have an edge so long as there is no way to change your default iOS browser. The browser is pretty well masked by all apps that have some sort of browsing component that is farmed out to Safari/Webkit. It seems vaguely similar to MS and IE in the olden days?

[OreoCookie]

Originally Posted by besson3c 

But why would it be on Google to commit this code to Webkit?

Because they have always been one of the most active two developers (as aggregate). Since they wrote this code, it's clear that they are the most qualified.

Originally Posted by besson3c 

For starters, they probably don't have the authority to actually merge stuff, right?

Google was asked to commit the code, so it was not a problem of authority.

Originally Posted by besson3c 

Apple could just integrate Google's code on their own, they don't need Google's permission to do that.

Integrate where? In Webkit itself? Yes, I reckon, they could have, but on the other hand, that may have proven as complicate an undertaking as writing Webkit2 (because the other Webkit engineers would have to understand Google's code, come up with a plan to integrate it into the Webkit code and execute it). Integration into Apple's APIs would probably not be possible since Cocoa is closed-source.

Originally Posted by besson3c 

Yeah, but Safari will always have an edge so long as there is no way to change your default iOS browser. The browser is pretty well masked by all apps that have some sort of browsing component that is farmed out to Safari/Webkit. It seems vaguely similar to MS and IE in the olden days?

In principle, I agree that Apple should allow people to choose their own browsers. However, I don't think it has had the same detrimental effect as IE has had on the web: Microsoft has stymied the wide-spread adoption of css and the like, not to speak of html5. Webkit and blink are the de facto default implementations of new web standards, so as long as that stays that way, I don't worry too much.