Rob Isaac is a New Zealand-based developer, technical analyst, and consultant. After the news that Google would be creating its own, Chrome-specific version of the Webkit browser rendering engine, called Blink, Isaac created this “translation” of Google’s developer FAQ for Blink. 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?

Yes.

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?

Yes.

We encourage you to adopt Chrome on Android for your mobile browsing needs.

1.7 What’s stopping Chrome from shipping proprietary features?

Nothing.

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?

Not really.

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.

photo credit: nitot via photopin cc

July 9-10, 2013
San Francisco, CA

Tickets On Sale Now

Web browser engines may not be particularly exciting, but they sure are in the news a lot as of late.

Yesterday Google announced it was ditching the WebKit mobile browser engine in favor of Blink, its own in-house fork. That move was as much about speed as it was control: By developing its own browser engine, Google says it can accelerate development (and also maybe control the direction of the mobile web).

Now, rival browser maker Opera is following in Google’s footsteps, the company confirmed today.

“When we announced the move away from Presto, we announced that we are going with the Chromium package, and the forking and name change have little practical influence on the Opera browsers,” an Opera spokesperson told The Next Web.

Essentially, nothing has changed for Opera, which announced in February that it was adopting WebKit for its own mobile browser. But the company also pledged support for Chromium, the open source counterpart to Chrome — which is why it’s going with Google rather than sticking with WebKit.

Opera’s confirmation comes the day after Samsung announced it was teaming up with Mozilla to develop Servo, a browser engine designed to take advantage of multi-core devices.

It’s all a tad confusing, but here’s the gist: Developing your own browsing engine gives you more influence over the browsers that use it. This means control, which is becoming increasingly important in the growing world of the mobile web.

While it’s too early to predict what will happen with all of these browsing engines, we do know that developers are going to have quite a time working with all of them.

Photo: Flickr/Johan Larsson

Why?

Google says that using WebKit is slowing down innovation, because “Chromium uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects.”

The solution is Blink, Chromium’s new rendering engine. It’s a fork of WebKit that will use largely the same codebase, minus a significant amount of no-longer-needed code: 7,000 files and 4.5 million lines of code. That will make the codebase slimmer — obviously — as well as more stable, more secure, and less buggy, according to Google.

WebKit emerged from the KHTML browser when Apple took KHTML code as the basis for its Safari browser in 2001, and it currently powers the vast majority of web browser share. Forking the codebase will fracture the browser rendering space between WebKit, Gecko (which powers Firefox), Trident (Microsoft’s rendering engine), and now, of course, Blink.

That’s a concern for web developers who have to build websites that render properly in all browsers, but Google says that won’t be a problem:

“In the short term, Blink will bring little change for web developers,” Google engineer Adam Barth wrote.

The question, of course, is the long term.

Interestingly, Opera has very swiftly said that it would use the new Google fork of WebKit for the new Opera rendering engine.

(Oh, and if you’re wondering what the dongle joke is about, here’s the answer.)

Samsung already builds Android hardware — now it wants to help build the underlying software running on it.

The South Korean manufacturer’s teaming up with Mozilla to make Servo, a web browser engine for ARM Android devices built with Mozilla’s Rust programming language.

While a Servo-based browser could help Mozilla one day take on Chrome, Servo right now seems focused on WebKit, the browser engine that drives Chrome, Safari, the BlackBerry 10 browser, and, eventually, Opera. (It’s worth noting that Mozilla doesn’t explicitly mention Webkit in the announcement post.)

The project obviously means a lot to Mozilla, seeing that the company makes, well, web browsers. But what about Samsung?

The answer is actually pretty simple: Servo takes advantage of so-called parallel hardware (i.e., devices with multiple cores), which, despite their power, don’t actually run apps any faster due to power constraints. Samsung obviously sees an opportunity in fixing that problem by making software that’s more optimized for its devices, which is why its deal with Mozilla makes so much sense.

A lot of this also ties into Samsung’s ongoing efforts to distance itself from Google. If Samsung can make a native web browser that takes full advantage of its hardware — well, that’s a big win.

Obviously, all of this is in its early stages, but Mozilla says that it and Samsung “will be increasingly looking at opportunities on mobile platforms.” Take from that what you will.

Photo: Devindra Hardawar/VentureBeat

July 9-10, 2013
San Francisco, CA

Tickets On Sale Now

I’m not sure this is what they meant when they said design is now mobile first. Google has taken the widely loved new look in its iPhone and iPad app straight to the web — the mobile web, that is.

The new look is clean and simple, and much more usable — in my humble opinion — than Gmail’s web app for mail.

But this isn’t just my opinion of it:

