Live data from Hacker News

Blink: A rendering engine for the Chromium project

blog.chromium.org

291–300 of 326 posts

Re: Blink: A rendering engine for the Chromium project

#291
post #145

Earlier quoted context omitted.

Finally! Before anyone starts moaning about incompatibility, let's face it: developers start to rely on new features the moment they're added. Differentiating between different implementations is pointless, since CSS's design means you can specify a property multiple times and your browser will only use the one it understands. The current system also excluded other rendering engines who web developers didn't consider…

Hmm, isn't it true though, for example, that without that we'd have had to wait a long time to get simple things like border-radius that were supported in all the browsers but hidden behind vendor extensions? Having experimental features available to developers creates pressure for all browsers to move forward. Without that we won't know what is important to developers because they'll be stuck using what the browser…

Yes exactly.

The 'yay no vendor prefixes!' crew seem to have very short memories on what it was like before vendor prefixes..IE Waiting a LONG time (years) for a CSS feature to be 'recommended' by the w3c.

Vendor Prefixes were the best of a bad situation, I think they will be missed quite quickly.

I'm all up for this movement, but the W3C will need to move a lot quicker if this is to happen. Otherwise innovation will just grind to a halt again like it did before.

Re: Blink: A rendering engine for the Chromium project

#292

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?

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

Re: Blink: A rendering engine for the Chromium project

#293
post #191

Earlier quoted context omitted.

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

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.

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.

Re: Blink: A rendering engine for the Chromium project

#294

Earlier quoted context omitted.

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

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)

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

Re: Blink: A rendering engine for the Chromium project

#295

Earlier quoted context omitted.

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

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

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

Re: Blink: A rendering engine for the Chromium project

#296

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…

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.

Re: Blink: A rendering engine for the Chromium project

#297

Earlier quoted context omitted.

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

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

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

Re: Blink: A rendering engine for the Chromium project

#298

Earlier quoted context omitted.

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

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

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.

Re: Blink: A rendering engine for the Chromium project

#299
post #272

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.

Multiple efforts can increase competition or spread resources thin.

We already have 3 major engines. Do we need a fourth? The Linux Kernel combines all efforts in a single thriving project, while we have multiple desktop distributions struggling to get a single digit percentage of the market.

Re: Blink: A rendering engine for the Chromium project

#300

Earlier quoted context omitted.

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 & god…

>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.
Post reply on HN