9 ms·

So, I'm pretty sure this is a correct history: 1. Google builds a new process architecture into Chrome as a product differentiator. (It was a major part of Chr

• jimray 14y ago
  Reading the utterly passive tone of the OP, with Webkit somehow "emerging" out of KHTML all on its own, nary a mention of Apple, makes it pretty obvious this move is mostly about politics.
• makomk 14y ago
  Apple's current commit approval policies appear to be fairly hostile to non-Apple developers and users of WebKit, and especially to non-Apple users of WebKit2. They now reserve the right to break builds on non-Apple platforms randomly and delay patches to fix them, amongst other things.
  • randomfool 14y ago
    Correct- Apple's announcement of the WebKit2 changes- https://lists.webkit.org/pipermail/webkit-dev/2013-January/thread.html#23255 https://lists.webkit.org/pipermail/webkit-dev/2013-January/t...
    • voltagex_ 14y ago
      This post put me completely on Google's side: https://lists.webkit.org/pipermail/webkit-dev/2013-January/023263.html https://lists.webkit.org/pipermail/webkit-dev/2013-January/0...
    • fpgeek 14y ago
      "Non Apple Mac ports, if broken by core functionality changes to WebKit2, are now responsible for fixing themselves." For a cross-platform project, this is a stunning policy change. I don't know what was the chicken and what was the egg, but it looks like this split was inevitable.
  • binarycrusader 14y ago
    Google is no different policy-wise for the chromium project. Neither of them are saints here.
• candybar 14y ago
  Isn't WebKit2 as much a fork of WebKit as Blink is? And it's not production ready?
  • macrael 14y ago
    The name doesn't make it clear, but I believe the answer is "no". My understanding is that WebKit2 is actually just a part of the whole WebKit platform. It's the process model, but all the other parts of webkit (the rendering and javascript, for instance) are the same as they were before WebKit2 was introduced.
• tolmasky 14y ago
  Maybe because anyone who has used Safari knows that WebKit2's multiprocess architecture is worse in practice. As a full-time Safari user I can tell you that things have gotten markedly worse since it went multiprocess. Pages go white momentarily (not crash) all the time, and on top of that they also crash all the time. Additionally, I believe that unlike Chrome, Safari has ONE separate process for all the tabs, and the render process (whereas Chrome tries one-process per tab -- way better in my opinion). Just out of curiosity, why do you think WebKit2 is the "standard"? Just because they named it "WebKit2"? Had Google named their multi-process version "WebKitB" would it be equally standard? It certainly came FIRST (I think it took WebKit2 years before it had an answer). I think this is a success of open source. Was the creation of WebKit a failure of Mozilla open source? Of course not. Sometimes you need to just actually test two ideas instead of discussing them. EDIT: Upon further inspection, I think current Safari isn't even using WebKit2. The wiki still says it should be considered a "technology demo", and exists largely in parallel to WebKit. So whatever multi-process thing its doing now I guess is separate? It's not clear to me. EDIT 2: I guess it is using WebKit2, so my criticisms stand.
  • kevincennis 14y ago
    Sincerely curious: why are you still a full-time Safari user in light of all those complaints?
    • tolmasky 14y ago
      Like most things, habit probably. Also, I used to work a lot on Safari/WebKit, so I guess sentimental value? That being said, I do like the way Safari "feels" a lot more than Chrome. I think Chrome is actually quite ugly, and bad from a UI perspective. For example, Safari's overflow tab menu is a much nicer solution than Chrome's insistence on shrinking tabs ever smaller until you can't tell them apart at all. Additionally Chrome is missing a killer feature I use all the time: zoom, and more specifically, double tap to zoom. I find it hard to read a lot of text on websites, and double tap, centered, zoom, is amazing. Its too bad everything else feels like its gotten way worse in the last 5 or so years.
