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.

One plausible outcome for this is further consolidation among the WebKit variants. For those dead set on using V8, switching to Blink may be the best option. If sticking with WebKit is most important, reverting to JSC may be the only practical long-term solution.

Google was an important part of the WebKit project, and it was responsible for a significant part of the codebase's maintenance. The company's departure has left various parts of WebKit without any developers to look after them. Some of these, such as some parts of the integrated developer tools, are probably too important for Apple to abandon—even Safari uses them.

Others, however, may be culled—even if they're on track to become Web standards. For example, Google developed code to provide preliminary support for CSS Custom Properties (formerly known as CSS Variables). It was integrated into WebKit but only enabled in Chromium. That code now has nobody to maintain it, so Apple wants to remove it.

This move was immediately criticized by Web developer Jon Rimmer, who pointed out that the standard was being actively developed by the World Wide Web Consortium (W3C), was being implemented by Mozilla, and was fundamentally useful. The developer suggested that Apple had two options for dealing with Google's departure from the project: either by "cutting out [Google-developed] features and continuing at a reduced pace, or by stepping up yourselves to fill the gap."

Discussion of Apple's ability to fill the Google-sized gap in WebKit was swiftly shut down, but Rimmer's concern remains the elephant in the room. Removing the JavaScript layer is one thing; this was a piece of code that existed only to support Google's use of V8, and with JavaScriptCore now the sole WebKit engine, streamlining the code makes sense. Google, after all, is doing the same thing in Blink. But removing features headed toward standardization is another thing entirely.

If Apple doesn't address Rimmer's concerns, and if Blink appears to have stronger corporate backing and more development investment, one could see a future in which more projects switch to using Blink rather than WebKit. Similarly, Web developers could switch to Blink—with a substantial share of desktop usage and a growing share of mobile usage—and leave WebKit as second-best.

178 Reader Comments

i don't think webkit is going to be substantially hit only because the pace of internet spending on mobile iOS devices. i can't remember the statistics, but money spent online on mobile last holiday season was accelerating, with users on iOS devices spending far more than others. combined with the mobile usage stats in general, i can't see webkit's future is in doubt (even the article linked at the end put mobile safari ahead at 61% with a 6 point bump from the previous month).

just my thoughts, not a fanboi, an unlocked nexus did not kill my mother and rape my father. while i understand the developer concerns, i think money and usage will dictate these projects' survival (the ultimate statement of banality i know).

It's a very interesting problem. The other half of the story, which I haven't seen covered too much, is perhaps Google did this purposely to hurt Apple and WebKit. Given Google's other actions, such as advancing their video codec when the widely backed one Apple depended on was better, of spending a ton of money to buy Motorola, perhaps to make sure the lawsuits against Apple continued, I'm surprised this hasn't come up more.

Ignoring the political aspect, I suspect Apple will do what they want to do. I think the article ignores that it was Apple by itself that created Safari and WebKit in the first place. In the short term maybe this will let Apple get some performance gains as noted in the article. In the long term though WebKit may be badly hurt by a lack of non-Apple developers. As a Mac / iOS user that is not a happy prospect.

And finally on a pair of tongue in cheek notes: 1. Blink will be great until Google shuts it down. And 2. Though this wouldn't really happen, what's to stop Apple from joining the Blink open source project and mucking it up with their own code before taking their ball and going home?

It is amazing how quickly the discussion went from "We don't want to fragment the web" to "let's start removing features we don't/didn't develop ourselves". While I can understand that from a software planning point of view (this sort of huge instant transfer of a large chunk of code responsibility/maintenance is surely problematic), it's exactly these kind of "mini-features" that introduce fragmentation and require everyone to code for the lowest common denominator.

The other thing that is going pretty hard on this is that now these two camps can, especially on mobile, much more easily go their separate ways in "leveraging and promoting" their viewpoint without having to agree as much with the other. Specifically, I'm thinking of WebRTC and the VP8/h264 battle being waged, but I'm sure other people have issues near and dear to them too. I have a hard time seeing this being an especially good development...

