4 ms·

I can't help but think that forking WebKit is a business based decision since Apple controls WebKit. This blog post doesn't make an engineering based argument*

by ebbv 14y ago

I can't help but think that forking WebKit is a business based decision since Apple controls WebKit. This blog post doesn't make an engineering based argument* so I'm left with the business ones. Which sucks. * - Just vague "we need to innovate faster" boilerplate. Which is what business people say when there's not a solid engineering based reason. EDIT: At the bottom of the project page are some engineering reasons: http://www.chromium.org/blink http://www.chromium.org/blink Each person can judge whether it's worth forking or not.

mankyd 14y ago
a) Why does that suck? b) Although it is a little hand wavey, they do make an engineering argument: "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."
- dragonwriter 14y ago
  > Although it is a little hand wavey, they do make an engineering argument: Immediately being able to eliminate and not worry about maintaining 7,000 files comprising 4.5 million LOC seems to be a pretty concrete benefit, rather than a hand-wavey one.
mikewest 14y ago
http://www.chromium.org/blink/developer-faq http://www.chromium.org/blink/developer-faq has a bit more information, as does http://www.chromium.org/blink#architectural-changes http://www.chromium.org/blink#architectural-changes. There really are good architectural reasons to go in this direction.
simonster 14y ago
Apple doesn't actually control WebKit. A decent proportion of reviewers at http://trac.webkit.org/wiki/WebKit%20Team http://trac.webkit.org/wiki/WebKit%20Team are Google employees. The engineering argument is that the differences between Chromium's multi-process model and WebKit2 are big enough that, in order for both projects to move forward, Google needs to fork WebKit. I'm not competent to judge whether this is actually true.
- mikewest 14y ago
  http://trac.webkit.org/wiki/WebKit2 http://trac.webkit.org/wiki/WebKit2 outlines the technical differences between the architectures pretty well. Suffice it to say, the model runs deep, and has real impact on the way things like WebCore are put together.
- fpgeek 14y ago
  Speaking of reviewers, it looked like there were (maybe) a handful of WebKit reviewers that meet the following criteria: 1. Not affiliated with Apple or Google. 2. Not specifically associated with a port in terms of their review areas. To me, that says a lot about how WebKit governance works in practice.
