Developer FAQ - Why Blink?
There are two main reasons why we’re making this change.
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.
- 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
- Refactor for performance
- 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.
<iframe>unload events async to make removeChild faster.
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.
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
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.
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.
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
experimental Web Platform features"==
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
prefix because renaming all these prefixes to something else would cause
developers unnecessary pain. We've started looking
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.
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.
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.
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.
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 will be adopting Blink, as mentioned by Bruce Lawson on his blog.
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
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