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.

I thought one of the reasons Opera announced support for WebKit was because they could not use their own rendering engine on the iPhone anyway. With their support for Blink going forward, and their statements about contributing to Webkit, and their need to be on the iPhone and therefore use JSC as well, what does this all mean for Opera?

The only thing that you can assume is Apple technology is the software, and this is what I pointed out in my comment. The software from Apple is "awful", its buggy, insecure, and just terrible. They took unix and they made it worst, the took Linux and made it more insecure and more buggy.

Apple took BSD, Mach and created Darwin. BSD cores run on the top of single Mach core. It's fully certified UNIX-like OS. Apple never used Linux.

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".

I plain forgot to include Apple forking KHTML. To me, and everyone else it seems, it is common knowledge where the code came from, but I agree I should have been more specific.

As for the rest, Apple is no saint, but Google is not a magical company that gives everything away for free with no politics or agenda either. And I submit that many of Google's moves lately have been directly aimed at harming competitors from Apple (with Android, this Blink / WebKit split, their video codec, their purchase of Motorola,) to others like Facebook and Evernote.

You'll notice that I'm not claiming Google Sainthood. I'm simply pointing out that the arguments you used against Google aren't good ones. You keep making the video codec thing sound like some dastardly plot against Apple. Do you realize that any browser shipping with Apple beloved codec has to pay a royalty to MPEG LA? Yeah, Google, Apple and MS can afford that, but Firefox, Dolphin, Opera and the likes surely can't. I applaud Google for trying to break those chains. As for the Motorola purchase, with the patent offensive that Android was facing, did they really have a choice? Google didn't patent their technologies early on. After Jobs decided to go nuclear on them, they desperately needed some offense. I think the whole patent war is harmful, but when your competitors attack, you have to fight back. Now I can understand frustration with some of the other moves that Google has made lately, but lets save that for another discussion as we're getting pretty far off topic here.

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?

I wouldn't disagree about the last two items, but the Java HotSpot is one of the best VM's out there, regarding performance.

But JavaScript is very different from Java, and depends on other techniques. It would be unlikely if a fast Java VM would be suitable as a fast JavaScript engine without major rewritting and new optimizations.

When Microsoft built its new Javascript engine for IE9, they were asked why they didn't build it on top of the new Dynamic Language Runtime (API framework for dynamic languages like Python on the .NET CLR) and the answer was that while the DLR is pretty fast, it's a generic runtime and unlikely to be as fast as a specialized Javascript runtime.

I thought one of the reasons Opera announced support for WebKit was because they could not use their own rendering engine on the iPhone anyway. With their support for Blink going forward, and their statements about contributing to Webkit, and their need to be on the iPhone and therefore use JSC as well, what does this all mean for Opera?

I don't think this was the reason. Opera had always the best browser features, but it lacked compatibility.

If someone dropped Opera it was because the webpage, game, webmail, banking login, app or whatever you used had bugs or didn't work at all with Opera. Not because of Opera fault, as their browser is standard compliant, but because websites are not coded for being standard compliant. Opera tried to push standards for many years, and I actually also thought that slowly web designers and developers would be "better" trying to have standard code that works everywhere. Instead, where once they coded for IE, now they code for Webkit, instead of coding once and it should work for decades and everywhere, they code for IE, now for Webkit and tomorrow for something else just because that is what's popular in the moment.

With Webkit being almost everywhere in the mobile space and with web designers now even coding webkit for desktops, I think all expectations of Opera to see a standard compliance Internet where shattered. There was no point in keeping trying to push their 1% presto share worldwide. And in the last years I think Opera mainly made their incomes from mobile alone and we're going to lose that market share once Chrome came into play in Android and every mobile websites was made for webkit. They had no choice but become "webkit".

Opera did not wen´t webkit because of Apple, you have it wrong. It went for Android, and the fact that once Google announced Blink, Opera jumped into Blink right away proves this. I tend to also see a world of Android powered devices in a short future, so Apple, even when they are relevant today are dropping shares so fast that they will lose their tablet share probably this years as well. Then it will be Android that will power most mobile and tablets. Is that good? I don't know, I prefer more split markets but I think this is where Opera is pushing. Also, if Opera can show the same website exactly the same as Chrome does, there is no point in using Chrome in the first place right? This is at least what Opera users or adopters will consider, because to be honest Chrome renders websites fast, and great, but their GUI is awful, spell checking is terrible, they just recently added a visual zoom indicator and they still miss so many features that make it the underdog in terms of browser features.

