Chromium have a very agressive innovative agenda, compared to other players.. im sure they will benefit from this move.. They were probably carrying webkit in their own shoulders anyway, cause nobody does so much experiments as chromium team does.. If they have the energy to do it.. thats good news for us :)
> compared to other players Do you have a source for this?
Blink: A rendering engine for the Chromium project
181–190 of 326 posts
Re: Blink: A rendering engine for the Chromium project
#182Earlier quoted context omitted.
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 th…
> 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.
Re: Blink: A rendering engine for the Chromium project
#183So, 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…
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…
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).
Re: Blink: A rendering engine for the Chromium project
#184Earlier 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…
> 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.
Re: Blink: A rendering engine for the Chromium project
#185 , mall,Re: Blink: A rendering engine for the Chromium project
#186Re: Blink: A rendering engine for the Chromium project
#187Earlier quoted context omitted.
I agree, that would suck. Specially if -for some reason- we start seeing differences in terms of rendering speed/js engine/or other techs between the android version and the iOS version.
There already are speed differences in iOS alone. The native Safari has a faster JavaScript engine than the sandboxed Safari instances that iOS apps use. Or something like that. Something about security concerns.
It's the JIT for JavaScript that's disabled. I've never seen an official statement on it but I've read that it's that the security model in iOS does not allow compiling code and then executing it, but Mobile Safari gets a unique bypass for this security. Other apps which merely embed a UIWebView are stuck with interpreted JavaScript.
Re: Blink: A rendering engine for the Chromium project
#188Earlier quoted context omitted.
So Google will be using 2 increasingly different rendering engines for Chrome in the future? Well that sucks. Apple really needs to allow other rendering engines on iOS, or at least be forced into it. People complain about the "webkit mono-culture", but a huge platform like iOS actually mandating you use webkit, and their single version of webkit, is a lot worse.
They allowed Opera on the market. They allow other engines. They just don't allow private source code. Which just so happens to be part of Chromium.
Opera on iOS is actually Opera Mini, which doesn't run a rendering engine on the device at all.
And no, Apple does not allow other rendering engines so much. Specifically, they do not allow anything that can execute code that is not distributed with the app. So for example, no JS engine that's allowed to run scripts that don't ship with the app, period (even without a JIT).
Re: Blink: A rendering engine for the Chromium project
#189Earlier quoted context omitted.
That's an interesting way of looking at it. Apple no longer get a free ride. On the other hand, now that Firefox is using WebKit perhaps Mozilla just replaces Google there.
You do know that most of the WebKit code as it is is Apple's right? If anything it was Google who got a free ride.
I thought most of it is KDE's?
Re: Blink: A rendering engine for the Chromium project
#190Earlier 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.
Check out the Chrome Web Store. There are several tab management extensions. One's a quick tab list with a search box.