April 3rd was an interesting day in the mobile industry, with major announcements that might re-shape the mobile web.
Had these announcements been made two days earlier on April 1, and I might have thought someone was playing a rather large joke.
A strong desktop and mobile web presence is critical to travel suppliers, intermediaries and content providers, so understanding the implications of this recent news is critical.
Change in a Blink
The news that got most of the attention was Google’s decision to diverge from Webkit to introduce Blink as Chrome's new rendering engine.
Many people – myself included – referred to Blink as a fork of WebKit. While this is accurate, "fork" is often a short-hand, pejorative term. But before we ascribe bad intentions to the move, let’s take a step back for some context.
Webkit, for sure, was the largest browser engine, but didn't have a majority of desktop web usage.
The numbers tell a very different story when you look at mobile browsing statistics (I used US numbers as a proxy for smartphone usage).
On mobile devices (which now outnumber desktop devices) WebKit has been all that's mattered:
But Webkit was never a homogeneous entity.
As such, the forking of WebKit might not be as big of a deal as many fear.
Samsung/Mozilla partnership could have a bigger impact on the mobile industry
On the face of it, the other announcement seems less impactful, but is more intriguing.
Mozilla announced that it is partnering with Samsung to create a next-generation browser engine called Servo.
Two thoughts come to mind.
First, Samsung seems to be steadily pseudo-forking Android for its own purposes.
TouchWiz user-interface, S-apps that replace core Google services (e.g. messaging, translation, voice, navigation, app store), and the Knox platform seem to be creating a Samsung experience, almost to the point that it wouldn't be recognizable as Android.
In fact, if you look at Samsung’s advertising, it's virtually free of any mention of Android.
What's missing is a browser, and developing one could be Samsung's plan.
Could the browser be the last step before truly forking Android as Amazon has? And if that happened, could it be said that Google has lost control of the platform? That would have seismic effects on the industry.
Second, for Mozilla, this could be the next step in maturing the Firefox operating system (OS). More importantly, it could line up the #1 non-Apple smartphone brand in the world as a manufacturer.
Community projects aren't always the Utopia we want them to be
Google is no doubt making this decision to further its own interests and perhaps the announcement about Blink will allow it to speed up the delivery of improvements to Chrome.
According to Alex Russell, a Google Chrome engineer, productivity gains are the primary driving force behind the move. Nothing nefarious, just Google’s laser-like focus on execution and speed.
Or is it?
The truth is that when you have a lot of people contributing to a project you reach a point where priorities diverge and that really seems to be at the crux of Google’s decision to introduce Blink.
All you have to do is look at Chrome's current advertising spot and it becomes clear:
Google wants to more tightly integrate your browsing experience across all devices. (Even though the ad doesn't include TVs, TVs are definitely part of the company's vision.)
Having greater control of the core browsing engine is likely seen as a linchpin to deliver this vision.
Given the many different voices that are part of a community project, Google probably couldn't get where it wanted to go without making a change.
Besides, if Google thinks it provides a competitive advantage, I can understand why they would choose not to share.
Further, the conspiracy theorist in me also sees this as a move done primarily because it directly hurts Apple, Google’s primary (only?) competitor in mobile.
Lee Matthews of Geek.com notes:
“For quite a while now, Google has held the number one spot on the WebKit code commit “leaderboard.”
Now that its engineers are working on Blink, that leaves WebKit with a greatly reduced number of active contributors”, which can pose quite a challenge for Apple to ensure that WebKit keeps up with Chrome from a technical perspective.
With Samsung joining forces with Mozilla on Servo, we don’t know how much future contributions WebKit will get from them either – Samsung has no love lost for Apple either.
And while Google gave good reasons for pulling out of WebKit, primarily pointing to Chromium's use of a multi-process architecture, it didn't have to happen that way, according to an Apple developer who is part of the WebKit team:
“…the main reason we built a new multiprocess architecture is that Chromium's multiprocess support was never contributed to the WebKit project. It has always lived in the separate Chromium tree, making it pretty hard to use for non-Chrome purposes.
Before we wrote a single line of what would become WebKit2 we directly asked the Google folks if they would be willing to contribute their multiprocess support back to WebKit, so that we could build on it. They said no...
If Google had upstreamed their multiprocess support, we almost surely would have built on it. And history might have turned out differently.”
Modestly higher workloads for Web and mobile developers
In many ways the amount of work that development teams need to expend won’t change very much. Servo replaces Gekko for all intents and purposes, so that’s a wash.
You can say that Blink becomes the 4th engine, essentially taking the place of Presto (previously used by the Opera browser), but given the low market share for Opera, I would wager that many organizations didn’t develop or test for it specifically.
And even though Blink is a fork of WebKit, will it really be that different? Will it really require that much incremental effort for developers? Xavier Facon, CTO of Crisp Media (a leading mobile advertising platform provider) doesn’t think so:
It won't make life easier or harder. These two engines [Blink and WebKit] will stay more similar to each other than compared to Servo and others.
In fact, the approach of using flags in Blink, and carefully remove Webkit prefixes, allows new experimental features to be rolled out in fully backwards compatible approach.
Bastien Cojan, Technical Director for Ness’ Imano mobile development team, notes that web developers will have to go back to testing Chrome and Safari separately, though he says that many firms were doing that anyway as the differences between the two WebKit–based platforms were already significant enough to merit it.
Better security, stability and performance
All code gets worse over time. It’s not that the code itself degrades, but the layers and layers that are added increases code complexity, introduces bugs and expands vulnerabilities.
So the streamlining of the codebase that will result from Blink (Google says they will remove 4.5 million lines of code and 7,000 files) and the removal of the Google-dependent code in Webkit should enhance both products.
Veracode, a leading application security platform vendor, agrees noting on its blog that there have been 210 reported security holes in Webkit since it launched in 2007, with 207 of those discovered in the last three years, including some moderately serious security holes.
Given that Android accounts for 79% of all malware on smartphones, one can see why Google was keen to close up some of these holes.
This will be good for the industry
It’s generally a good thing when everybody works together. Life becomes more consistent, orderly. Standards, even if they are de facto, help the productivity of developers everywhere.
But significant change such as Blink and Servo can spur innovation and really move an industry forward.
With Apple, Google, Samsung and Microsoft all with significant skin in the game, they will have to really up their efforts. The consumer will be the beneficiary in the form of better products and experiences.
Crisp Media’s Facon says:
“I am pretty certain, all considered, it is a positive. There are various mobile OS and browser projects scheduled by Samsung, Intel, Google, Apple, Opera, etc... that we don't know about.
Some of those projects are made complicated for developers when there is code share going on between all these competitors.
For Google to take this step was brave, considering they probably expected some backlash, but it solved business problems for both Apple and Google that allow them to move faster on projects we will end up caring about once we know them.”
“These new web engines seem to be developed with 'mobile in mind', which should speed up the current mobile development and have a better handle of device specificities as it will be directly developed by the device manufacturers (Google + Samsung).
In theory, this should make the developer's life easier (think Apple owning both hardware and software) and reduce the need for handling high number of different cases for different devices.
NB: Data for the charts is from StatCounter, charts created by Glenn Gruber.