...Do you realize that any browser shipping with Apple beloved codec has to pay a royalty to MPEG LA? Yeah, Google, Apple and MS can afford that, but Firefox, Dolphin, Opera and the likes surely can't. I applaud Google for trying to break those chains.... as we're getting pretty far off topic here.

Actually, while technically correct, this is incorrect. All these browsers need do is enable the native support in the OS, which both Microsoft and Apple offer in in their respective OSs and directly link to the hardware support. No browser out there has to implement h264 CODECs in their software. While this may not be the case on Linux, again, there are open source h264 implementations out there that someone can install, and the browsers on Linux can take advantage of, or the browsers can be written to allow the hardware to implement the decoding (and then the burden is on the silicon maker).

At the same time, since WebM was initially introduced, it has become known that it infringes on the h264 patents, and Google is now paying to the MPEG-LA consortium for it, so for what it's worth the same issues apply with WebM.

Lastly, h264 is not Apple's beloved CODEC. It is a beloved CODEC of the industry at large, due to its widespread support, high quality compression, and widespread support in hardware.

I thought one of the reasons Opera announced support for WebKit was because they could not use their own rendering engine on the iPhone anyway. With their support for Blink going forward, and their statements about contributing to Webkit, and their need to be on the iPhone and therefore use JSC as well, what does this all mean for Opera?

I don't think this was the reason. Opera had always the best browser features, but it lacked compatibility.

You didn't listen to what I asked, and you obviously didn't pay attention to what Opera stated.

They said, PUBLICLY, that they wanted to bring a browser to iOS and could not use their rendering engine nor JS at all (these are Apple's policies, like it or not). Since they could not bring it to iOS, they might as well contribute to the engine they are being forced to use.

Could someone who actually understands questions and has knowledge of the situation contribute an insightful comment? I certainly can't expect it from nibb... (even though you'd think form his name he has some knowledge of Interface Builder design, if he only dropped a b)

I thought one of the reasons Opera announced support for WebKit was because they could not use their own rendering engine on the iPhone anyway. With their support for Blink going forward, and their statements about contributing to Webkit, and their need to be on the iPhone and therefore use JSC as well, what does this all mean for Opera?

I don't think this was the reason. Opera had always the best browser features, but it lacked compatibility.

You didn't listen to what I asked, and you obviously didn't pay attention to what Opera stated.

They said, PUBLICLY, that they wanted to bring a browser to iOS and could not use their rendering engine nor JS at all (these are Apple's policies, like it or not). Since they could not bring it to iOS, they might as well contribute to the engine they are being forced to use.

Could someone who actually understands questions and has knowledge of the situation contribute an insightful comment? I certainly can't expect it from nibb... (even though you'd think form his name he has some knowledge of Interface Builder design, if he only dropped a b)

What other answer you need. It is clear that Opera is going with Blink because of Android, otherwise if iOS was so important to them they would have stayed with Webkit.

What they said in public does not matter, the fact they could not use their engine on iOS makes things worst, one more reason to jump into bed with Google+Android and leave Apple out.

This is a public forum, so anyone can comment, if this is not what you want, then pay a consultant to answer your questions in private. Otherwise live with the fact this website is a public website and everyone can comment. Not sure what answer you want when Opera switched to Blink hours after it was announced, which means they knew this before Google made it public.

I thought one of the reasons Opera announced support for WebKit was because they could not use their own rendering engine on the iPhone anyway. With their support for Blink going forward, and their statements about contributing to Webkit, and their need to be on the iPhone and therefore use JSC as well, what does this all mean for Opera?

I don't think this was the reason. Opera had always the best browser features, but it lacked compatibility.

You didn't listen to what I asked, and you obviously didn't pay attention to what Opera stated.

They said, PUBLICLY, that they wanted to bring a browser to iOS and could not use their rendering engine nor JS at all (these are Apple's policies, like it or not). Since they could not bring it to iOS, they might as well contribute to the engine they are being forced to use.

Could someone who actually understands questions and has knowledge of the situation contribute an insightful comment? I certainly can't expect it from nibb... (even though you'd think form his name he has some knowledge of Interface Builder design, if he only dropped a b)

