03 4 / 2013
Chrome is departing WebKit as its rendering engine. This is big news for web developers, so I thought I’d write up my personal take on the matter. Please realize these are my own thoughts and not those of Google.
The new engine is called Blink. It’s open source and based WebKit.
"You’re kidding, right!?"
That was my reaction when I first heard the news. It was quickly followed by: “Won’t this segment the web even further?” and “Great. An additional rendering engine I have to test.” Being a web developer, I feel your pain.
Honestly, I was extremely skeptical about the decision at first. After several conversations with various members of the web platform team here at Google, I was slowly convinced it might not be such a terrible idea after all. In fact, I’m now convinced it’s a good idea for the long term health and innovation of browsers.
Reflecting on Chrome’s mission
Many of you will be in the same skeptic boat I was. But I think it’s worth remembering the continuing goals of the Chromium project.
From day one the Chrome team’s mission has been to build the best browser possible. Speed, security, and simplicity are in its blood. Over the last four years, I have gained a deep respect for our engineering team. They’re some of the most brilliant engineers in the world. If their consensus is that Chrome cannot be the best browser it can be with WebKit at its core, I fully trust and support that decision. After all, these folks know how to build browsers. If you think about it some more things start to make sense. The architecture of today’s web browser is dramatically different than it was back in 2001 (when WebKit was designed).
The irony in all of this is that we were soon destined to have three render engines with Opera’s impending move to WebKit. Even today, Mozilla/Samsung announced their work on a new engine, called Servo. So, we were at three engines. Now we have 4+. Interesting times indeed.
Things we can all look forward to
Ultimately, Chrome is engineering driven project and I’m personally excited about the potential this change offers. Here are a few:
Improved performance & security
Many ideas and proposals have sprung up about things like out of process iframes, moving DOM to JS, multi-threaded layout, faster DOM bindings,…. Big architectural changes and refactorings means Chrome gets smaller, more secure, and faster over time.
Increased transparency, accountability, responsibility
Every feature added to the web platform has a cost. Through efforts like Chromium Feature Dashboard - chromestatus.com, developers will be in the full know about what features we’re adding. New APIs are going under a fine comb before being released. There’s an extensive process for adding new features.
By the way, watch for chromestatus.com to get much more robust in the coming months. I’m personally helping with that project. Look forward to it’s v2 :)
No vendor prefixes
What a debacle vendor prefixes have been! Features in Blink are going to be implemented unprefixed and kept behind the “Enable experimental web platform features” flag until they’re ready for prime time. This is a great thing for authors.
Testing Testing Testing
More conformance testing is a win. Period. There’s a huge benefit to all browser vendors when things are interoperable. Blink will be no exception.
I see Blink as an opportunity to take browser engines to the next level. Innovation needs to happen at all levels of the stack, not just shiny new HTML5 features.
Having multiple rendering engines—similar to having multiple browsers—will spur innovation and over time improve the health of the entire open web ecosystem.
If you have burning questions for Blink’s engineering leads (Darin Fisher, Eric Seidel), post them. There will be a live video Q&A tomorrow (Thursday, April 4th) at 1PM PST: developers.google.com/live
Permalink 10 notes