deleted 14y ago
[deleted]
yanw 14y ago
Chromium uses a different multi-process architecture ... and supporting multiple architectures over the years has led to increasing complexity ... we anticipate that we’ll be able to remove 7 build systems and delete more than 7,000 files—comprising more than 4.5 million lines How is that not engineering based?
- nnethercote 14y ago
  Last time I measured (late 2012) the entire mozilla-central repository was 4.488 million lines of code. So I don't believe that by simply streamlining things they'll be able to remove anything like 4.5 million lines. Perhaps an extra zero got inserted somewhere.
  - signed0 14y ago
    4.5 million lines spread over 7,000 files is only ~642 lines per file, so I doubt there is an extra zero. Perhaps they included whitespace and comments in their count.
  - simonster 14y ago
    Not sure why this is got downvoted given that it appears to be correct (https://github.com/mozilla/mozilla-central/graphs/code-frequency https://github.com/mozilla/mozilla-central/graphs/code-frequ...)
  - dragonwriter 14y ago
    > Last time I measured (late 2012) the entire mozilla-central repository was 4.488 million lines of code. Mozilla isn't WebKit. > I don't believe that by simply streamlining things they'll be able to remove anything like 4.5 million lines. I suppose you could compare WebKit repos against Blink repos once the latter is live to see exactly what is cut, but I'm going to say the people working on the code that are the source of the count know how many LOC are involved, and that there direct count is more reliable than a third-party estimate based on a different browser's repo.
    - nnethercote 14y ago
drivebyacct2 14y ago
Of course the blog post doesn't go into technical detail. But if you would explore just a single link deeper you would see a pretty good explanation of the changes they're making. It's pretty obvious why they're doing it. It improves and greatly eases the amount of effort required to port/utilize Chromium/Blink not to mention the other benefits from the architecture that they indicate will enable better multithreading.
deleted 14y ago
[deleted]
mtgx 14y ago
How does Apple control webkit? Doesn't Google have like 50% of the commits to webkit?
alxndr 14y ago
Ars has slightly more... >Longer term, we can expect to see Blink evolve in a different direction from WebKit. Upson and Komoroske told us that there were all manner of ideas that may or may not pan out that Google would like to try. The company says that forking WebKit will give it the flexibility to do so. http://arstechnica.com/information-technology/2013/04/google-going-its-own-way-forking-webkit-rendering-engine/ http://arstechnica.com/information-technology/2013/04/google...
tolmasky 14y ago
If you look at the commits, there's a fair argument that Google "controls" WebKit. You could almost say Apple got KHTML'ed ;) I believe this is an honest move. This is what happens with software. Goals change, old code and design no longer makes sense, you refactor or rewrite. The architecture of WebKit was created to address goals that are a decade old now. The multi-process nature of Chrome alone, an amazing achievement and really quite elegant if you've looked at the way they bolted it on, was bolted on all the same. V8 without a doubt re-invigorated JavaScript. When V8 was announced there was a lot of "do we really need another JS engine" arguments. You could argue that other engines were getting fast as well, but v8 got people really thinking about JavaScript outside the browser. I am excited to see what new insights this new rendering engine brings -- and what unexpected positive consequences it generates.
- MatthewPhillips 14y ago
  If you want to really put a tinfoil cap on, you could say that by Google contributing to WebKit they are giving Apple a lot of free code, allowing them to devote fewer resources to their browser. Once Blink diverges father from WebKit it won't be practical for WebKit to merge in changes from there. One has to wonder if Google will be recruiting other WebKit contributors (RIM, Intel, Nokia, etc) to move over to Blink. This would put Apple in a tough spot.
  - mikewest 14y ago
    Blink remains very much open source: the repository should be visible in a minute or three. We're going to be even more transparent than we currently are, actually, about how things get added to the platform http://www.chromium.org/blink#new-features http://www.chromium.org/blink#new-features. I'm pretty excited about how that's going to play out with regard to sharing ideas and implementations.
    - MatthewPhillips 14y ago
      Of course, I wasn't claiming otherwise, but over time porting code to WebKit from Blink will become more trouble than it's worth. They can still learn from it, but you can hardly deny that this move is going to cause WebKit some pain to fill in the tremendous amount of work you guys were doing (the part about this being the reason for the move was, of course, completely a joke.
lukifer 14y ago
If there is an engineering argument, I'm guessing it's to do with multi-threaded DOM+JS, given the mention of multi-process architecture. Also, how much does Apple really control WebKit? At a glance, it looks to me like FOSS. (Apple might be the maintainer, but it seems trivial to fork it in a different direction.) Perhaps this is a more nebulous "thought leadership" kind of thing?
alexchamberlain 14y ago
It looks like a lot of C++ projects atm; we need to throw out the chronies and fix their spaghetti code.

by ebbv 14y ago

mankyd 14y ago

a) Why does that suck? b) Although it is a little hand wavey, they do make an engineering argument: "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."

dragonwriter 14y ago
> Although it is a little hand wavey, they do make an engineering argument: Immediately being able to eliminate and not worry about maintaining 7,000 files comprising 4.5 million LOC seems to be a pretty concrete benefit, rather than a hand-wavey one.

mikewest 14y ago

http://www.chromium.org/blink/developer-faq http://www.chromium.org/blink/developer-faq has a bit more information, as does http://www.chromium.org/blink#architectural-changes http://www.chromium.org/blink#architectural-changes. There really are good architectural reasons to go in this direction.

simonster 14y ago

Apple doesn't actually control WebKit. A decent proportion of reviewers at http://trac.webkit.org/wiki/WebKit%20Team http://trac.webkit.org/wiki/WebKit%20Team are Google employees. The engineering argument is that the differences between Chromium's multi-process model and WebKit2 are big enough that, in order for both projects to move forward, Google needs to fork WebKit. I'm not competent to judge whether this is actually true.

mikewest 14y ago
http://trac.webkit.org/wiki/WebKit2 http://trac.webkit.org/wiki/WebKit2 outlines the technical differences between the architectures pretty well. Suffice it to say, the model runs deep, and has real impact on the way things like WebCore are put together.
fpgeek 14y ago
Speaking of reviewers, it looked like there were (maybe) a handful of WebKit reviewers that meet the following criteria: 1. Not affiliated with Apple or Google. 2. Not specifically associated with a port in terms of their review areas. To me, that says a lot about how WebKit governance works in practice.

deleted 14y ago

[deleted]

yanw 14y ago

Chromium uses a different multi-process architecture ... and supporting multiple architectures over the years has led to increasing complexity ... we anticipate that we’ll be able to remove 7 build systems and delete more than 7,000 files—comprising more than 4.5 million lines How is that not engineering based?

