Earlier quoted context omitted.
The argument is essentially: "It took up lots of engineering time and effort to maintain compatibility with other platforms, so this allows us not to worry about other platforms and only focus on our own and that will allow us to move faster." Hopefully this is easier for everyone. If the chrome multithreading architecture really was the pain point then does that mean that webkit will also be deleting thousands of fi…
Does Apple already maintain a private WebKit fork for iOS?
Blink: A rendering engine for the Chromium project
81–90 of 326 posts
Re: Blink: A rendering engine for the Chromium project
#82Earlier quoted context omitted.
No, it just means that instead of Chrome for Android and Chrome for iOS having different versions of WebKit, Chrome for Android will use Blink and Chrome for iOS will use the system WebKit, as it does now.
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.
We'll be coming at the same problems from different angles, find and fix different bugs, and have the opportunity to peek at how other browsers have done things. I'm quite hopeful that will mean that we'll all end up with better implementations.
Re: Blink: A rendering engine for the Chromium project
#83Super excited about this! There was a long discussion on the webkit mailing list after google tried to add support for multiple language VMs in webkit. The goal was to have a native Dart VM. https://lists.webkit.org/pipermail/webkit-dev/2011-December/... If I remember correctly, the patch was not merged in. I guess now google can do whatever it wants!
This is addressed in the FAQ: http://www.chromium.org/blink/developer-faq#TOC-Is-this-just... http://www.chromium.org/blink#new-features Additionally: we have had experimental Dart+Chromium builds for a long time, they use a different approach (V8 bindings layer) that doesn't require WebKit changes. However we only use these builds for fast development edit+refresh, for deploying Dart code you should use dart2js (it'…
Re: Blink: A rendering engine for the Chromium project
#84Earlier quoted context omitted.
If you look at the commits, there's a fair argument that Google "controls" WebKit. You could almost say Apple got KHTML'ed ;) I believe this is an honest move. This is what happens with software. Goals change, old code and design no longer makes sense, you refactor or rewrite. The architecture of WebKit was created to address goals that are a decade old now. The multi-process nature of Chrome alone, an amazing achiev…
If you want to really put a tinfoil cap on, you could say that by Google contributing to WebKit they are giving Apple a lot of free code, allowing them to devote fewer resources to their browser. Once Blink diverges father from WebKit it won't be practical for WebKit to merge in changes from there. One has to wonder if Google will be recruiting other WebKit contributors (RIM, Intel, Nokia, etc) to move over to Blink.…
We're going to be even more transparent than we currently are, actually, about how things get added to the platform http://www.chromium.org/blink#new-features. I'm pretty excited about how that's going to play out with regard to sharing ideas and implementations.
Re: Blink: A rendering engine for the Chromium project
#85Earlier 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.
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.
Or something like that. Something about security concerns.
Re: Blink: A rendering engine for the Chromium project
#86I know it might be an unpopular comment, but I really don't like this. I had hoped every browser would eventually use the webkit rendering engine. I have a hard time feeling sorry for those engineers that have to maintain compatibility, when I think of the many frontend engineers that now have to test a different rendering engine :(
Rendering engine monoculture isn't a good thing though. If a single rendering engine dominates, then there is less reason to write standards-compliant code - after all, everyone uses WebKit, right?
As much as I was sad to see it go, I sympathize with their problem. If you just have a single C/C++ implementation with no spec, it's a lot harder to know, as a user/web developer, what the correct behavior is and what you can rely on.
Re: Blink: A rendering engine for the Chromium project
#87I know it might be an unpopular comment, but I really don't like this. I had hoped every browser would eventually use the webkit rendering engine. I have a hard time feeling sorry for those engineers that have to maintain compatibility, when I think of the many frontend engineers that now have to test a different rendering engine :(
Re: Blink: A rendering engine for the Chromium project
#88The 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…