I'm a huge supporter of Open Source and how it allows you to do awesome things like taking a web rendering engine and creating your own chrome (lowercase, not the Google product) and perhaps make the experience better for the end user. However, if you don't own the backend you're at the whims of those who do. Just like those who depended on twitter apis for their businesses.

And finally on a pair of tongue in cheek notes: 1. Blink will be great until Google shuts it down. And 2. Though this wouldn't really happen, what's to stop Apple from joining the Blink open source project and mucking it up with their own code before taking their ball and going home?

While this kind of "code vandalism" sounds like it would be very easy to do, it would never make it past a code review.

EDIT: I think I misread Ragashingo's use of the word "mucking". But why would Apple wish to contribute to Blink when they already have their own plans with WebKit 2?

It's a very interesting problem. The other half of the story, which I haven't seen covered too much, is perhaps Google did this purposely to hurt Apple and WebKit. Given Google's other actions, such as advancing their video codec when the widely backed one Apple depended on was better, of spending a ton of money to buy Motorola, perhaps to make sure the lawsuits against Apple continued, I'm surprised this hasn't come up more.

Ignoring the political aspect, I suspect Apple will do what they want to do. I think the article ignores that it was Apple by itself that created Safari and WebKit in the first place. In the short term maybe this will let Apple get some performance gains as noted in the article. In the long term though WebKit may be badly hurt by a lack of non-Apple developers. As a Mac / iOS user that is not a happy prospect.

And finally on a pair of tongue in cheek notes: 1. Blink will be great until Google shuts it down. And 2. Though this wouldn't really happen, what's to stop Apple from joining the Blink open source project and mucking it up with their own code before taking their ball and going home?

That's a pretty Apple centric spin. Reading what you wrote, I'd assume that Apple started WebKit from scratch, instead of forking it off a couple KDE projects.

Your statement statement about video codecs ignores the fact that the codec Apple depended on is heavily encumbered in patents making it financially impossible for open source browsers to implement it.

Finally, your statement on Motorola almost makes Apple sound more like an innocent victim in the patent war than a company that decided to go "nuclear".

Apple is heavily invested in Webkit, their iPhones depend on it. What I'm worried about is the lack of consistency I've seen in both branches, Apple is a visual company, they pioneered typography on computers, but in the latest Safari (6.0.3) the font-rendering engine is not fully communicated with the WebCore, so advanced features such as discretionary ligatures can't be turned on on Safari but work flawlessly on Chromium.

I know Apple is very cautious about new technology, but if they ignore new standards, Webkit will be another browser variant that web developers will have to test before deployment.

And finally on a pair of tongue in cheek notes: 1. Blink will be great until Google shuts it down. And 2. Though this wouldn't really happen, what's to stop Apple from joining the Blink open source project and mucking it up with their own code before taking their ball and going home?

While this kind of "code vandalism" sounds like it would be very easy to do, it would never make it past a code review.

I'm just waiting for Google adding features specific to their services, backed by frequent updates to Chrome. Then replace HTTP with SPDY for Google's services (while supporting a somewhat limited "compatible" standard web version) and Apple and MS will have to run after what Google does to the web.

I'm not saying that something like that will happen, but Google has enormous power here and has shown to be willing to use it (like with cutting off EAS and CalDAV support, which is aimed straight at MS).

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.

Man, that concept hurts. It hurts from a performance point of view, security POV, and a not-get-sued-by-Oracle POV. Who would actually want to use Nashorn?

My personal view is that no single rendering engine--open source or otherwise--should become so dominant that developers feel they can safely code to one implementation and cease demanding that browsers support standards in a consistent way. So in a way, I'm glad to see Google forking WebKit, though I recognize some (especially mobile) developers may be concerned.

There are now at least 4 major rendering engines with significant market share competing with each other on standards support and performance. This is healthy, in my view, as it makes it less likely that any one influential company (Microsoft, Mozilla, Google, or Apple) can go their own way and flout the standards process.

Even if most OSS projects adopt Blink and WebKit becomes just the de-facto "in-house" technology at Apple, Apple's market share is sufficient to ensure that developers will be supporting it for a long time to come.

If developers would stop using browser-specific extensions, none of this would be a problem.

