Some projects I just don’t understand. And this is one of them.
There is a new project that was just announced: WebRTC in WebKit. The vendors behind it are Ericsson and Temasys (there are a few more, but they are of less relevance to us here).
The idea? There’s this browser engine called WebKit. It is open source. And it WAS important (emphasis on WAS). Having WebRTC in that project, logic suggests, is a good thing.
And while it is, why go to the length of doing that at all?
WebKit, then and now
WebKit was once a popular open source browser engine. Browser engine means it was used to render HTML and CSS into visible pages.
What made it popular were the two vendors that used it:
- Apple for their Safari browser
- Google for their Chrome browser
That all changed in April 2013, when Google announced a new project called Blink. The reason? Progress faster in browser innovation without the need to maintain integrity of Apple related code.
And just in a Blink of an eye, WebKit is now used just by Apple for Safari and no one else.
Apple, WebKit and WebRTC
Now that WebKit is rather synonymous with Apple and Safari, what’s the point in vendors other than Apple investing the time and effort of adding WebRTC into it? This goes right in the fact of the logic of browser vendors being the only important decision makers. To me, that’s like fighting windmills.
Let’s be frank here.
Apple is the most profitable company in the world.
They can easily invest the money, time and resources required to add WebRTC into WebKit.
If they choose to do so.
And if they decide not to, then who on earth can force them or entice them to make that decision?
Ericsson and WebRTC in WebKit
Ericsson. What do they need this for?
I’ve asked that same question about the OpenWebRTC initiative.
While I think I had good answers about OpenWebRTC for Ericsson, I am clueless here.
What do they expect to gain by this pet project? Making friends with Apple?
Temasys and WebRTC in WebKit
For Temasys that may well be the migration from Google’s WebRTC stack to Ericsson’s OpenWebRTC one.
They are a WebRTC PaaS vendor, with a touch of unbundling (their WebRTC plugin). Working on an open project where the words WebRTC, Apple and Temasys appear in the same sentence can lure VCs to invest money. As a startup, that has value.
On the other hand, can Temasys really spare the manpower and focus from their real offering towards this school project? Do they stand to gain anything besides the name Apple, and even that a long shot of sorts?
Getting WebRTC to work on iOS
If the point of this exercise is to get WebRTC to work for people who use iOS, then this train has left the station already.
- WebRTC is portable to iOS
- Vendors have been using WebRTC on iOS since 2012
- Adoption of WebRTC on iOS in 2014 has increased considerably
Granted, that adoption happens inside an app and not in the browser, but think about these facts:
- Most use cases today on mobile are app based anyway
- Until Apple decides to add WebRTC to Safari on iOS, no hooplah will help any company (be it Ericsson, Temasys or other) get WebRTC inside iOS’ Safari browser
To make a long story short, WebRTC in WebKit doesn’t help iOS developers.
Why is this important?
Unless there’s some secretive deal with Apple here – It isn’t important. And that’s the whole point of it.
There are many projects using WebRTC, adopting it, trying to get in the limelight of it. Similar to the branding of projects and products around IOT or Big Data. It gains attention.
If what you do is trying to build stuff with WebRTC, better know what matters. And what doesn’t.
Need to know where WebRTC is available? Download this free WebRTC Device Cheat Sheet.
2 possible motives – all speculation :
1) E/// want a codebase that isn’t Google’s – they need to feel like a player in webRTC. Bowser is a failure, this is a 3rd attempt. Temasys have had their fingers burnt trying to keep up with the changes in the large and unwieldy webrtc.org codebase that chromium uses. – so a marriage of convenience.
2) KHTML (the KDE browser) uses webkit too – They may be planning some sort of embeddable webrtc enabled browser component for linux devices – Think TVs, doorbells, entry-phones or Maemo-like phones.
Tim,
I guess you are correct, but at the end of it, both amount to very little. Not sure it is worth for either of the two parties involved.
some readings for you guys, since you did not do your homework.
native apps vs web app – wait … wrong debate. Most native apps use web view anyway
– http://developer.telerik.com/featured/what-is-a-hybrid-mobile-app/
– http://www.stevesouders.com/blog/2014/10/09/do-u-webview/
nobody uses webkit/webview – right…
– http://en.wikipedia.org/wiki/WebKit
— samsung phones
— nokia phones
— BB phones
— nintendo, playstation, …
— amazon kindle,
— most of the set up boxes (http://en.wikipedia.org/wiki/OpenTV)
— the majority of device with embedded display
chrome forked webkit into blink – or not (webcore is a subpart of webkit)
– http://en.wikipedia.org/wiki/Blink_(layout_engine)
– https://chromium.googlesource.com/external/Webkit/
Alex, somehow, I expected this 🙂
Using webview inside an app is nice, but it ends up using the browser renderer that the mobile OS vendor decided to place in his smartphone, which brings us back to… Apple.
I’d also suggest reading some other views re:mobile such as this one: http://www.mobilephonedevelopment.com/archives/2200
The jury is still out there for best way to implement apps. I haven’t made up my mind which way is better.
As for the list of “users”:
– Samsung phones. That would be their Bada ones, which are nowhere
– Nokia. Sure
– Blackberry. Yap
– Nintendo. Seriously?
– PlayStation. Got me there, but Sony has its hands full with XBox and Android competition anyway
– Amazon Kindle. That’s Android. When they decide to upgrade, it will be Blink and not WebKit
– Set top boxes. I understand I need to defuse this bomb, but would require a whole post. Expect this later this month
– Embedded displays. A lot of them are switching to Android anyway
And yes, while Blink is a fork of WebKit, do they share such resemblance after two years? If they had, then there would be no need for the WebRTC in WebKit initiative – you’d just need to merge the files and be done with it 🙂
Never did do my homework anyway.
As someone who has tried to use an embedded webview to support a webRTC call
I can tell you that it is not easy. The only webview that supports webRTC at the moment is the one in android 5 (which is a rare beast still) – and it is 10 versions behind the public chrome release – which means it barely interops with the chrome browser on the same device, let alone anything else. (Enough homework?)
I am happy with webkitRTCPeerConnection. Mostly.
I mostly don’t know how to react to that 😉
To reiterate what we said when we released OpenWebRTC: the WebRTC standard is better of with multiple independent implementations of the standard. This is true for the media plane (IETF) but also on the API side (W3C).
Sure, Mozilla has a different API implementation than Google Chrome, but Mozilla does not yet have a large enough footprint on the ever more important mobile platforms.
Also, I do not share Tsahi’s (arguably Google-centric view) that WebKit is no longer relevant after being forked in to Blink. Google leaving was to some extent negative for WebKit, but saying it is irrelevant is at least a few steps too far.
Stefan
Stefan,
Let’s face the truth. We live in a mobile duopoly. The only 2 players in mobile operating systems these days are Apple and Google. No one else comes close to being relevant. Not Firefox OS. Not Blackberry. Not Microsoft Windows Phone. Not Samsung Bada. Not Jolla. Only Apple and Google.
This translates to iOS and Android which translates to Safari and Chrome which then translates to WebKit and Blink.
Blink is relevant in the context of Android and Chrome. WebKit is relevant in the context of iOS, Safari, the iPhone and the iPad. As stated earlier, WebKit in the scope of Safari is controlled by Apple, which will do as it pleases with whatever goes in its devices.
How is WebKit important out of the scope of iOS in an extent that isn’t overshadowed by Apple’s WebKit and Google’s Blink? By saying that Nokia uses it?
You are almost making my point here 🙂 What you are potentially missing is that when/if Apple decides to add WebRTC to their port of WebKit, it will be largely based on the code that we are landing right now as it is generic for all ports of WebKit (WebCore).
@tim,
I realized I hadn’t answered your speculation, sorry about that.
Yes, webrtc.org code is … problematic to manage. Yes, when we first came out with the free plugin, we realized we were spending 80% of our time handling changes in libwebrtc against 20% in the plugin code. No, we did not get burnt, we automated everything nicely, as we are using the stack in several products, it was making a lot of sense. We are about to provide, likely for free, precompiled and pre tested webrtc libraries. You can see the public automatic builds there already:
http://my.cdash.org/index.php?project=libwebRTC&date=
You can see builds result for linux, mac, windows, 32b/64b, debug, release.
Far from burnt.
The homework comment was related to the post itself.
As for web view, the one on android is indeed pretty recent (4.3 if i recall correctly) and still need love. The one in safari is … older. We both agree that it is still too hard, and we plan to make it easier for developer to just use webview instead of having to maintain a full webrtc stack. Note that on android, however difficult it may be to use web view with webrtc support, it’s still easier than repurposing an existing webrtc stack. (kudos for the parrot demo, leveraging janus was a nice hack).
@tsahi,
In the meantime, less than one hour and a half ago, apple accepted yet another patch bringing webrtc to webkit 😉 Actions speaks more than words.
http://trac.webkit.org/changeset/182275
“Talk is cheap, show me the code”, Torvalds, Linus (2000-08-25).
Stefan, Alex,
Each is entitled his own opinion. My worry isn’t with you running off and building WebRTC into WebKit instead of letting Apple do the work. My worry is that you are defocusing yourselves from what can bring value (and revenue) to your companies.
For Ericsson that might not be an issue, but for Temasys…
I fail to understand the business case behind this, and you haven’t been able to explain it clear enough for me to understand. Feel free to see it as my own failing for being stupid.