Hacker News Reader

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.

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

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

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

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

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

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.

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.

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.

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

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.

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… :)

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

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.

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

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

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.

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.

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.

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

Interface is nicer and more native.

Chrome is even starting to drop native dialog boxes

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

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

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