You can even try it out now on Safari Technology Preview: https://webkit.org/blog/7627/safari-technology-preview-32/
This is absolutely huge. Many, many services that could once only be provided at a premium fee or by large to massive companies like Skype or Google can now be offered for free by small start-ups without having to worry about "this page was designed to be viewed in [preferred browser] version [foo] or higher" hassles.
Also, definitely worth trying out this AR.js demo if you're running the beta: https://freinbichler.me/apps/web-ar/
Always thought it was a little peculiar that the Media Capture APIs are tied to what is otherwise a very data/protocol-oriented spec.
Wish we could have had a camera feed in a canvas element on Mobile Safari a few years ago without having to wait for the entirety of WebRTC to be vetted. :P
---
And now, for my own unrelated Web API peeve:
Beyond service workers and all that jazz, I'm a little bummed out that the Pointer Events API isn't even listed on the Webkit Feature Status page: https://webkit.org/status/
It just seems like such a pleasant unification of all of the input-type APIs (mouse, touch, pen, hypothetical future peripherals...)
At least touch events have a "force" property with Apple Pencil input in the meantime. No tilt though.
Maybe next year :/
My phone, though an iPhone 6, seems to shut down Safari if I've been using other apps long enough. I can't imagine it staying alive long enough to torrent anything large.
[1] http://new.gafferongames.com/post/why_cant_i_send_udp_packet... / https://github.com/networkprotocol/netcode.io
In terms of replacing, the obvious ones (as mentioned) are applications like Hangouts, Skype, GoToMeeting, etc.
In terms of enabling, time will tell but I try to think about what kinda of applications were possible before but not practical, because of the need to get everyone to install something. Hopefully this will increase the competitiveness of web to apps.
One of the projects using WebRTC data channels right now is Threema Web to connect smartphone and browser across networks without trusting a server: https://github.com/threema-ch/threema-web (Disclaimer: I'm involved in development)
WebRTC can communicate on the near network without roundtrip to ISP uplink, so it can get high bandwidth in managed environments (industrial etc).
It is completely hostile to users. If I close a web page I expect everything related to that web page to stop. Immediately. I don't expect there to be lingering background threads consuming battery life, network data and disk storage. And in Chrome you can only discover service workers by enabling a Debug mode and memorising a specific URL. Exactly how does a non-developer figure out what is going on ?
If Apple had any sense they would ban service workers and instead propose use case specific, tightly focused and managed APIs that focus on security and battery life first.
Also just a hint at a future where Botnets are running in your browser:
https://sakurity.com/blog/2016/12/10/serviceworker_botnet.ht...
Think about it this way... why do you have to download an entire app just to use a site? Don't like the notifications? Turn the off.
[1]: https://developer.apple.com/notifications/safari-push-notifi...
AFAIK Service workers are still under consideration, and nothing was announced.
quick question: i noticed that the camera isnt available on iOS 11 if you put a web-app capable page on to your homescreen. when you open the page in full screen, mediaDevices is undefined. is that just an iOS beta bug?
And when are they going to support MSE[1] in iOS Safari?
still some bugs maybe...
Using webrtc-adapter, all of my webrtc code instantly worked. Though it doesn't seem to want to connect to firefox peers.
It sometimes baffles me how apple is holding up progress on the web - and that they aren't criticized more for it.
Apple tends to take a little longer and suffer a little short-term pain to get it right in the long run.
[1] https://daringfireball.net/2017/05/safari_vs_chrome_on_the_m...
Sure, but it stops your site from working cross-browser.
Apple famously refused to allow Flash on iOS and in doing so single-handedly did more to push HTML5 standards than anyone else. I'll also point out that WebRTC has gone through numerous iterations to such a degree that a lot of WebRTC sites don't work with Safari 11 because they're using old non-standards-compliant variants of the API.
The typical HN web dev seems to load their site in Chrome, click around a bit, and call it a day. That's not healthy for standards or the web, but it sure is lazy and expedient for a very narrow group of people.
Chrome is not the web.
I remember having to integrate WebRTC through cordova (thank goodness somebody did it first) a couple years ago, and wondering why on earth Apple didn't find time or money for this. libwebrtc has been stable for years, it represents effectively no security risk, it performs well on all of their platforms. It truly boggles the mind.
ETA: If you look at the page counts of all the required specs (ECMAScript APIs, WebRTC protocol specs, underlying codec and protocol specs like Opus and RTC) it adds up to multiple thousands of pages. By comparison, the whole HTML5 spec (current WHATWG version) is 855 pages.
I would think the greatest barrier to integrating Opus would be getting Apple legal to agree not to sue other Opus adopters . Fair enough, but that's not five years worth of legal research. I would be gobsmacked if Apple bothered to write their own encoder or decoder just for WebKit, you don't need to read the bitstream format documentation.
And again, Apple has so much cash on hand that it takes the accountants five minutes to walk across a line on their balance sheets. Maybe the rest of you are busy, fine, but there are people who are qualified to put WebRTC in WebKit in the general public. Apple could send some money to the qualified people at Collabora, Igalia, or Ericsson Research (who I think have had WebRTC in Webkit since 2015).
All in all, it's absolutely bogus that Safari hasn't had WebRTC for at least two years already. You can make all the excuses you want, but this API drives more customer value than any ES6 feature. Nobody actually deploys ES6 on the web today, because it has forced browser vendors to completely reengineer their compilers, taking half a decade each, and as a result it has not been deployed long enough with decent performance to offer any value. WebRTC has been deployed for going on five years in valuable applications which are otherwise completely impossible on the web, half the other crap has no userbase, and offers questionable tangible value.
I guess it's also not an easy decision to "just include libwebrtc" into ones own application, since that's a giant dependency which pulls in lots of chromium code.
[1] https://daringfireball.net/2017/05/safari_vs_chrome_on_the_m...
I don't think that implementation of it is anywhere near as easy as you think.
That said, if you don't have the client in your browser, nobody gets to even try.
You may think that WebRTC is a pain, but try implementing video chat with getUserMedia and WebSockets, or a custom plugin, and get back to me on how much of a pain WebRTC is.
