Hacker News Reader

Comment by macrael | Hacker News Reader

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 Chrome's initial marketing)

2. WebKit 2 is built (mostly by Apple?) to bake the same type of architecture straight into the core framework -- anyone using WebKit can use it and get the same security/stability benefits.[1]

3. 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.

Why can't Chrome implement WebKit 2? Are there major advantages to Chrome's process model that are not present in WebKit 2? Is there a reason why WebKit 2 cannot be patched to provide those advantages?

This seems like a failure of open source.

[1]: see the first paragraph on http://trac.webkit.org/wiki/WebKit2

View on HN

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.

Sincerely curious: why are you still a full-time Safari user in light of all those complaints?

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.

Just in that specific, or also zoom in general? Chrome has had zoom for as long as I can remember, and that's years.

Double click to zoom seems like something that shouldn't be too hard to do in an extension.

I meant "smooth zoom" I guess? I can pinch in from anywhere on the page and center in on any particular item at any particular zoom level. Unless I've missed something, Chrome seems to have "integral" stepwise zooming, which also always zooms from the center of the page (vs where my mouse cursor is). It ends up feeling like Safari's old zoom which would just make the individual items bigger (as opposed to actually scaling the page), but I'm pretty sure Chrome is indeed scaling the page, just doing it in a way that I find frustrating and less useful.