I hardly think that V8 and JSC and even Nashorn are 'browser-specific extensions' that developers are using. They are browser specific innovations -- differentiation if you will. If all the browsers are identical, why on earth would I want to use yours? They have to provide advantages for their end users, advantages that aren't dependent on the developer. Your suggestion would solve some issues, but not nearly all of them.

I'm just waiting for Google adding features specific to their services, backed by frequent updates to Chrome. Then replace HTTP with SPDY for Google's services (while supporting a somewhat limited "compatible" standard web version) and Apple and MS will have to run after what Google does to the web.

I'm not saying that something like that will happen, but Google has enormous power here and has shown to be willing to use it (like with cutting off EAS and CalDAV support, which is aimed straight at MS).

I agree, but I think they would be overreaching in that case, if they aren't already.

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.

Man, that concept hurts. It hurts from a performance point of view, security POV, and a not-get-sued-by-Oracle POV. Who would actually want to use Nashorn?

On the contrary; HotSpot is a great JIT, with strong profiling support already. Nashorn would be really interesting from a performance PoV.

Discussion of Apple's ability to fill the Google-sized gap in WebKit was swiftly shut down[...]But removing features headed toward standardization is another thing entirely.

Way to skip out on actually reading the thread and seeing what the concerns were in favor of "omg Apple stomps cause politics!" Rimmer had valid concerns, but webkit-dev isn't the right mailing list to talk about politics, and the actual worries everyone else had were entirely practical and real. As Allan Jensen wrote:

Quote:

I think this discussion can be simplified a bit. I too is very sceptic about just removing features and would prefer we didn't remove features based on whether they could be a burden, but based on whether they actually are a burden or in the way of something specific we would like to do.

The problem with css variables though is that it is not currently being actively developed by anyone in webkit, and that no webkit port or bot have it enabled. This means that it is very likely to bitrot. Unless someone either starts working actively on it or a port decides to enable it on a bot, it is just guaranteed to stop working soon.

I am guessing as a minimum an interested third party could offer to setup a bot running Qt (the easiest port to run on standard hardware) with CSS variables enabled.

Without testing, CSS variables are better removed and reintroduced later when either the implementation in blink gets better and we can adopt a cleaner solution, the standard improves or Mozilla implements it. Whichever happens first.

This happens, and particularly when a project is open source it can be the sensible choice. If a section of code has no maintainer and no active use, how are regressions spotted? How does compatibility work? What happens when an issue is spotted, who deals with it when, well, no one is there to deal with it? This is totally standard stuff. And since Blink is just a fork, if they see any code they like in Blink they can just go take it themselves, and vice versa.

Someone needs to step up, or else they can follow the path Allan outlined and just wait for it to become fully standardized and done with a clean implementation. Sometimes being the Last Mover can be better then being first, and if the WebKit devs (including Apple) aren't interested in actually driving that particular standard then why not wait until it's done? Although in fact, it appears someone might very well step up:

Karen Shaeffer wrote:

Hi Niwa,I am willing to consider if it is practical for me to volunteer to maintain CSSvariables for the webkit project. I'll need a week to make an informed decision,because I already have a full plate. But I am very interested in webkit, and thisseems like a good time to step up to help the team. CSS variables does appear tobe a worthy feature to maintain. If the team is willing to let this sit for a week,then that'll give me time to consider the issue properly.

enjoy,Karen

Benjamin Poulain wrote:

If waiting a week means we get a new contributor, that sounds like a good deal

Cheers,Benjamin

So this entire tempest in a tea cup may amount to nothing anyway. What a scoop.

Kuro san wrote:

It is amazing how quickly the discussion went from "We don't want to fragment the web" to "let's start removing features we don't/didn't develop ourselves".

That doesn't appear to be the discussion. More like "OK a bunch of engineering resources and maintainers vanished, what do we do for stuff that doesn't have maintainers right now?"

It is amazing how quickly the discussion went from "We don't want to fragment the web" to "let's start removing features we don't/didn't develop ourselves". While I can understand that from a software planning point of view (this sort of huge instant transfer of a large chunk of code responsibility/maintenance is surely problematic), it's exactly these kind of "mini-features" that introduce fragmentation and require everyone to code for the lowest common denominator.