nnethercote 14y ago
Last time I measured (late 2012) the entire mozilla-central repository was 4.488 million lines of code. So I don't believe that by simply streamlining things they'll be able to remove anything like 4.5 million lines. Perhaps an extra zero got inserted somewhere.
- signed0 14y ago
  4.5 million lines spread over 7,000 files is only ~642 lines per file, so I doubt there is an extra zero. Perhaps they included whitespace and comments in their count.
- simonster 14y ago
  Not sure why this is got downvoted given that it appears to be correct (https://github.com/mozilla/mozilla-central/graphs/code-frequency https://github.com/mozilla/mozilla-central/graphs/code-frequ...)
- dragonwriter 14y ago
  > Last time I measured (late 2012) the entire mozilla-central repository was 4.488 million lines of code. Mozilla isn't WebKit. > I don't believe that by simply streamlining things they'll be able to remove anything like 4.5 million lines. I suppose you could compare WebKit repos against Blink repos once the latter is live to see exactly what is cut, but I'm going to say the people working on the code that are the source of the count know how many LOC are involved, and that there direct count is more reliable than a third-party estimate based on a different browser's repo.
  - nnethercote 14y ago

drivebyacct2 14y ago

Of course the blog post doesn't go into technical detail. But if you would explore just a single link deeper you would see a pretty good explanation of the changes they're making. It's pretty obvious why they're doing it. It improves and greatly eases the amount of effort required to port/utilize Chromium/Blink not to mention the other benefits from the architecture that they indicate will enable better multithreading.

deleted 14y ago

[deleted]

mtgx 14y ago

How does Apple control webkit? Doesn't Google have like 50% of the commits to webkit?

alxndr 14y ago

Ars has slightly more... >Longer term, we can expect to see Blink evolve in a different direction from WebKit. Upson and Komoroske told us that there were all manner of ideas that may or may not pan out that Google would like to try. The company says that forking WebKit will give it the flexibility to do so. http://arstechnica.com/information-technology/2013/04/google-going-its-own-way-forking-webkit-rendering-engine/ http://arstechnica.com/information-technology/2013/04/google...

tolmasky 14y ago

If you look at the commits, there's a fair argument that Google "controls" WebKit. You could almost say Apple got KHTML'ed ;) I believe this is an honest move. This is what happens with software. Goals change, old code and design no longer makes sense, you refactor or rewrite. The architecture of WebKit was created to address goals that are a decade old now. The multi-process nature of Chrome alone, an amazing achievement and really quite elegant if you've looked at the way they bolted it on, was bolted on all the same. V8 without a doubt re-invigorated JavaScript. When V8 was announced there was a lot of "do we really need another JS engine" arguments. You could argue that other engines were getting fast as well, but v8 got people really thinking about JavaScript outside the browser. I am excited to see what new insights this new rendering engine brings -- and what unexpected positive consequences it generates.

MatthewPhillips 14y ago
If you want to really put a tinfoil cap on, you could say that by Google contributing to WebKit they are giving Apple a lot of free code, allowing them to devote fewer resources to their browser. Once Blink diverges father from WebKit it won't be practical for WebKit to merge in changes from there. One has to wonder if Google will be recruiting other WebKit contributors (RIM, Intel, Nokia, etc) to move over to Blink. This would put Apple in a tough spot.
- mikewest 14y ago
  Blink remains very much open source: the repository should be visible in a minute or three. We're going to be even more transparent than we currently are, actually, about how things get added to the platform http://www.chromium.org/blink#new-features http://www.chromium.org/blink#new-features. I'm pretty excited about how that's going to play out with regard to sharing ideas and implementations.
  - MatthewPhillips 14y ago
    Of course, I wasn't claiming otherwise, but over time porting code to WebKit from Blink will become more trouble than it's worth. They can still learn from it, but you can hardly deny that this move is going to cause WebKit some pain to fill in the tremendous amount of work you guys were doing (the part about this being the reason for the move was, of course, completely a joke.

lukifer 14y ago

If there is an engineering argument, I'm guessing it's to do with multi-threaded DOM+JS, given the mention of multi-process architecture. Also, how much does Apple really control WebKit? At a glance, it looks to me like FOSS. (Apple might be the maintainer, but it seems trivial to fork it in a different direction.) Perhaps this is a more nebulous "thought leadership" kind of thing?

alexchamberlain 14y ago

It looks like a lot of C++ projects atm; we need to throw out the chronies and fix their spaghetti code.