Another example, I'm watching an embedded YouTube video which thus annoyingly doesn't allow fullscreen, so I double tap it, and it fills the browser window, and it seems to be smart enough to render at correct resolution at that scale (since it still allows you to choose a higher resolution even though it won't full screen).

To do similar feats with Chrome I have to manually jigger things around.

The tab behavior in chrome is what does it for me too. In fact, you can have so many tabs that you can no longer open the last tabs (the tabs extend past the little full screen or switch user icon).

I also think Safari has a much better solution for handling bookmarking when you have multiple tabs. Solve these two issues and I'd switch to Chrome in a second.

Check out the Chrome Web Store. There are several tab management extensions. One's a quick tab list with a search box.

I actually prefer Firefox's approach to multiple tabs: the tab bar scrolls (you can use the scroll wheel). That's about the only thing I like in Firefox anymore though… Been using Chrome because of its multi-user support (tied in with Google accounts) but Safari is soooo much better than Chrome in terms of UI and UX… Latest Chrome betas, with the full integration of the address bar as a full-blown "Google box" (e.g. you start typing, it loads Google Instant Search without the page's classic search box)…

I digress… :)

FWIW activating "Stacked tabs" in Chrome://flags resolves this by switching to the tablet implementation which doesn't shrink the tabs.

I went and looked at the "Stacked Tabs" flag and it appears to be Windows only.

From Chrome://Flags-

Stacked Tabs Windows Tabs never shrink, instead they stack on top of each other when there is not enough space. Sorry, this experiment is not available on your platform.

I also use Safari pretty much exclusively because I like the UI over Chrome, but the one feature I love about Chrome is its tab closing/resizing. When a tab is closed, the remaining tabs resize and shift appropriately so that your mouse is over the next tab's close button. (See http://www.theinvisibl.com/2009/12/08/chrometabs for a nice explanation.)

Try AutoZoom extension for Chrome which has different zoom levels for every website

https://chrome.google.com/webstore/detail/autozoom/ocdkpkoao...

I can confirm what tolmasky said about WebKit2, yet I'm also a Safari user. The interface just feels better for me, and Chrome has actually been getting worse in this respect. When I stopped using it, a few versions ago, it had started feeling more and more like a Chrome OS VM than like a browser on my Mac. I doubt they've changed course since then.

Safari is the only browser that has decent scrolling performance on a Retina MacBook. All the other browsers stutter really badly as soon as the page has any complexity with fixed elements (Facebook is a big one)

Yeah, that's certainly true. Pretty frustrating to have spent $2,500 or whatever it was on my retina MBP and I can't smoothly scroll websites with more than like 500 DOM nodes in Chrome.

That's a case where Apple has to optimize the heck out of Safari until it is workable on that particular new machine, otherwise it would get terrible reviews and hurt the overall brand.

Chrome doesn't have the same incentives to get that particular machine working well, especially since the next revision of the Retina Macbook probably won't even need special handling since it will surely have a more powerful GPU. They can just wait it out, similar to what happened with the iPad 3 vs iPad 4, where people had to optimize for the iPad 3 and then those optimizations were unneeded on the iPad 4.

> That's a case where Apple has to optimize the heck out of Safari until it is workable

Actually, they "merely" leverage their platform by using CoreAnimation, making it GPU accelerated (and enabling pinch-to-zoom), while Chrome scrolling hits the CPU really hard.

So true, this is actually one of the things that almost convinced me to switch to Safari. I'd miss the Developer Tools though..

But the developer tools are in Safari.

Not visible by default, hence may people miss them: Developer menu entry needs to be enabled in Preferences.

The latest dev and beta channel significantly outperforms Safari scrolling IMHO.

Interesting, just tried it out. The framerate is smooth, but there's some lag in starting to scroll that makes it feel like the page has inertia.

Interface is nicer and more native.

Chrome is even starting to drop native dialog boxes

No way to disable tabs (in particular the default "open in new tab" behavior) in Chrome.

Safari is using WebKit2, and has been for some time. The "preproduction prototype" bit of that Wiki is a bit out of date.

Wikipedia says WebKit2 has been part of Safari since Safari 5.1 which I believe was released with Lion, or so. So it absolutely is in production. The major difference here being that WebKit2 is part of the webkit project, so as the rendering engine (which sits atop both webkit1 and webkit2) is improved by all the various parties involved in WebKit's development, it gets better for everyone. Google's fork now means that changes to the rendering engine they make to Blink will no longer have any effect on the WebKit project, which does seem to be a major difference.

I don't know all the history here, but my understanding is that Chrome's engine was never offered in that same sort of way. It was just part of the chromium project, apparently a part that increased the difficulty of integrating with WebKit, not an api intended to be taken by others and integrated into their browser.

That's in theory. In practice nobody bothered besides Apple.

The recently released Epiphany 3.8 (part of GNOME 3.8) uses WebKit2, so there are others who care.

> The major difference here being that WebKit2 is part of the webkit project, so as the rendering engine (which sits atop both webkit1 and webkit2) is improved by all the various parties involved in WebKit's development, it gets better for everyone. Google's fork now means that changes to the rendering engine they make to Blink will no longer have any effect on the WebKit project, which does seem to be a major difference.

It also means that the work they do on the rendering engine for Blink won't be constrained by the constraints imposed by support the various WebKit implementations.

Well that's ultimately kind of sad, right? It's certainly not the argument that was made in this blog post, but it certainly is a believable one. WebKit is a giant open source project that is relied upon by many many different companies and Google contributed a lot to that. Now they are gone and all those companies are left continuing to build WebKit with a goal of interoperability between the myriad different clients while Google takes their ball and goes home and only works on their own platforms.

> Well that's ultimately kind of sad, right?

Forking happens all the time and is natural: good since you can go your own way, bad since you no longer contribute to the mainline. Its like speciation in that way, where some group of animals splits off and stops mating with (and hence evolving with) another group of animals.

> Well that's ultimately kind of sad, right?

Why is it sad for Chrome development not to be held back by WebKit when each project prefers a different approach?

Personally, I think its win-win: Chrome and WebKit, which have conflicting approaches to a variety of different issues, are free to take their own approaches and prove them. This is a good thing for progress.

> It's certainly not the argument that was made in this blog post, but it certainly is a believable one.

Its actually exactly what the post says when it says "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. This has slowed down the collective pace of innovation - so today, we are introducing Blink, a new open source rendering engine based on WebKit."

>WebKit is a giant open source project that is relied upon by many many different companies...Google takes their ball and goes home and only works on their own platforms.

Blink is open source, it's simply a fork of WebKit. That's why Opera is intending to use it instead of WebKit2. It's like Google wanted to take their ball to another court and still let everyone play.

You're assuming it's the exact same multi-process architecture. Is it, really?

You're right that Chrome's multiprocess architecture is more mature than the WebKit2 design. I wish we hadn't ended up in a position where we felt we had to make our own. But stay tuned - we have some great stuff coming up.

all of this all the more hilarious because the current version of Safari is functionally broken to the point where it is unusable

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/) is another example of how other projects can leverage the work we've done.

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?

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 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 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&... The folks answering questions there were around right at the beginning... I only hopped on board ~2.5 years ago. :)

As long as we are recapitulating history - the main reason we built a new multiprocess architecture is that Chromium's multiprocess support was never contributed to the WebKit project. It has always lived in the separate Chromium tree, making it pretty hard to use for non-Chrome purposes.

Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute their multiprocess support back to WebKit, so that we could build on it. They said no.

At that point, our choices were to do a hostile fork of Chromium into the WebKit tree, write our own process model, or live with being single-process forever. (At the time, there wasn't really an API-stable layer of the Chromium stack that packaged the process support.)

Writing our own seemed like the least bad approach.

If Google had upstreamed their multiprocess support, we almost surely would have built on it. And history might have turned out differently.

I'd also add that I disagree with Mike about the architectures being really different. In fact, they are quite similar in broad strokes, but with many differences in details (and with the significant difference that the Chromium model isn't in WebKit per se).

