Why is Chrome spawning a new browser engine?

There are two main reasons why we’re making this change.

The main reason is that Chromium uses a different multi-process architecture from other WebKit-based browsers. So, over the years, supporting multiple architectures has led to increasing complexity for both the WebKit and Chromium communities, slowing down the collective pace of innovation.

In addition, this gives us an opportunity to do open-ended investigations into other performance improvement strategies. We want web applications to be as fast as possible. So for example, we want to make as many of the browser’s duties as possible run in parallel, so we can keep the main thread free for your application code. We’ve already made significant progress here--for example by reducing the impact JavaScript and layout have on page scrolling, and making it so an increasing number of CSS animations can run at 60fps even while JavaScript is doing some heavy-lifting--but this is just the start.

We want to do for networking, rendering and layout what V8 did for JavaScript. Remember JS engines before V8? We want the same sort of healthy innovation that benefits all users of the web, on all browsers.

What sorts of things should I expect from Chrome?

In the BlinkArchitectural Changessection we have listed a few changes that will improve the speed and stability of the web platform in Chrome. Meanwhile, there are more improvements whose feasibility and performance benefits we're excited to investigate:

Implement the DOM in JS. This has the potential to make JavaScript DOM access dramatically faster, but will involve a very large re-write of WebKit’s DOM implementation. IE is already doing this and overall, this helps yield faster GC, and faster DOM bindings

Support snapshotting in V8. This could allow us to have no parse-time overhead and near-instant startup of previously loaded pages.

Reduce binding layer overhead. We can make things even faster by simplifying the many abstractions in the binding layers that have existed to share code between JavaScriptCore and V8 (e.g. ScriptState, DOMRequestState, etc).

Improve the performance of style resolution.

Improve utilization of multiple cores.

Enable more powerful rendering and layout

Pursue multi-threaded layout

Overhaul style recalculation and selector resolution performance

Stop creating renderers for hidden iframes

Fix old bugs like plugins unloading when they're set to display:none.

Allow generated content to be selectable and copy-pasteable.

Rewrite event handling to be more consistent and have fewer bugs with focus, mouse up, clicks, etc.

Fire <iframe>unload events async to make removeChild faster.

Is this new browser engine going to fragment the web platform's compatibility more?

We're keenly aware of the compatibility challenges faced by developers today, and will be collaborating closely with other browser vendors to move the web forward and preserve the interoperability that has made it a successful ecosystem. We’ve also put a lot of work over the past few years into reducing that pain. Take one of the huge successes of the web standards community: the HTML5 Parser. All major browser engines now share the exact same parsing logic, which means things like broken markup, <a> tags wrapping block elements, and other edge cases are all handled consistently across browsers. This interoperability is important to Chrome and we want to defend it.

Our team regularly contributes to sites that document browser support and differences like Mozilla's MDN, WebPlatform.org, and Can I Use. The last thing we want is for things to go backwards.

We see testing as the critical piece of web browser interoperability. Chrome currently shares and runs tests that were authored by Opera, Mozilla, and W3C Working Groups and we'll be doing a better job of this going forward. Developers need to be able to rely on Chrome’s implementation of standards, and that’s something we take very seriously. See the Testing section for our plans.

Hold up, isn't more browsers sharing WebKit better for compatibility?

It's important to remember that WebKit is already not a homogenous target for developers. For example, features like WebGL and IndexedDB are only supported in some WebKit-based browsers. Understanding WebKit for Developers helps explain the details, like why <video>, fonts and 3D transforms implementations vary across WebKit browsers.

Today Firefox uses the Gecko engine, which isn’t based on WebKit, yet the two have a high level of compatibility. We’re adopting a similar approach to Mozilla by having a distinct yet compatible open-source engine. We will also continue to have open bug tracking and implementation status so you can see and contribute to what we’re working on at any time.

From a short-term perspective, monocultures seem good for developer productivity. From the long-term perspective, however, monocultures inevitably lead to stagnation. It is our firm belief that more options in rendering engines will lead to more innovation and a healthier web ecosystem.

How does this affect web standards?

Bringing a new browser engine into the world increases diversity. Though that in itself isn't our goal, it has the beneficial effect of ensuring that multiple interoperable implementations of accepted standards exist. Each engine will approach the same problem from a different direction, meaning that web developers can be more confident in the performance and security characteristics of the end result. It also makes it less likely that one implementation's quirks become de facto standards, which is good for the open web at large.

Will we see a -chrome- vendor prefix now?

We’ve seen how the proliferation of vendor prefixes has caused pain for developers and we don't want to exacerbate this. As of today, Chrome is adopting a policy on vendor prefixes, one that is similar to Mozilla's recently announced policy.

