Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blink: A rendering engine for the Chromium project

blog.chromium.org

Post reply on HN
Print view View original

271–280 of 326 posts

Re: Blink: A rendering engine for the Chromium project

#271

Post by zanny »

tripzilch wrote: post #260
mikewest wrote: post #136

Earlier quoted context omitted.

WebKit and Chromium are different repositories, and point to each other via a "DEPS" (dependencies) file. We roll new revisions of WebKit into Chromium regularly, and call the process of diagnosing and fixing problems with the rolls "Gardening": http://www.chromium.org/developers/how-tos/webkit-gardening is a good reference.

Hey, clicking around that Wiki it has some pretty interesting information. Do other large open-source projects have a very similar workflow?

You mean having full-time engineers handling merge conflicts / upstream breakage / regressions / running test suites? In anything sufficiently large, that becomes a major issue inevitably.

Almost any project worth its salt has someone doing testing. But it is really time consuming.

Re: Blink: A rendering engine for the Chromium project

#272

Post by zanny »

tambourine_man wrote: post #180

Very sad news. This seems more of a political/economical move than a technical one. Two of the biggest players (and now arch rivals) sharing what's arguably the most strategic piece of code there is, couldn't last very long. It's a shame though. It was probably the biggest open source success story. An open source monoculture is not the same as a proprietary monopoly.

Open source monocultures can be pretty bad. Look at how Mir has jumpstarted Wayland interest and adoption after it has stagnated for a few years.

Likewise, look at how GCC is now dramatically improving since Clang became competitive.

Or look at how Firefox back in the good old days picked up the pace after Chrome(ium) happened.

Re: Blink: A rendering engine for the Chromium project

#273

Post by Shooti »

malandrew wrote: post #167
tolmasky wrote: post #139

Earlier quoted context omitted.

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

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.

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

Re: Blink: A rendering engine for the Chromium project

#274

Post by bradleyjg »

tripzilch wrote: post #260
mikewest wrote: post #136

Earlier quoted context omitted.

WebKit and Chromium are different repositories, and point to each other via a "DEPS" (dependencies) file. We roll new revisions of WebKit into Chromium regularly, and call the process of diagnosing and fixing problems with the rolls "Gardening": http://www.chromium.org/developers/how-tos/webkit-gardening is a good reference.

Hey, clicking around that Wiki it has some pretty interesting information. Do other large open-source projects have a very similar workflow?

The most significant long term upstream-downstream relationships are probably the linux distros to the kernel.

Re: Blink: A rendering engine for the Chromium project

#275

Post by workbench »

kevincennis wrote: post #133
tolmasky wrote: post #124

Earlier quoted context omitted.

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 t…

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

Interface is nicer and more native.

Chrome is even starting to drop native dialog boxes

Re: Blink: A rendering engine for the Chromium project

#276

Post by workbench »

cpeterso wrote: post #42

The good news is no -blink prefixes! Blink, like Mozilla, will avoid shipping vendor-prefixed features: Historically, browsers have relied on vendor prefixes (e.g., -webkit-feature) to ship experimental features to web developers. This approach can be harmful to compatibility because web content comes to rely upon these vendor-prefixed names. Going forward ... we will instead keep the (unprefixed) feature behind the…

That sounds far worse to me, so I can't even use the new features as they arrive.

I couldn't care less if they add -blink, it takes minutes to push that through a modern CSS codebase. At least I can use the features where they exist.

Re: Blink: A rendering engine for the Chromium project

#278

Post by klapinat0r »

cpeterso wrote: post #42

The good news is no -blink prefixes! Blink, like Mozilla, will avoid shipping vendor-prefixed features: Historically, browsers have relied on vendor prefixes (e.g., -webkit-feature) to ship experimental features to web developers. This approach can be harmful to compatibility because web content comes to rely upon these vendor-prefixed names. Going forward ... we will instead keep the (unprefixed) feature behind the…

Sorry if I'm dense, but unlike mozilla? are mozilla css extensions not "prefixes" in this context? https://developer.mozilla.org/en-US/docs/CSS/CSS_Reference/M...

or can someone explain to me the difference?

Re: Blink: A rendering engine for the Chromium project

#280

Post by easytiger »

tolmasky wrote: post #124
macrael wrote: post #112

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 maintainin…

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 t…

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