I'm no stranger to open source, but can you please explain what a "hostile fork" is? Especially in this context, it just seems like diction for the sole purpose of making Google look like they were 'in the wrong' in that situation.

A hostile fork is one done unilaterally, generally without consultation or the blessing of the main project. It generally causes acrimony and community fragmentation, and usually no code changes are shared between the forks after the split.

Compare to forking to solve a very specific or specialized problem that doesn't make sense to merge upstream, like a set of changes that only apply to a very narrow audience or esoteric use-case. In such a case, it's common that changes that do affect the main project are still merged upstream and special care is done to make sure the forks don't diverge too much.

If we took Chromium's multiprocess code and put it in the WebKit tree after the Chrome folks specifically said they did not want to do that, that would have been super rude. Don't you think? That's why I say "hostile fork". I am judging our own path not chosen, and do not mean to cast aspersions on Google's actions.

To be clear, I do not consider Blink to be a hostile fork. I wish the Blink developers good luck & godspeed.

>that would have been super rude. Don't you think?

As long as the license allows it and the maintainer is not burdened in any way, no?

Just because you can do something, doesn't mean you should. To do an action without considering the consequences is foolhardy.

You could see the history between xMule and aMule for a hostile fork. Or the history between ffmpeg and libav, where some contributors where denied access to the repo.

I don't understand this claim. WebKit2 was landed with effectively no notice and no attempts at collaboration. I saw repeated attempts to work on a shared architecture in WebKit2, but none were reciprocated. http://goo.gl/KH1Sr Eventually all non-Apple contributors were cut off entirely from WebKit2 as a matter of policy. http://goo.gl/iTDAR

We talked privately with particular Chrome folks before we started (as described upthread), in the middle, and shortly before landing to mention that we were landing soon.

I don't know if the contents of these conversations were ever shared with the whole Chrome team as som Chrome people seemed super surprised at our announcement.

It is true that when we announced our effort, it came with a rough working prototype and not just an empty directory. Basically because we did not know if we could do it until we tried.

BTW I am not trying to pick a fight here. I think mikewest's comment gave the impression that Apple built a multiprocess architecture out of cussedness or NIH. But that's not how it was.

Google had the right to make their choices and we had the right to make ours.

>We talked privately with particular Chrome folks before we started (as described upthread), in the middle, and shortly before landing to mention that we were landing soon.

Yes, I'm aware of that, but the work had been underway for a long time and was about to be dropped by the time there was a real heads up. So the core of the architecture was already being frozen from a larger perspective.

>BTW I am not trying to pick a fight here. I think mikewest's comment gave the impression that Apple built a multiprocess architecture out of cussedness or NIH. But that's not how it was.

I don't interpret Mike's comments that way. Chromium's architecture was public and available, but we assumed it wasn't used because it didn't fit the needs of WebKit2. There's no malice in that. We designed Chromium from the beginning for SFI (as Adam tried to convey), and that incurs quite a bit of complexity. I'm comfortable that the divergence was simply a result of different needs. I just don't see how it could be presented as something malicious or anti-collaborative.

>> We talked privately with particular Chrome folks before we started (as described upthread), in the middle, and shortly before landing to mention that we were landing soon. > Yes, I'm aware of that, but the work had been underway for a long time and was about to be dropped by the time there was a real heads up. So the core of the architecture was already being frozen from a larger perspective.

Are you aware of the earlier conversation that occurred before we wrote any lines of code or even had a name? Where we talked about the possibility of just using Chromium's model if Google was willing to contribute it back? I have mentioned it twice - maybe you overlooked those parts of my remarks.

> Chromium's architecture was public and available, but we assumed it wasn't used because it didn't fit the needs of WebKit2. There's no malice in that. We designed Chromium from the beginning for SFI (as Adam tried to convey), and that incurs quite a bit of complexity.

