Google Forks WebKit As Blink Rendering Engine & Opera Will Also Use Blink

[menotu]

Posted by Michael Larabel on April 03, 2013

Google Forks WebKit As Blink Rendering Engine

Just earlier today was word that Mozilla is developing Servo, a new web-browser engine, and now comes a similar action out of Google. The search giant announced this afternoon they are forking the WebKit code-base for their Chrome/Chromium web-browser to form the "Blink" engine.

Adam Barth of Google basically says that because Chrome uses a different multi-process architecture compared to other WebKit-based web-browsers and multiple architectures, the situation has become rather complicated for Google developers.

Blink is to be an open-source rendering engine that will in time deviate from WebKit. Key goals with Blink include performance and simplicity. Google also believes this fork and more rendering engines will spur further innovations than most everyone relying upon WebKit. Google's routine fighting with Apple is also likely another reason for parting ways with upstream WebKit.

Initially this fork has internal architecture improvements and a simplified code-base, which already lightens the engine code-base by four and a half million lines of code.

More details on Google's Blink can be found from this Chromium blog post and the Blink project pag

http://www.phoronix.com/scan.php?page=news_item&px=MTM0MjM

===================

Bruce Lawson - Wednesday 3 April 2013 - opera emplyee

Hello Blink

It’s great to be able to talk publicly about Blink, the new engine that will power Opera’s browsers (disclosure: my employer, but this is a personal post) and Chrome henceforth. I know a lot of people worried that there would be less diversity on the Web once Opera Presto was retired, and the forking of WebKit into Blink restores that balance. Opera will be contributing to Blink in future.

[added 22:46 UK time] My boss, Lars Erik Bolstad, said on Opera’s behalf: “Our ambition is to contribute Opera’s browser engine expertise to Blink, ranging from the implementation of new web standards to improvements in existing code.”

My personal feeling (not representing my employer, wife, children or hamster) is that Blink has a lot of promise for the Web. Its architecture allows for greater speed – something that Opera and Google have long focused on. When browsers are fast and interoperable, using the web as a platform becomes more competitive against native app development. I also hope that it’s easier for smaller players and even individuals to contribute to the new rendering engine, with a more transparent gatekeeping process: “Our goal is for anyone to be able to participate, regardless of organizational affiliation.”

It’s also great that there will be no more vendor prefixes in Blink (only legacy ones inherited from WebKit that will be removed or dropped where possible). Vendor prefixes were like Morrissey’s solo career: on paper, a good idea – but in reality, a horrible mess.

So, hello Blink. With Presto remaining in the wild until 2020, and Firefox’s co-incidental announcement today that it’s collaborating with Samsung on two early stage projects to build a new rendering engine called Servo, diversity on the Web has never looked healthier, and interoperability never (er) interoperabler.

http://www.brucelawson.co.uk/2013/hello-blink/

[menotu]

Posted by Michael Larabel on April 04, 2013

WebKit Looks To Drop Google Code, V8, Skia

Following yesterday's announcement of Google forking the WebKit rendering engine to form "Blink" (also with the support of Opera), Apple developers working on WebKit are now looking to strip away Google/Chrome features from upstream WebKit.

Geoffrey Garen of Apple sparked a discussion this morning about "cleaning house" in WebKit with Google having already forked the code-base.

Among the items brought up in the discussion is stripping away the V8 JavaScript engine, the DOMFileSystem, WebLayer, and the Skia graphics library. (Though there is some outside opposition to dropping V8 from WebKit, so that feature might end up remaining.)

As part of the changes, they also want to begin adopting LLVM's libc++ for its C++ standard library

http://www.phoronix.com/scan.php?page=news_item&px=MTM0MzM

[menotu]

by Peter Bright - Apr 8, 2013

Does WebKit face a troubled future now that Google is gone?

Aggressive streamlining of Blink, WebKit causes headaches for all.

Now that Google is going its own way and developing its rendering engine independently of the WebKit project, both sides of the split are starting the work of removing all the things they don't actually need.

This is already causing some tensions among WebKit users and Web developers, as it could lead to the removal of technology that they use or technology that is in the process of being standardized. This is leading some to question whether Apple is willing or able to fill in the gaps that Google has left.

Since Google first released Chrome in 2008, WebCore, the part of WebKit that does the actual CSS and HTML processing, has had to serve two masters. The major contributors to the project, and the contributors with the most widely used browsers, were Apple and Google.

While both used WebCore, the two companies did a lot of things very differently. They used different JavaScript engines (JavaScriptCore [JSC] for Apple, V8 for Google). They adopted different approaches to handling multiple processes and sandboxing. They used different options when compiling the software, too, so their browsers actually had different HTML and CSS features.

The WebCore codebase had to accommodate all this complexity. JavaScript, for example, couldn't be integrated too tightly with the code that handles the DOM (the standard API for manipulating HTML pages from JavaScript), because there was an intermediary layer to ensure that JSC and V8 could be swapped in and out.

Google said that the decision to fork was driven by engineering concerns and that forking would enable faster development by both sides. That work is already under way, and both teams are now preparing to rip all these unnecessary bits out.

Right now, it looks like Google has it easier. So far, only Google and Opera are planning to use Blink, and Opera intends to track Chromium (the open source project that contains the bulk of Chrome's code) and Blink anyway, so it won't diverge too substantially from either. This means that Google has a fairly free hand to turn features that were optional in WebCore into ones that are permanent in Blink if Chrome uses them, or eliminate them entirely if it doesn't.

Apple's position is much trickier, because many other projects use WebKit, and no one person knows which features are demanded by which projects. Apple also wants to remove the JavaScript layers and just bake in the use of JSC, but some WebKit-derived projects may depend on them.

Samsung, for example, is using WebKit with V8. But with Google's fork decision, there's now nobody maintaining the code that glues V8 to WebCore. The route that Apple wants to take is to purge this stuff and leave it up to third-party projects to maintain their variants themselves. This task is likely to become harder as Cupertino increases the integration between JSC and WebCore.

Oracle is working on a similar project: a version of WebKit with its own JavaScript engine, "Nashorn," that's based on the Java virtual machine. This takes advantage of the current JavaScript abstractions, so it's likely to be made more complicated as Apple removes them.

http://arstechnica.com/information-technology/2013/04/does-webkit-face-a-troubled-future-now-that-google-is-gone/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+arstechnica%2Findex+%28Ars+Technica+-+All+content%29