What other answer you need. It is clear that Opera is going with Blink because of Android, otherwise if iOS was so important to them they would have stayed with Webkit.

What they said in public does not matter, the fact they could not use their engine on iOS makes things worst, one more reason to jump into bed with Google+Android and leave Apple out.

This is a public forum, so anyone can comment, if this is not what you want, then pay a consultant to answer your questions in private. Otherwise live with the fact this website is a public website and everyone can comment. Not sure what answer you want when Opera switched to Blink hours after it was announced, which means they knew this before Google made it public.

My question still stands. Could someone who understands the topic (or has inside knowledge at Opera) please let us know if in the pursuit of the browser they are putting on iOS (Announced LONG after they knew about Blink) they are going to be contributing to both Blink and Webkit, or whether they are going to be putting their enhancements on Blink and then managing the porting to Webkit, or whether they will put them on Blink, make recommendations to Webkit and hope they make it there? They indicated a browser on iOS is important to their future, and that they want to focus on the application layer and not necessarily the rendering engine, so it would seem odd for them to have to devote resources to both of these rendering engines now...

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.

I've SWAGged elsewhere in this thread that maintaining parity in the race for a competent rendering engine costs perhaps $10–$20 million per year.

(Better estimates VERY WELCOME. I note that Opera claimed they'd save be able to release 90 engineers by going to WebKit, and that the Mozilla Co apparently has some $160million of revenues, as justification for the SWAG.)

I'd appreciate knowing what “open source browsers” can afford to have their own rendering engines at this level of expense, but cannot afford what I see as approximately $6.5million maximum license fees for h.264 that'd be used WITH that costly rendering engine.

Since VP8 advocates—likely many of them, the same ones who are approving the fork of Webkit so that Google can advance it in the way that Google attaches highest priority to—first asserted this meme about economics, and since you won't find a lawyer on the planet willing to vouchsafe for VP8 actually being available for any use in the face of Nokia's strenuous patent assertions, I'm curious why this is not just Google asserting its priorities — how this is more than just propaganda that fits whatever situation Google happens to find itself in at any moment, apparently trusting that nobody remembers its arguments of just a few months earlier.

So again: Apple is bad for proposing a video codec that is cost-effective in the face of real-world web economics, even though it requires licensing, and Google is good for forking perhaps the most successful open-source project for the web, while proposing “free” technologies that actually aren't?

I thought one of the reasons Opera announced support for WebKit was because they could not use their own rendering engine on the iPhone anyway. With their support for Blink going forward, and their statements about contributing to Webkit, and their need to be on the iPhone and therefore use JSC as well, what does this all mean for Opera?

I don't think this was the reason. Opera had always the best browser features, but it lacked compatibility.

You didn't listen to what I asked, and you obviously didn't pay attention to what Opera stated.

They said, PUBLICLY, that they wanted to bring a browser to iOS and could not use their rendering engine nor JS at all (these are Apple's policies, like it or not). Since they could not bring it to iOS, they might as well contribute to the engine they are being forced to use.

Could someone who actually understands questions and has knowledge of the situation contribute an insightful comment? I certainly can't expect it from nibb... (even though you'd think form his name he has some knowledge of Interface Builder design, if he only dropped a b)

What other answer you need. It is clear that Opera is going with Blink because of Android, otherwise if iOS was so important to them they would have stayed with Webkit.

What they said in public does not matter, the fact they could not use their engine on iOS makes things worst, one more reason to jump into bed with Google+Android and leave Apple out.

This is a public forum, so anyone can comment, if this is not what you want, then pay a consultant to answer your questions in private. Otherwise live with the fact this website is a public website and everyone can comment. Not sure what answer you want when Opera switched to Blink hours after it was announced, which means they knew this before Google made it public.

My question still stands. Could someone who understands the topic (or has inside knowledge at Opera) please let us know if in the pursuit of the browser they are putting on iOS (Announced LONG after they knew about Blink) they are going to be contributing to both Blink and Webkit, or whether they are going to be putting their enhancements on Blink and then managing the porting to Webkit, or whether they will put them on Blink, make recommendations to Webkit and hope they make it there? They indicated a browser on iOS is important to their future, and that they want to focus on the application layer and not necessarily the rendering engine, so it would seem odd for them to have to devote resources to both of these rendering engines now...

You don't understand. On iOS Opera will do what Google did. Google just used their custom GUI on top of Safari backend with inferior JavaScript engine provided by Apple. Opera will also bring their own GUI as Apple don't allow 3rd party rendering engines. On other platforms Opera will use and develop Blink (actually Opera will build their browser using Chromium source code, what indirectly means using Blink and Opera will be contributing to this project). http://www.chromium.org/blink/developer ... heir-plan-

Anybody got a clue why Google insisted on creating V8 in the first place instead of optimizing JSC?

That said, I never noticed any practical speed difference between JSC and V8.

As a near full-time JavaScript developer that slaves away writing graphics-intensive and dom-manipulation-heavy apps, I can attest to the near-fatal speed increases that V8 brought to the table. I don't know if it's the way I program or if V8's speed manifests itself greater in some mediums than others, but it was staggering how much faster V8 could churn through our code than the competitors'.

You don't understand. On iOS Opera will do what Google did. Google just used their custom GUI on top of Safari backend with inferior JavaScript engine provided by Apple. Opera will also bring their own GUI as Apple don't allow 3rd party rendering engines. On other platforms Opera will use and develop Blink (actually Opera will build their browser using Chromium source code, what indirectly means using Blink and Opera will be contributing to this project). http://www.chromium.org/blink/developer ... heir-plan-

Yes, inferior because 3rd parties cannot use Nitro. Unsure how Nitro measures up again V8 on equivalent hardware/OS if they were able to.I'm still curious as to whether Opera will be trying to get Webkit to adopt features they put into Blink, and whether they will have any presence in Webkit, Bruce Lawson's PERSONAL blog and Chromium's blog non-withstanding (yes, I had read that on the 3rd, when it came out — I have yet to see any official announcement from Opera since they announced Webkit adoption).You'd think, with so much attention being paid right now to Blink (among web developers and the tech industry), and Opera publicly stating just a few weeks back their adoption of Webkit (at a point in time that they KNEW about Blink), why no public statement has come from them about this, and what it means?

As you can see, I DO understand what is going on, and I am still curious as to what Opera's OFFICIAL plans may be.

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'm trying to figure out why anyone is supposed to care. Most of the major browser's have already included support for SPDY, and it is being setup as a major candidate or at least a foundation of the next HTTP standard. Not only that, but it is completely optional. Google's services have it as an option, but don't require it by any means. I mean, you do realize SPDY is just a protocol right? How could they possibly use their huge influence to make the other players use SPDY, when they don't have nearly enough market share to force all users to use SPDY over their services?

If anything they have LESS power to force features down the internet's throat now that they are maintaining their own separate fork which has a relatively much smaller market share then the collective Webkit project they previously devoted a lot of engineering resources into.

You don't understand. On iOS Opera will do what Google did. Google just used their custom GUI on top of Safari backend with inferior JavaScript engine provided by Apple. Opera will also bring their own GUI as Apple don't allow 3rd party rendering engines. On other platforms Opera will use and develop Blink (actually Opera will build their browser using Chromium source code, what indirectly means using Blink and Opera will be contributing to this project). http://www.chromium.org/blink/developer ... heir-plan-

Yes, inferior because 3rd parties cannot use Nitro. Unsure how Nitro measures up again V8 on equivalent hardware/OS if they were able to.I'm still curious as to whether Opera will be trying to get Webkit to adopt features they put into Blink, and whether they will have any presence in Webkit, Bruce Lawson's PERSONAL blog and Chromium's blog non-withstanding (yes, I had read that on the 3rd, when it came out — I have yet to see any official announcement from Opera since they announced Webkit adoption).You'd think, with so much attention being paid right now to Blink (among web developers and the tech industry), and Opera publicly stating just a few weeks back their adoption of Webkit (at a point in time that they KNEW about Blink), why no public statement has come from them about this, and what it means?

As you can see, I DO understand what is going on, and I am still curious as to what Opera's OFFICIAL plans may be.

What exactly do you want them to say? You can't use your own Javascript engine on iOS and neither your own rendering engine, so its Webkit or nothing.

Apple blocks access to third party to their Nitro engine assuming security issues, but they also do not allow third party engines for browser, which means they have to use what they impose.

I don't know what kind of statement you need or want from Opera, because its not like Apple gives Opera or Chrome a choice on iOS, they they will run Webkit for iOS and Blink for the rest.

Opera does not need to make a statement on this because they will just follow Google, what you need to ask is how or what will Chrome on iOS run, and the same thing will do Opera, which in both cases is just put their GUI on top of what Apple allows. On the end this means the same thing, less choice for iOS users which are forced strictly to use Apple software. This can't possibly speak well about Apple software, which is so lousy that they need to implement tricks in order for their users to use them. Otherwise if they were so confident of their quality they would let uses choose.

No, neither Opera or Chrome will keep developing 2 engines, Webkit and Blink, I think this is what you ask, if they are going to keep developing a Webkit version for iOS and the answer is no. Apple is not that important to keep a separate team and developing only for iOS. So they will keep releasing for iOS the same version that exists today and thats it. They will just use their GUI and nothing more. Outside iOS it will be Blink which will be their main focus and development.

And when I mean they are not important I say this for 2 reasons. Why would Opera or Google keep resources developing for a company that makes it impossible to deliver their product on their iOS? Apple puts nothing but roadblocks for their browsers in their iOS so do not expect them to keep developing a separate version just for iOS. They will keep just what works now. And second, both Google and Opera know that iOS is losing market share in the mobile scene by the day, so this just puts more emphasis on point one.

No, neither Opera or Chrome will keep developing 2 engines, Webkit and Blink, I think this is what you ask, if they are going to keep developing a Webkit version for iOS and the answer is no. Apple is not that important to keep a separate team and developing only for iOS. So they will keep releasing for iOS the same version that exists today and thats it. They will just use their GUI and nothing more. Outside iOS it will be Blink which will be their main focus and development.

And when I mean they are not important I say this for 2 reasons. Why would Opera or Google keep resources developing for a company that makes it impossible to deliver their product on their iOS? Apple puts nothing but roadblocks for their browsers in their iOS so do not expect them to keep developing a separate version just for iOS. They will keep just what works now. And second, both Google and Opera know that iOS is losing market share in the mobile scene by the day, so this just puts more emphasis on point one.

Opera was fully aware of this, and Blink, when they made the Webkit announcement. Their press release had Webkit clearly announced, along with Chromium. Given that they knew about Blink, they could have waited a month and announced Blink adoption instead (I understand more people probably still know what Webkit is).Ice has not been released publicly yet, so I don't understand this "...so do not expect them to keep developing a separate version just for iOS. They will keep just what works now."

I've had it going back and forth with you nibb. You obviously hate Apple (it's alright, many people do, it's in fashion these days, Android crushing Apple, blah blah blah). I'll refrain from responding to your next response to me...

I'm still curious as to when and what Opera announces in respect to Blink, and how much influence they want to have on the Webkit fork in terms of code contributions vs. just suggestions, etc. Until Opera announces something publicly, all we really have to go on is what other people, like Chromium, Bruce Lawson, and yourself state.

No, neither Opera or Chrome will keep developing 2 engines, Webkit and Blink, I think this is what you ask, if they are going to keep developing a Webkit version for iOS and the answer is no. Apple is not that important to keep a separate team and developing only for iOS. So they will keep releasing for iOS the same version that exists today and thats it. They will just use their GUI and nothing more. Outside iOS it will be Blink which will be their main focus and development.

And when I mean they are not important I say this for 2 reasons. Why would Opera or Google keep resources developing for a company that makes it impossible to deliver their product on their iOS? Apple puts nothing but roadblocks for their browsers in their iOS so do not expect them to keep developing a separate version just for iOS. They will keep just what works now. And second, both Google and Opera know that iOS is losing market share in the mobile scene by the day, so this just puts more emphasis on point one.

Opera was fully aware of this, and Blink, when they made the Webkit announcement. Their press release had Webkit clearly announced, along with Chromium. Given that they knew about Blink, they could have waited a month and announced Blink adoption instead (I understand more people probably still know what Webkit is).Ice has not been released publicly yet, so I don't understand this "...so do not expect them to keep developing a separate version just for iOS. They will keep just what works now."

I've had it going back and forth with you nibb. You obviously hate Apple (it's alright, many people do, it's in fashion these days, Android crushing Apple, blah blah blah). I'll refrain from responding to your next response to me...

I'm still curious as to when and what Opera announces in respect to Blink, and how much influence they want to have on the Webkit fork in terms of code contributions vs. just suggestions, etc. Until Opera announces something publicly, all we really have to go on is what other people, like Chromium, Bruce Lawson, and yourself state.

But they did already, several times:

"“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. So yes, your understanding is correct,” an Opera spokesperson told TNW. This will affect both desktop and mobile versions of Opera the spokesperson further confirmed."

By the way I do not hate Apple, hate is a strong word, I do not hate anyone or anything, maybe the proper word would be I dislike Apple as a company. They make amazing hardware and devices and really know how to push technology to non tech savvy users in terms of simplicity and quality.

I just don't like their approach in terms of consumer using their product and their relationship with other companies. Its ok to be protective of your products, but it seems Apple is constantly in a defensive mode against everyone to the point it hurts their own products. And im not an Android or Google fanboy either, you can read my comments there that I have criticized Google, Microsoft and Apple as well praised all them before as well. There is no best product company or product, just what works best for everyone and Apple does not work for me as I need to fit products in terms of security, customization, etc to my own needs.

Opera did not knew about Blink months before, they just were aware of it probably some days before Google announced it, for the reason Google did not knew this months before either, it was a decision just made recently and it was announced shortly after. Even while Google probably decided this months before, they had to have at least one company on board before going this route, this company was Opera, which has a huge market in the mobile market. Also, Google clearly admits that they do not want to see a mobile world where only Webkit exists. This is a great move for the web. A terrible for Webkit and Apple as the market share Webkit has will drop in huge numbers in the following months.

Google agreed no such things. The degree of infringement and the financial terms of the settlement were not revealed, so at most you can state that they have settled their differences, with Google asserting the right to freely sublicense VP8.

I'm sure many readers will baulk at this, but as a Java developer who also uses Scala and even JRuby on the JVM, I was looking forward to a viable JS engine running on the JVM, all in a browser (Nashorn).

My somewhat absurd dream is to have a common VM (the JVM) in all browsers, allowing web developers to use the language of their choice, where we now have to use JS. I do like JS, and am not even against using it for backend duty where appropriate (NodeJS), but would just love to be able to use, say, Scala in the browser, or at least mix Scala libraries with Dart and JS all on the frontend, all playing nice with each other.

I know it's never going to happen. You guys might even down-vote this out of existence. But I can dream, can't I?

Nashorn [ˈnaːsˌhɔʁn]("nose horn") is German translation of 'rhinoceros', a play on words on Rhino, the name of a JavaScript engine implemented in Java and provided by Mozilla Foundation. The latter gets its name from the animal on the cover of the JavaScript book from O'Reilly Media.

No, neither Opera or Chrome will keep developing 2 engines, Webkit and Blink, I think this is what you ask, if they are going to keep developing a Webkit version for iOS and the answer is no. Apple is not that important to keep a separate team and developing only for iOS. So they will keep releasing for iOS the same version that exists today and thats it. They will just use their GUI and nothing more. Outside iOS it will be Blink which will be their main focus and development.

And when I mean they are not important I say this for 2 reasons. Why would Opera or Google keep resources developing for a company that makes it impossible to deliver their product on their iOS? Apple puts nothing but roadblocks for their browsers in their iOS so do not expect them to keep developing a separate version just for iOS. They will keep just what works now. And second, both Google and Opera know that iOS is losing market share in the mobile scene by the day, so this just puts more emphasis on point one.

Opera was fully aware of this, and Blink, when they made the Webkit announcement. Their press release had Webkit clearly announced, along with Chromium. Given that they knew about Blink, they could have waited a month and announced Blink adoption instead (I understand more people probably still know what Webkit is).Ice has not been released publicly yet, so I don't understand this "...so do not expect them to keep developing a separate version just for iOS. They will keep just what works now."

I've had it going back and forth with you nibb. You obviously hate Apple (it's alright, many people do, it's in fashion these days, Android crushing Apple, blah blah blah). I'll refrain from responding to your next response to me...

I'm still curious as to when and what Opera announces in respect to Blink, and how much influence they want to have on the Webkit fork in terms of code contributions vs. just suggestions, etc. Until Opera announces something publicly, all we really have to go on is what other people, like Chromium, Bruce Lawson, and yourself state.

If you read it carefully they say that it will be based on Chromium. At that time Chromium was using WebKit, so as Google Opera was supposed to contribute to WebKIt. It has changed, but this line is still true and was confirmed by Google and mr Lawson.

From original Opera announcement:.

Quote:

It's built using the open-source Chromium browser as one of its components.

I don't know what kind of evidence do you need and why are still questioning it.

I think you'll find that the H264 consortium was until recently doing everything they could to throw doubt on whether an open-source video codec was even legal in the US…Let's not rewrite history unless we have to ....

In that spirit:

The h.264 standard was created by MPEG, a group that included virtually EVERY company with video technology and an interest in distributing it. Work was done under the aegis of the UN's ITU and ISO, a world body of standards organizations (e.g., the ISO speed on virtually every camera of the world). Wikipedia says the first draft of the standard was completed about 10 years ago, and it has been public knowledge ever since. You could hardly ask for better breadth.

Individual contributors to the standard have all pledged to license the technology on FRAND terms. AFAICT, this worked extremely smoothly up until the last year. Most contributors to the standard had MPEG-LA (“Licensing Authority”), a legally independent group only in the business of being a storefront for IP, sign people up and handle all the paperwork. Individual companies, however, retain full rights over their patents, subject only to their FRAND commitment and various laws.

The only exceptions to this ho-hum it-just-works history that I've found, are two incidents relating to Google.

First, Google sued Microsoft for using parts of the standard that Google never pooled into MPEG-LA. In fact, several firms contributed patents but have made no attempt to license them; the difference is that the Google claim appeared after ten years of non-assertion. Google claimed fees that appear to be as much as a thousand times all the other patents' value, combined. As to the actual benefit of the Google patents, as I understand it, these patents, acquired with Motorola, are (primarily?) on interlaced video, a format that would be long gone except for the fact that implementers like to claim FULL h.264 compatibility.

The other incident involving h.264 is the recent announcement by Google that it had licensed re-distribution rights for 11 of the MPEG members' work from MPEG-LA, for use in VP8 (fee undisclosed). However, Nokia asserted that its commitment to license h.264 patents did NOT extend to license their specific patents in OTHER video standards. As of now, there is no resolution for Nokia's claim of right to forbid Google “forking” the h.264 standard by cherry-picking individual patents from it. On the other hand, Nokia has successfully sued over a range of patents, including a large settlement with Apple, so their claims are not just a typical patent troll's hot air.

The FUD you cite is perhaps the result of MPEG-LA's call for anybody who had patents that read on VP8, to please submit them, so easy licensing could obtain. This turns out not to have been FUD at all, as the 11 firms that did submit, were able to strike a deal with Google.

I would go a step further: h.264 has been known and understood and almost universally used for high-quality video encoding/decoding. Most of the world has been happy to accept the licensing terms and has implicitly acknowledged the validity of work done by all the major firms actually interested in video (including Motorola) over the past 20 years. I fully understand some people's concerns about possible licensing costs down the road, or principles demanding purity around licensed IP, but at this stage it seems pretty foolish to deny, as Google implicitly does, that they are magically not exposed to the licensing obligations that everybody else has found fair and reasonable for a decade.

This would all be rather insignificant to the browser questions except for the fact that Google is changing the terms on which it supports and asserts web standards — such as the de facto h.264. Interested people might look to the h.264 history — suing competitors over trivial patents that Google has promised to license on reasonable terms — in evaluating their motivations for yet another fork of a powerful web standard, likely in a way that'll make it harder for other developers, especially those open-source developers who depend on Webkit, whose interests they have claimed to defend.

I think the article ignores that it was Apple by itself that created Safari and WebKit in the first place

If by that you mean Apple forked KHTML, then yes, they created it in the first place.

These apple people

Anywho I think the biggest issue at hand is the fact that Apple does not really care about what other users of webkit think about them ripping it to shreds. A lot of the stuff Google is taking out of webkit are remnents from when Apple originally took over the project. That being said there are many pieces that are Apple specific code but have to stay in because it is core functionality. Apple could completely abandon webkit for webkit2, and if I'm not mistaken webkit2 to is more my way or the highway - even though its open source I am under the impression (though I could be wrong) that you can only do MP/sandboxing one way and only use JScore...

Apple has to make some very careful decisions with webkit without causing massive backlash. Google has it easy - they already stated everything will be standards based, and will not use blink to introduce incompatible browser specific tags like webkit does and mozilla has... I think this sounds quite nice to me

But we will find out more as time goes on. I think there are some people really wondering what Apple will do with webkit now... this is a concern - hell they could fork it as well and tell everyone else to piss off... and basically close off development.

Google agreed no such things. The degree of infringement and the financial terms of the settlement were not revealed, so at most you can state that they have settled their differences, with Google asserting the right to freely sublicense VP8.

Yes, and in other news from the world of law, insider traders agree to settle with the SEC for millions of dollars “just to get the allegations behind them,” neither admitting nor denying guilt.

When the SEC is involved, it is illegal for a sanctioned firm to go back and say they weren't really guilty; that's breaking their deal and they can be hauled straight into court. Likely, Google faces no such risk, but the MPEG-LA would be able to publish the terms of the deal — in which Google almost certainly paid firms that claimed patents over VP8.

So Google Irregulars® do the dirty work for them, claiming that a settlement isn't really a sign that Google admitted they were in a no-win situation. Why—what's in it for them to spout obviously spurious non-inferences—we never know.

Of course, Google's settlement did not include one vociferous party that was key to h.264, so the game goes on.

Anybody got a clue why Google insisted on creating V8 in the first place instead of optimizing JSC?

That said, I never noticed any practical speed difference between JSC and V8.

As a near full-time JavaScript developer that slaves away writing graphics-intensive and dom-manipulation-heavy apps, I can attest to the near-fatal speed increases that V8 brought to the table. I don't know if it's the way I program or if V8's speed manifests itself greater in some mediums than others, but it was staggering how much faster V8 could churn through our code than the competitors'.

I was not saying that both engines are absolutely equal speedwise. I just said that I never noticed a difference when browsing the web. Sure, I know the benchmarks showing that V8 is faster but benchmarks are designed to make speed differences more obvious by repeatedly executing a function many times.

Anyways: Way main point was that I don't understand why Google did not optimize JSC directly and instead made an alternative JS engine.

I think the article ignores that it was Apple by itself that created Safari and WebKit in the first place

If by that you mean Apple forked KHTML, then yes, they created it in the first place.

As a long time Apple user I'd like apologize for that statement up above. He is a mis-informed brethren and he speaks NOT for the cult! Anyone who has the ability to access wikipedia knows Apple didn't create Webkit and therefor could not have done any of it by themselves. Please don't turn this into an another example of "why Apple users think the company invented something it didn't."

I think the article ignores that it was Apple by itself that created Safari and WebKit in the first place

If by that you mean Apple forked KHTML, then yes, they created it in the first place.

As a long time Apple user I'd like apologize for that statement up above. He is a mis-informed brethren and he speaks NOT for the cult! Anyone who has the ability to access wikipedia knows Apple didn't create Webkit and therefor could not have done any of it by themselves. Please don't turn this into an another example of "why Apple users think the company invented something it didn't."

Heh. I say something unintentional incomplete, apologize, get called a liar for the apology, and then get apologized for. Best discussion thread ever.

You keep making the video codec thing sound like some dastardly plot against Apple. Do you realize that any browser shipping with Apple beloved codec has to pay a royalty to MPEG LA? Yeah, Google, Apple and MS can afford that, but Firefox, Dolphin, Opera and the likes surely can't. I applaud Google for trying to break those chains.

The whole idea that browsers need to implement playback routines themselves dates back to a time when operating systems did not have centralized APIs for media playback – at least not streamed ones (starting with animated GIFs and bundled Netscape plugins).No idea why that concept even survived the past 10 years. Heck, if it was my call, I'll even rip out image decoding from HTML engines and let the OS handle that.

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.

It seems like they need Firefox or IE to switch over to Webkit and fill the role.