Developer FAQ - Why Blink?

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 Blink Architectural Changes section 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:

Deliver a speedier DOM and JS engine
- Multi-process, security-focused, and faster low-overhead DOM bindings to V8
- JIT DOM attribute getters in V8. That would allow V8 to access div.id, div.firstChild, etc without leaving JIT code. Mozilla is also meanwhile trying to JIT DOM attribute getters.
- 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.
Keep the platform secure
- Better sandboxing of the compositor thread
- Out-of-process iframes. Use renderer processes as a security boundary between cross-site iframes.
Refactor for performance
- 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.

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.

Please feel free to watch the development of Blink via Gitiles, follow along on the blink-dev mailing list, and join #blink on Freenode.

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.

Is this going to be open source?

Yes, of course. Chromium is already open-source and Blink is part of that project. Transparency is one of our core principles. Developing Blink covers this in detail.

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

Opera will be adopting Blink, as mentioned by Bruce Lawson on his blog.

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.

Engineering leads Darin Fisher and Eric Seidel are joined by PM Alex Komoroske and Developer Advocate Paul Irish

Below are the top-voted questions, along with timecodes you can click (will open in a new window): 1:12 What will be the relationship between the WebKit and Blink codebases going forward? 2:42 When will Blink ship on the Chrome channels Canary/Beta/Stable? 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"? 8:35 How will Blink responsibly deprecate prefixed CSS properties? 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. 19:34 How will affect other browsers that have adopted WebKit? 20:44 Does this means Google stops contributions to WebKit? 21:31 What Open Source license will Blink have? Will it continue to support the H.264 video codec? 22:11 Any user-agent string changes? 23:38 When we'll be able to test first versions of Blink in Chromium? 24:15 How can developers follow Blink's development? 25:40 What is chromestatus.com about? 26:40 How will this impact Dart language's progress? 27:13 Will this be a direct competitor against Mozilla's new engine? 29:03 When will all existing vendor prefixes in Blink be phased out? 30:20 Will you support -blink-text-decoration: blink? ;)