Rob Isaac is a New Zealand-based developer, technical analyst, and consultant. This FAQ was originally published on his website.
1 Why is Chrome spawning a new browser engine?
The WebKit maintainers wouldn’t let us attack Apple directly, by changing WebKit in ways that would make it perform badly on OS X and iOS.
Because they share a rendering engine, developer effort to ensure Chrome compatibility currently benefits Apple platforms for free. To prevent this, we must make Chrome and WebKit behave differently.
1.1 What sorts of things should I expect from Chrome?
Nothing yet. This is a political move, not a technical one.
However, while the Chrome user interface will not change in any significant way, we will be silently overwriting all existing installations of Chrome with our new rendering engine without your knowledge or consent.
1.2 Is this new browser engine going to fragment the web platform’s compatibility more?
We intend to distract people from this obvious problem by continually implying that our as-yet unwritten replacement is somehow much better and more sophisticated than the rendering engine that until yesterday was more than good enough to permit us to achieve total dominance of the Windows desktop browsing market in less than two years.
This strategy has worked extremely well for Netscape, Microsoft, Apple and us in previous iterations of the browser wars, and we firmly believe that everyone in this industry was born yesterday and they will not recognise this for the total bullshit it so clearly is.
1.3 Hold up, isn’t more browsers sharing WebKit better for compatibility?
Yes. See 1.
1.4 How does this affect web standards?
We have sufficient market share on the desktop that a few months from now, we will be in a position to unilaterally dictate them.
We hope to leverage this control to achieve the same dominance in mobile eventually.
1.5 Will we see a -chrome vendor prefix now?
No. See 1.4.
1.6 So we have an even more fragmented mobile WebKit story?
We encourage you to adopt Chrome on Android for your mobile browsing needs.
1.7 What’s stopping Chrome from shipping proprietary features?
1.8 Is this just a ruse to land the Dart VM or Native Client?
We’ve decided to avoid discussing unpopular topics like those for the time being.
1.9 What should we expect to see from Chrome and Blink in the next 12 months? What about the long term?
We have a direct strategic interest in destroying Apple’s mobile platforms because their lack of participation in our advertising and social ecosystems does not benefit our long term goals. You should expect Chrome and Blink changes in the short term to be focused in this direction.
In the longer term, we aim to have sufficient control over the installed base of web browsers to dictate whatever conditions we consider most appropriate to our business goals at the time.
1.10 Is this going to be open source?
While you can certainly read the source code, we’re fully aware that actually tracking and understanding a modern HTML renderer is extremely difficult. In addition, the first changes we will make are intended specifically to break compatibility with WebKit, so the only organisation with sufficient resources to track our changes will no longer be able to do so.
In practice, this allows us to call the project “open” while simultaneously ensuring Google will be the only effective contributor to the Chrome and Blink source now and in the future. We’ve had enormous success co-opting the language of open source in the past to imply our products are better, and we aim to continue with that strategy.
1.11 Opera recently announced they adopted Chromium for their browsers. What’s their plan?
Opera have such a tiny market share that they have no choice other than to follow whatever strategy Chromium adopts. In this case, it means they will adopt the Blink renderer as quickly as possible.
1.12 Why is this is good for me as a web developer?
It isn’t. Our primary goal is to use your development efforts as leverage against our competitors. See 1.9.