It sounds like the browsers were already fragmented on these "mini-features". It looks like many were dependent on build definitions, meaning that code never went into the release version of all the browsers anyway. In this case removing code that you never use isn't political, its the smart thing to do.

Plus, this is all under source control. If some one wants to contribute and maintain a feature that was cut back to the new branches (webkit or blink) they can without having to start from scratch.

If developers would stop using browser-specific extensions, none of this would be a problem.

I hardly think that V8 and JSC and even Nashorn are 'browser-specific extensions' that developers are using. They are browser specific innovations -- differentiation if you will. If all the browsers are identical, why on earth would I want to use yours? They have to provide advantages for their end users, advantages that aren't dependent on the developer. Your suggestion would solve some issues, but not nearly all of them.

Good points. The things you mention should differ in performance, memory usage, and configurability. They should *not* differ in how they logically operate, i.e., how they display pages, run scripts. JavaScript implementations should not differ in how they e.g. evaluate expressions. As long as standards are adhered to, users should not have any issues switching between browsing platforms.

It's like PDF files: they should look the same everywhere, but there are lots of PDF implementations that offer a wide variety of different features. When someone creates a PDF file, he never thinks "what sort of flags should I set to make this PDF file look good in FoxIt, MacOS, or Acrobat".

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.

Man, that concept hurts. It hurts from a performance point of view, security POV, and a not-get-sued-by-Oracle POV. Who would actually want to use Nashorn?

On the contrary; HotSpot is a great JIT, with strong profiling support already. Nashorn would be really interesting from a performance PoV.

Well, in that case, it'll be interesting to see what kind of numbers they end up producing.

I'm just waiting for Google adding features specific to their services, backed by frequent updates to Chrome. Then replace HTTP with SPDY for Google's services (while supporting a somewhat limited "compatible" standard web version) and Apple and MS will have to run after what Google does to the web.

I'm not saying that something like that will happen, but Google has enormous power here and has shown to be willing to use it (like with cutting off EAS and CalDAV support, which is aimed straight at MS).

I think the defense against this is that anyone else could fork Blink. That puts a constraint on how much they can abuse their control of the project. It doesn't eliminate it entirely, since maintaining the new fork has its own costs, but it does set a limit.

I don't know how decisions about which email address to use are made, but after reading a bunch of that webkit mailing list, it seems like the people with the @webkit.org are the most reasonable with respect to broad based community concerns and @apple.com the least -- even though many (all?) of the @webkit.org posters also work at apple.

----

The biggest loss in the breakup seems to be an actively maintained browser toolkit that other groups can use to sub in the one or two components they want to customize. For example, although Samsung can ultimately go with Blink or Webkit2, Oracle's Nashorn project probably won't fit into either project since they both look to be pulling out hooks for arbitrary javascript engines.

In the mobile sphere tiny Apple takes the largest share still, so devs are probably going to target those extensions first.

Then the issue for removing parts of the projects are handled kind-of democratically : there is a list of features where people voted to set priorities, no amount of whining can change the facts that those participating decided it wasn't the most important as to be accepted.

Then for me the biggest issue is the fact that HTML5 is a standard in the making for a decade and one wonders when we are going to finally see the standard.

It worried me to see a feature that I do believe is objectively important to the web being removed in a fairly casual fashion, with an intimation that it is unpopular or unimportant.

The point of the posting being replied to was to solicit input on a proposed change. After providing his own input on the matter, said web developer waxed political rather than leaving it at that.

It's easy to take this out of context, but discussions about features are a normal and often mundane part of open source development.

There's an interesting discussion to be had around the state of WebKit now that Google has forked it, but I think the example above was perhaps a better example of how not to participate in developer mailing list discussions.

Way to skip out on actually reading the thread and seeing what the concerns were in favor of "omg Apple stomps cause politics!" Rimmer had valid concerns, but webkit-dev isn't the right mailing list to talk about politics, and the actual worries everyone else had were entirely practical and real. As Allan Jensen wrote:

Quote:

I think this discussion can be simplified a bit. I too is very sceptic about just removing features and would prefer we didn't remove features based on whether they could be a burden, but based on whether they actually are a burden or in the way of something specific we would like to do.

Quite informative, it actually sounds sensible. It's usually better being late than being half-assed.

Going through the thread, the main concern was maintaining a feature which was enabled only for chromium. Morphing it in to some kind of insidious plan by apple to break standards is disingenuous. If you see through the replies, the standard isn't done yet and no one is left to maintain the code and they wanted to remove it now and once the standard is ratified they could easily bring back the code. Also apple devs were OK to keep it as long as someone maintains it or uses it in their port.

Also the ports which are using V8 are downstream and not in Webkit repository. None of the ports in webkit repository are using V8, which is clear if you read through the thread. Its untenable for Webkit developers to maintain JS bindings for out of tree ports, when removing those bindings simplifies and may give performance improvements to the project. you can argue if Webkit should take some time before they clean up and decide what they should do. But V8 is now going to be developed in tandem with Blink, i can't see how Webkit can be in sync with it.

As per comments from jon rimmer's post, though it had valid points, he went on about internal webkit politics adding nothing to the discussion. Opinions may vary and state of the project and its future is yet to be seen but that post was not a great example for such discussion.

Also its weird that a discussion about a experimental feature not yet completely standardized and was only being used by chromium port, suddenly makes Webkit a broken project. if you follow these things, discussions such as this are normal.

All you open source advocates crying yourselves to sleep over this fail to come to terms with that Chrome itself wasn't open source. The underlying technology of Webkit was, sure. But the actual Google Chrome browser (NOT Chromium, which is different) is closed source, only worked on by Google. Same with Safari.

The only big player that's soup-to-nuts open source is Firefox. Why doesn't everyone who's banging the Open Source Drumhead move over there, instead of arguing over two closed source clients? They could always use more developers with Mozilla.

This happens, and particularly when a project is open source it can be the sensible choice. If a section of code has no maintainer and no active use, how are regressions spotted? How does compatibility work? What happens when an issue is spotted, who deals with it when, well, no one is there to deal with it? This is totally standard stuff. And since Blink is just a fork, if they see any code they like in Blink they can just go take it themselves, and vice versa.

That's a worrying suggestion, because it implies that WebKit was accepting patches that didn't have corresponding tests, and hence no facility to spot regressions. Though even then, the tests have to be written at some point (unless Apple plans to never implement the feature at all), so why not now?

Quote:

Someone needs to step up, or else they can follow the path Allan outlined and just wait for it to become fully standardized and done with a clean implementation. Sometimes being the Last Mover can be better then being first, and if the WebKit devs (including Apple) aren't interested in actually driving that particular standard then why not wait until it's done? Although in fact, it appears someone might very well step up:

It's close to Last Call; I don't think that throwing the switch and including the feature in Safari is anything even close to "driving the standard". Earlier in its development, that would be a fair criticism, but unless there's some major last-minute change, that's not the case here.

Quote:

That doesn't appear to be the discussion. More like "OK a bunch of engineering resources and maintainers vanished, what do we do for stuff that doesn't have maintainers right now?"

For things like threaded HTML parsing (also Chromium-only, invasive, now unmaintained), I would agree. But for Web stuff that WebKit should end up supporting one way or another anyway?

Webkit was better when it had two competing companies contributing to it, as they balanced it out. I expect that both projects will regress when it comes to standards, or at least "standards" that their corporate contributors don't control.

I hardly think that V8 and JSC and even Nashorn are 'browser-specific extensions' that developers are using. They are browser specific innovations -- differentiation if you will. If all the browsers are identical, why on earth would I want to use yours?

How does sharing a JS engine result in identical browsers?Opera think they can differentiate by building their own UI and services on top of Chromium.

Basically every WebKit users (except Google, and the mentioned corner cases of Samsung *internally* using WebKit-GTK+V8 and Oracle with Nashorn) had absolutely no problems at all using JSC. Heck, even Google uses JSC in Google Earth via QtWebKit.