Browser Split - Google And Opera Fork WebKit To Blink
Written by Mike James   
Thursday, 04 April 2013

It has been something of a mystery as to how the WebKit community managed to not only stay together but to mostly "play nicely". Now we have the, not entirely unpredictable, split with Google creating a new, but WebKit derived, engine called Blink which Opera has already signed up to support. 

Apple and Google have been working together for some time on the WebKit project, but there have been lots of tensions between the two companies because of their different needs see  Who Is Building WebKit?       

Apple uses WebKit in its Safari browser but Google uses WebKit as part of the Chrome browser and Chrome OS. What this means is that Apple really only wants WebKit to be good enough to power a browser but Google needs more.

In fact there are even disadvantages to Apple if the Safari browser was to become more powerful because web apps are out of Apple's control and have the potential to short-circuit the App Store and Apple's profit. 

 

chromiumicon

 

Notice that WebKit isn't the whole of the browser by any means. It is the HTML rendering engine that builds the graphical representation of the page and allows the JavaScript engine to interact with the DOM etc. There are quite big differences in presentation between browsers based on the same rendering engine. However, from a programmer's point of view browsers that use the same engine can be mostly expected to behave in the same way. They form a single platform for web apps. So if some app worked on Safari then it would probably work in the same way on Chrome. This was why Opera's decision to drop development of its own browser engine and use WebKit was good as well as bad news - one fewer platform.

Now we have a split in the WebKit community that is about to create one more web platform. Google has decided that it needs a rendering engine that it has more control over and has forked WebKit to create Blink. The argument is that Google will be able to innovate more quickly and simplify the code of Blink because of not having to support a range of architectures. To quote the Chromium Blog:

"In the short term, Blink will bring little change for web developers. The bulk of the initial work will focus on internal architectural improvements and a simplification of the codebase. For example, we anticipate that we’ll be able to remove 7 build systems and delete more than 7,000 files—comprising more than 4.5 million lines—right off the bat. Over the long term a healthier codebase leads to more stability and fewer bugs."

This sounds like a worthwhile saving, but the sting for developers is "In the short term". Of course in the long term Blink will diverge from the WebKit core and introduce new features that make it a distinct entity. However, we have been promised that there will be no new CSS prefix for Blink - specifc features will be enabled using options. The Blink Developer FAQ promises that it will speed up the DOM and the JS engine while keeping the browser secure. 

What about compatibility? 

You might think that simply sticking to standard HTML5 or the W3C standards in general would guarantee uniformity in browsers, but we all know that this isn't true. The FAQ. does its best to put our minds at rest by stating that compatibility is important. However, it does a better job of arguing that diversity is good for innovation and incompatibilities just have to be lived with.  To quote the FAQ:

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.

So that's a yes then....

There is another interesting problem for Google. Currently Chrome is the only alternative to Safari on iOS, but the rules of the game, invented by Apple, say that any iOS browser has to use WebKit. If Chrome is going to run under iOS in the future either Google is going to have to make a special version or Apple is going to have to regard Blink as a version of WebKit. This could be interesting. 

Putting this together with Mozilla's announcement of a new rendering engine in the form of Servo (Mozilla Builds Servo A New Browser Engine) it seems that we are entering a new and more fragmented time. In principle, the web platform should be unified but we know that in practice it isn't . Each browser, or more properly browser engine, is its own platform that we have to tweak applications for. Chrome suddenly changing its rendering engine is on a par with, say, Ubuntu deciding to use its own Linux kernel and not just a cosmetic change.

It is worth it?

From Google's point of view very probably.

 

chromiumicon

More Information

Blink: A rendering engine for the Chromium project

Blink Developer FAQ.

Blink Project

Related Articles

Mozilla Builds Servo A New Browser Engine

Who Is Building WebKit?       

Opera Moving to WebKit       

When Open Source Attacks       

 

To be informed about new articles on I Programmer, install the I Programmer Toolbar, subscribe to the RSS feed, follow us on, Twitter, FacebookGoogle+ or Linkedin,  or sign up for our weekly newsletter.

espbook

 

Comments




or email your comment to: comments@i-programmer.info

Banner


Apache Fury Adds Optimized Serializers For Scala
31/10/2024

Apache Fury has been updated to add GraalVM native images and with optimized serializers for Scala collection. The update also reduces Scala collection serialization cost via the use of  encoding [ ... ]



Microsoft Introduces Unified .NET API For AI
14/10/2024

Microsoft has introduced new libraries for integrating AI services into .NET applications and libraries, along with middleware for adding key capabilities.


More News

 

 

Last Updated ( Thursday, 04 April 2013 )