• mikewest 14y ago
  It's a complex question. To be stunningly reductive: the architectures are simply quite different. We hook into the network stack in different places, we have different sandbox models and constraints (Win XP for instance), etc. Also note that the timing is fairly important: Chromium was quite far along with our implementation when WebKit2 was announced, and rather than iterating on the solution we'd proposed and run with, Apple created its own framework. That had advantages and disadvantages. More generally, I'd point to the Content layer as a better integration point: Opera, for instance, is building on top of our multi-process architecture successfully. Chromium Embedded Framework (https://code.google.com/p/chromiumembedded/ https://code.google.com/p/chromiumembedded/) is another example of how other projects can leverage the work we've done.
  • macrael 14y ago
    A stunningly reductive question deserves to be responded to in kind :) I don't know much of this history, but was integrating Chrome's processor model into WebKit feasible at the time that WebKit2 was built? What were the reasons for not doing so?
    • mikewest 14y ago
      Generally, I think WebKit2 and Chromium simply disagree about where to hook into the platform, and what the responsibilities of the embedder should be. The description at http://trac.webkit.org/wiki/WebKit2 http://trac.webkit.org/wiki/WebKit2 is written from Apple's point of view, but I think it's broadly fair. The position we're taking is that the Content layer (in Chromium) is the right place to hook into the system: http://www.chromium.org/developers/content-module http://www.chromium.org/developers/content-module That's where we've drawn the boundary between the embeddable bits and the Chrome and browser-specific bits. Regarding the history, I'd suggest adding some questions to the Moderator for tomorrow's video Q/A: http://google.com/moderator/#15/e=20ac1d&t=20ac1d.40&v=5 http://google.com/moderator/#15/e=20ac1d&t=20ac1d.40&#38... The folks answering questions there were around right at the beginning... I only hopped on board ~2.5 years ago. :)
  • othermaciej 14y ago
• mikewest 14y ago
  Also: these sorts of deep technical questions would be great for tomorrow's hangout: engineering leads Darin Fisher and Eric Seidel, product manager Alex Komoroske, and developer advocate Paul Irish will be more than happy to answer whatever you can throw at them. Add questions to the Moderator at: http://google.com/moderator/#15/e=20ac1d&t=20ac1d.40&.. http://google.com/moderator/#15/e=20ac1d&t=20ac1d.40&#38....
• dragonwriter 14y ago
  > Google says that the pain in maintaining their separate, non standard, process architecture is too much of a burden to continue to contribute into WebKit proper, so they must fork. Actually, they didn't say that the pain of maintaining their own work was too much of a burden, they said the pain of maintaining their model within the constraints and obligations WebKit had was too much of a burden (and, imposed too much of a burden on WebKit with regard to what WebKit wanted to do), so they decided fork so that WebKit can do what it wants to do without worrying about Chrome while Blink does what is needed for Chrome without worrying about WebKit. > Why can't Chrome implement WebKit 2? Implementing WebKit 2 wouldn't solve the problem going forward. Changes to WebKit to serve Chrome's needs would still have to meet all of the commitments WebKit has, and Chrome would still be placing demands on WebKit. > This seems like a failure of open source. Forking isn't failure. The purpose of open source isn't to create a monoculture, it is to enable groups to share effort when they have common goals, and to allow groups with divergent goals (including where those goals diverged after a period of shared work) to continue to benefit from the shared work without having to start back at square one. This is a success of open source.
  • malandrew 14y ago
    Just look up the history of browsers and you'll see that forking is rampant. Forking isn't failure. It's evolution. Once a project reaches a certain size, there exist enough developers in the community to be able to split into two or more self-sustaining communities that can take the project in two or more directions that are valid and serve different needs. It's called specialization.
• Osiris 14y ago
  Why is this a failure of open-source? Isn't it exactly what open-source is supposed to do, fork when a project doesn't meet your needs? I've always found it curious that open-source advocates rail on people that fork or split from projects instead of maintaining code that they believe isn't worth maintaining.
• podperson 14y ago
  If you see this other thread https://news.ycombinator.com/item?id=5490242 https://news.ycombinator.com/item?id=5490242 the history is slightly different. 1. Google builds new process architecture into Chromium. 1a. Apple asks for it to be contributed back to Webkit. 1b. Google either says "no" or doesn't care but expects Apple to do all the work (note that if Google doesn't do it then this would mean the same functionality being implemented at two different points in the code tree -- webkit and chromium) 2. Apple decides to build its own multiprocess support into Webkit2. Seems to me that the forking is probably overall a Good Thing, no-one is angry at anybody else, it's just a very important codebase which now has way too many stakeholders.