“[It's] much more usable now,” engineering student Filipe Werneck said. “And I must say that the redesign of the web app is very welcome and brings color consistency between desktop and mobile.”

But you can’t please everyone, apparently.

Windows Phone is not included in the release, probably because the Windows Phone browser is based on the Trident rendering engine, and just about everyone else (Android, iOS, Opera) is on or moving toward the Webkit rendering engine. But it means that Windows Phone users are forced to use WAP to access Gmail in a browser on their devices — a very 1997 experience.

Other complaints include that Microsoft Exchange support was dropped (old news), and yet another responder to Google’s announcement post said, “Yeah, but the Contacts page still looks like it was developed by Fred Flintstone.”

Visit gmail.com in a mobile browser on your iPhone, Android smartphone, BlackBerry, or even a Kindle to check it out.

photo credit: opacity via photopin cc

Earlier this month, Opera decided to use WebKit as its rendering browser engine and V8 as its JavaScript engine. Unfortunately for around 91 people, that means the browser maker no longer requires their particular skills.

In its Q4 2012 financials, Opera stated, “At the end of 4Q12, the company had 931 full-time employees and equivalents. … Excluding employees associated with the organizational restructuring, the company had 840 full-time employees and equivalents at the end of 4Q12.” Or, in simpler terms, 91 folks got the boot.

WebKit is the open-source software behind a few other modern browsers you may know — Chrome, Safari. In its attempt to keep up with those fast-moving Joneses, Opera had to let go of its own rendering engine, Presto.

“It makes more sense to have our experts working with the open source communities to further improve WebKit and Chromium rather than developing our own rendering engine further,” said Opera chief technical officer Håkon Wium Lie.

“Opera will contribute to the WebKit and Chromium projects, and we have already submitted our first set of patches to improve multi-column layout.”

While some developers were sacked in the switch, others working on Presto chose to leave of their own accord when their skill sets and job descriptions became less than useful to the company.

The company also just shipped Ice, a new mobile browser for iOS and Android — again, WebKit-based.

With around a 2-percent share of all web traffic, the small company is clearly hoping these strides forward will help it keep pace with competitors and remain in the browser game for a little while longer.

July 9-10, 2013
San Francisco, CA

Tickets On Sale Now

If mobile browser developer SkyFire has its way, its new SkyFire 2.0 browser will finally give iPhone users access to the wealth of Flash video on the web.

The company has submitted its new browser to the App Store, and it seems confidant that Apple will approve it. SkyFire’s cloud-computing technology allows the browser to translate Flash videos in real-time to Apple-approved HTML5 standards. The company says it adheres to all of Apple’s video and browser guidelines — including the use of a WebKit browser core and H.264 adaptive video streaming.

The new iPhone browser is a follow-up to the Android version of SkyFire 2.0, which also brought Flash support to that platform before it was officially supported.

SkyFire 2.0 also makes its Flash video streaming very efficient. The browser compresses video data by about 75 percent on average — making it easier to stream videos without buffering, and saving precious battery life in the process. SkyFire says the increased efficiency addresses concerns Apple CEO Steve Jobs raised in his open letter about Flash on mobile devices — particularly, his worry about its impact on battery life.

There’s always the chance that Apple would reject the browser, but clearly SkyFire went to great pains to follow its rigid guidelines. And since Apple already approved the Opera Mini 5 web browser — which doesn’t follow all the company’s rules, since it’s not using the WebKit browser framework — there would be little reason for rejecting SkyFire 2.0.

July 9-10, 2013
San Francisco, CA

Tickets On Sale Now

Today at the Mobile World Congress in Barcelona, BlackBerry maker Research In Motion made several announcements that showed the company isn’t ready to give up its smartphone dominance in the US just yet.

RIM announced a new WebKit-based web browser that would compete directly with iPhone’s mobile Safari and Android’s web browser (both also use WebKit). Co-CEO Mike Lazaridis emphasized network efficiency in his keynote, and said that the new BlackBerry browser would make efficiency a priority as well. So we can expect the browser to be fast. Lazaridis also demonstrated that the new browser scored 100 percent on the Acid 3 test — which shows that it’s compliant with known web standards. He went on to say that the browser will hit BlackBerrys sometime this year.

As a traditionally e-mail-focused device, RIM has waited too long to improve the BlackBerry’s web browsing experience. A better browser would be key for the next iteration of its Storm smartphone — a direct competitor to other touchscreen smartphones — and will bring the rest of the BlackBerry line to the modern age of mobile web browsing.

Lazaridis also pushed “SuperApps” — which appears to be RIM’s spin on making its existing BlackBerry applications more functional via extensions and other applications. He showed off an extension that allowed BlackBerry users to tweet from their inbox, as well as an eBay app that syncs with your calendar and sends alerts to the inbox. We can expect further extensions for the inbox in the future, along with similar integration with other applications.

Finally, Lazaridis announced a free version of BlackBerry Enterprise Server Express — a simplified version of the BES server that many large businesses and institutions run to support BlackBerry e-mail. The BES Express server will run on existing mail servers and will come with free server and client licenses. A higher-end version will offer social network and video features.

In short, RIM didn’t announce anything truly revolutionary, but the unveiling of its WebKit browser is a sign that the company is keenly aware of the progress its mobile competitors are making.

[Photo via CrackBerry]