In short: we won't use vendor prefixes for new features. Instead, we’ll expose a single setting (in about:flags) to enable experimental DOM/CSS features for you to see what's coming, play around, and provide feedback, much as we do today with the “Experimental WebKit Features”/"Enable experimental Web Platform features" flag. Only when we're ready to see these features ship to stable will they be enabled by default in the dev/canary channels.

For legacy vendor-prefixed features, we will continue to use the -webkit- prefix because renaming all these prefixes to something else would cause developers unnecessary pain. We've started looking into real world usage of HTML5 and CSS3 features and hope to use data like this to better inform how we can responsibly deprecate prefixed properties and APIs. As for any non-standard features that we inherited (like -webkit-box-reflect), over time we hope to either help standardize or deprecate them on a case-by-case basis.

So we have an even more fragmented mobile WebKit story?

We really don’t want that; time spent papering over differences is time not spent building your apps’ features. We’re focusing our attention on making Chrome for Android the best possible mobile browser. So you should expect the same compatibility, rapid release schedule and super high JS and DOM performance that you get in desktop Chrome.

Your site or app's success on the mobile web is dependent on the mobile browsers it runs on. We want to see that entire mobile web platform keeps pace with, and even anticipates, the ambitions of your app. Opera is already shipping a beta of their Chromium-based browser which has features and capabilities very similar to what's in Chrome on Android.

What's stopping Chrome from shipping proprietary features?

Our goal is to drive innovation and improve the compatible, open web platform, not to add a ton of features and break compatibility with other browsers. We're introducing strong developer-facing policies on adding new features, the use of vendor prefixes, and when a feature should be considered stable enough to ship. This codifies our policy on thoughtfully augmenting the platform, and as transparency is a core principle of Blink, we hope this process is equally visible to you. The Chromium Feature Dashboard we recently introduced offers a view of the standards and implementation status of many of our implemented and planned features.

We know that the introduction of a new rendering engine can have significant implications for the web. In the coming months we hope to earn the respect of the broader open web community by letting our actions speak louder than words.

Is this just a ruse to land Google-developed technologies?

Nope, not at all! We're instituting strong guidelines on new features that emphasize standards, interoperability, and transparency. We expect to hold all new shipping features that affect web developers on the open web up to the same level of scrutiny. Technologies and standards developed primarily within Google will be held to the same guidelines as others.

What should we expect to see from Chrome and Blink in the next 12 months? What about the long term?

Our main short-term aim is to improve performance, compatibility and stability for all the platforms where we ship Chrome. In the long term we hope to significantly improve Chrome and inspire innovation among all the browser manufacturers. We will be increasing our investment in conformance tests (shared with W3C working groups) as part of our commitment to being good citizens of the open web.

Opera recently announced they adopted Chromium for their browsers. What's their plan?

Why is this is good for me as a web developer?

One of the keys to improving users’ experience is to give developers the tools, features, compatibility and performance they need to get the most out of the platform. Although the move is borne out of architectural necessity, it also allows us to prioritize the features that you need to build the next generation of apps, on both mobile and desktop. Similar to the introduction of V8, we hope this will spur innovation and you can and should expect the whole web platform to benefit.

Our ambitions are high and we continue to need the feedback and contributions that have made Chrome the browser it is today. You should also expect improved transparency in Blink's development processes, so getting involved will be easier than ever. Please, review the Chromium Feature Dashboard, experiment with future features in Dev/Canary and file any bugs you find.

~ FAQ authored by Paul Irish and Paul Lewis on the Chrome Developer Relations team

Q&A Video

After the Blink announcement, the developer community submitted hundreds of questions and votes on Google Moderator (goo.gl/Uu0qV) that sought answers to your tough questions about Blink.

3:25 How does the plan for transitioning the WebKit integrated in Android to Blink look like?

4:59 Can you elaborate on the idea of moving the DOM into JavaScript?6:40 Can you elaborate on the idea of "removing obscure parts of the DOM and make backwards incompatible changesthat benefit performance or remove complexity"?

9:30 What will prevent the same collaborative development difficulties that have hampered Webkit emerging in Blink, as it gains more contributors and is ported to more platforms?

12:35 Will changes to Blink be contributed back to the WebKit project?

13:34 Google said problems living with the WebKit2 multi-process model was a prime reason to create Blink, but Apple engineers say they asked to integrate Chromium's multi-process into WebKit prior to creating WebKit2, and were refused. What gives?16:46 Is the plan to shift Android's <webview> implementation over to Blink as well?

17:26 Will blink be able to support multiple scripting languages? E.g. Dart.