Live data from Hacker News

Blink: A rendering engine for the Chromium project

blog.chromium.org

81–90 of 326 posts

Re: Blink: A rendering engine for the Chromium project

#81
post #67

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?

Yes. It's (finally) slowly being upstreamed, however. iBooks uses a separate fork of WebKit, too.

Re: Blink: A rendering engine for the Chromium project

#82
post #33

Earlier 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're a bit worried about compatibility, certainly. One important thing to note is that WebKit has _tens of thousands_ of layout tests; all of those tests exist right now in the Blink repository, and we're certainly going to continue working with browser vendors in general and the W3C to ensure that we can agree on exactly what standards mean, and how they should be rendered.

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

#83

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

Right, I wasn't saying this in a negative way :). That is quite interesting!

Re: Blink: A rendering engine for the Chromium project

#84

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

Blink remains very much open source: the repository should be visible in a minute or three.

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

#85
post #33

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

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.

Re: Blink: A rendering engine for the Chromium project

#86

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

Yeah. It would be the same problem that WebSQL had: http://www.w3.org/TR/webdatabase/

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

#87

I 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 :(

I'll say from personal experience on two recent projects: if you're only testing in one webkit browser and not hitting the others there's a good chance that you're missing a couple of bugs. There are a ton of different ways to build webkit, Chrome and Safari were never identical enough to ignore. Fortunately, after developing in Chrome it took about as much effort to support Firefox as it did to support Safari, which is to say about half an hour.

Re: Blink: A rendering engine for the Chromium project

#88

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…

Since every developer will want it to work in Chrome, this effectively kills vendor prefixes once and for all. It doesn't make sense for Microsoft or WebKit to continue to include them.

Re: Blink: A rendering engine for the Chromium project

#90
A little out of left field here, but if anyone is interested in working on the other multi-process browser (for OS X at least) I've just released Stainless as open source. Stainless was a hack that actually became quite popular while we Mac users waited for Google to release Chrome for our platform. http://stainlessapp.com
Post reply on HN