It had nothing to do with SFI (which wasn't brought up at the time) or complexity. It was for the reasons I stated upthread.

>Are you aware of the earlier conversation that occurred before we wrote any lines of code or even had a name? Where we talked about the possibility of just using Chromium's model if Google was willing to contribute it back? I have mentioned it twice - maybe you overlooked those parts of my remarks.

The Chromium code is all in a public repository and was already integrated into WebKit via Chrome's platform layer. Members of the Chrome team were also interested in helping better incorporate Chrome's model into WebKit. So, I must be misunderstanding you, because it seems like you're suggesting that you expected Chrome engineers to simply do all the work.

>It had nothing to do with SFI (which wasn't brought up at the time) or complexity. It was for the reasons I stated upthread.

I still don't get what that reason is supposed to be. Regardless, the resulting WebKit2 design was clearly incompatible with the existing Chrome architecture. And the fact that they were continuing to diverge and place a burden on both projects was a clear problem. This was raised repeatedly, but never seemed to receive any serious consideration.

> So, I must be misunderstanding you, because it seems like you're suggesting that > you expected Chrome engineers to simply do all the work.

Nah, you're not misunderstanding, Apple/WebKit has a track record of doing this.

I expect that's not the case, and I'm just missing the point othermaciej is trying to make.

Well it doesn't really matter if you expect it or not, the fact still stands that they do.

Do you actually know what you pretend to know, or are you holding a grudge against Apple for an old transgression with KHTML that they've since done did a great deal of work to put right?

The way I read it, they didn't want to integrate until they got an official 'yes' (quote: 'our choices were to do a hostile fork of Chromium into the WebKit tree').

My interest in this thread was only to report on some history that I knew about personally, to correct what I thought was an incomplete version of events. I think a bunch of people found that information useful and interesting.

I regret that this thread has turned into such a back-and-forth. It's not my goal to detract from the Blink announcement. I feel like it would be rude to leave you hanging on mid-thread. However, I feel like: (a) You are trying to argue with my version of specific events where I was present in person and you (as far as I recall) were not. (b) You are trying to argue with my stated motivations for decisions that I was part of and you were not. (c) You seem to want to assign blame.

Maybe my impressions are wrong. But given this, I find it hard to reply in a way that would be constructive and would not further escalate. I hope you will forgive me for not debating about it further.

A request for clarification on why they refused was posed to a Chrome engineer in todays Blink Q&A (http://www.youtube.com/watch?v=TlJob8K_OwE#t=13m34s), and according to him the request for integration came shortly after Chrome was released, and the reason for their refusal was the sheer scale/complexity of the task.

In light of this, your initial "if Google had only upstreamed their multiprocess support...we almost surely" and reiterations on this point within the thread do seem a bit like PR sleight of hand, since out of context it implies willingness to do so was the only issue on their part.

1) The answer wasn't "we'd like to do this but we're super busy right now, how about later" or "that's super complicated, will you guys put in a lot of the effort". It was a pretty direct no. We would have been willing to do much of the work.

2) My recollection is that we talked about it around a year after Chrome was released. Chrome Beta release date: September 2, 2008 Date of WebKit2 announcement: Thu Apr 8, 2010 (after <1 year of development) I don't have records of the meetings where we walked though.

3) Does the reason for saying no affect whether our choice to make our own thing was reasonable?

I think it's reasonable to say this is one of those situations where different sides simply interpreted the situation very differently.

If this is actually true, then the schism is truly a tragedy.

With regards to 3), yes it does affect it since a "flexible/malleable no" is an altogether different constraint from a "solid no", so the solution would be measured against a different yardstick in the former case. Pressing on with your own thing in the interests of time to market (and thereby further cementing the more mature implementation not being integrated) in that scenario does strike me as less than ideal/short-sighted.

This is somewhat moot with 1) and 2) being the case (or at the very least strongly perceived to be the case on your side). At any rate neither side being able to settle on a single version of events signals a communication problem, which makes the whole value of this hypothetical joint undertaking fuzzy anyway.

Yeah, I didn't intend this to turn into a back and forth. I think we both had similar intentions, but from different perspectives and with different first-hand information that may not be well communicated. I agree that it's best to leave it be from here. I think both of us and our respective projects bear no ill will and desire the best for the Web as a whole, despite differences in how exactly to get there.

Hi Maciej. Sorry if my comments read as though I was implying that you were wrong or bullheaded to choose WebKit2. That wasn't my intention; there are of course good technical arguments for choosing either architecture, and I'll choose my words more carefully next time the question comes up.

Thanks, Mike. And sorry also if my reply was too lengthy or pedantic or otherwise out of place. I feel bad for getting into a back-and-forth about this.

Open always wins.

This is a sad day.

I always believed (hoped) you guys would never be corrupted and do the right thing for the world and not be swayed by organizational affinities / commercial gains.

You have a greater responsibility than to your company or country to keep the web open.

Think on that before you have a further public 'kiddy debate' on she said / he said and throwing the rattle out of the pram.

Disappointed.

> 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.

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.

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.

Correct- Apple's announcement of the WebKit2 changes- https://lists.webkit.org/pipermail/webkit-dev/2013-January/t...

This post put me completely on Google's side: https://lists.webkit.org/pipermail/webkit-dev/2013-January/0...

"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.

Google is no different policy-wise for the chromium project. Neither of them are saints here.

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.

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.

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&....

If you see this other thread 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.

Isn't WebKit2 as much a fork of WebKit as Blink is? And it's not production ready?

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.

Reply on news.ycombinator.com