It seems weird to focus so much on es2015 features, when so many of them are polyfillable (not optimal, sure, but still) when there is such uneven support for DOM (and related browser) API features in safari.
I mean, where are service workers? Give me a nice, cross-platform way to handle offline-first and I'll be happy. But hey, it isn't like there's some kind of browser monopoly on iOS or anything, like there was in windows.
Safari 11 supports WebRTC, Media Capture API, WebAssembly, WebCrypto API, drag-and-drop, and other interesting new features. If a crippled browser is their goal, they're doing quite an awful job of it.
http://caniuse.com/#feat=push-api is the interesting notifications API, which allows notifying a user (with their permission) even when the app isn't open. Neither API is supported on iOS Safari, and desktop Safari only supports notifications while the app is open.
The irony is that the only apps I could install on my iPhone 1 were javascript-powered html fragments. They launched with no app store or 3rd party binaries at all, and everything was to be done via js.
Now when we are super close to really supporting progressive web apps, apple is holding back (potentially to protect that golden calf of an app store).
I'm pretty sure Safari's features are intentionally crippled to keep their app ecosystem safe. See: web notifications.
I’m pretty sure you'd be wrong. Apple announced that it's paid over $70 billion to app developers since the App Store became a thing in 2008 at today's WWDC keynote. This is the 30% Apple pays developers; so we're talking about $233 billion in gross transactions in less than 10 years.
I think that's a shortsighted way to look at it. The iPhone is as successful as it is because of the perception of exclusivity - the best, newest apps will always be on iPhone first. Whether they are free or cost $100 each doesn't really matter that much - it still means Apple is the premier mobile device bar none.
If they enabled more progressive webapp features, we'd start to see a lot more cross platform webapps. That would not be in Apple's interest.
Apple sure is putting in a lot of effort into ES5 performance for a platform that they’re supposedly crippling, not to mention smoking Chrome and Firefox in the process: https://webkit.org/blog/7536/jsc-loves-es6/
The iPhone is as successful as it is because of the perception of exclusivity - the best, newest apps will always be on iPhone first.
That argument might have worked in back in the day when the iPhone was only available on AT&T but not in a world where the iPhone is available to more people than it ever has been before.
The total marketshare of Android is around 2 billion, but that's the total of Samsung, Motorola, HTC, LG, etc. None of them have individually sold a billion Android phones themselves.
If they enabled more progressive webapp features, we'd start to see a lot more cross platform webapps. That would not be in Apple's interest.
Do you think Apple cares more about selling a $700 iPhone or a 99¢ app? They have over a million native apps for iOS; what keeps that ecosystem strong is how Apple is able to innovate each year on new features for the iPhone, iPad and iOS, not by restricting what web apps can do.
The most compelling features are things web apps aren't very good at anyway. I seriously doubt Tim Cook is losing sleep worrying about Service Workers and the like.
People said the same thing about WebRTC and how it would compete with FaceTime. And now we have WebRTC in the new versions of macOS and iOS, so it's time to create reasons why other web features aren't there.
Web apps have made a lot of progress but for the average user in a developed country, the user experience pales in comparison to native apps.
They dont want to deal with potentional problems (like battery drain) of the web platform.
They can ignore it exactly because of their appstore and aura of exellence.
But in real world i know so many people who dont have single app on iphone. They cant even imagine what simple link could give them. This could go very wrong way for apple. Imagine their excelent app devs start to make webap version of their apps. Many of the beatifuly designed ones could work very easily on web platform. Suddenly it becomes trend and iphone app exclusivity is gone. Plus apple looses control over the market.
I for one would like to be able to opt in for notifs for events of certain clubs, galleries etc. It feels like sms for your fans. Much faster than newsletter much less busy than social networks.
Here's a link to a comment from a WebKit engineer responding to the notion that Apple deliberately omits features from Safari. Short answer--they don't: https://news.ycombinator.com/item?id=14509746
Every discussion about anything in Safari on HN, even if not at all related, for the last year or two has included multiple people complaining about the lack of WebRTC.
Now it's here and there is a new complaint /s
I agree with threeseed that it probwont come and frankly I don't see why I'd want it (or web notification, or even WebRTC). They only seem to support the use case of replacing real apps with webpages which I don't want to do and makes no sense to me as an end user (I understand the freedom motivations).
With service workers you can transparently intercept outgoing XHRs and replace their results with cached values. You can even do a cache race if you want (cancel the xhr if your cache returns first). This is a hugely important feature for making web apps work offline-first. I mean, it's also a big part of progressive web apps, which is the next thing I'm going to complain about. (I don't personally care much about webrtc, but I can see why people do care about it).
The general point isn't about any one feature in particular. It is about a history safari has with not implementing (or half-heartedly implementing, as with indexeddb for so long) APIs that are important to making the web a useful platform.
Reasonable people can disagree whether or not those features are good, but it seems basically true that my mobile web work is constrained by what iOS safari outright refuses to do, more than anything else.
Can't this be solved by a library? It seems like you could easily build a facade in front of requests that queried local storage...you would just need to figure out whether the device/server is online or not.
You need to be able to bootstrap the page to start with. If I request news.ycombinator.com and I'm offline, then Service Workers are the only way to avoid an error page.
...since you don't know whether there is a new version available on the server or not. To not make the user wait, you show him/her the - potentially - outdated version of your data until a new version is available. It's especially useful in situations where users lack internet connection.
I'm interested in this as well, as I haven't dove into service workers.
But I'm still failing to see why you can't pull the local data from local storage and show it, then render the data from the server (should you get new data)?
That works fine for your xhr data (and is what I do now), but is idiosyncratic to your library (note that detecting online state, responding to online state changes, etc all add complexity to this seemingly simple module, as does managing cache expiry).
You can't do anything about your top level index.html file (or the main js and css assets) though. If the user starts offline the second time they use your app, there's no guarantees about those bootup assets being loaded into cache, you'll just get the "you're offline" screen instead.
Since we are talking about hooking the lifecycle of a page, there's no good way to polyfill this with a library. That initial request needs to be serviced, offline, before you can load your polyfill library.
Maybe I'm confused, but provided I bootstrap the app every time by downloading a script that then downloads the big-ass app (that includes styling and whatnot) if necessary, I should be fine right? Or am I missing something?
That said I do understand that avoiding this could be desirable.
What happens if your user is offline (airplane mode, no data, etc), and can't download the initial bootstrap script? There's no way to avoid an error page at this time, unless you use a browser-specific plugin (the drive offline addon is one of these, but they now use service workers for the same functionality on chrome IIRC).
This is especially useful in non-us, non-eu countries, where people pay a lot for data, relative to their income. Being able to successfully launch and run without any data usage is pretty rad.
Service workers are in a separate layer to your app code. They're in another thread, they're subject to different memory/storage rules, they have access to a few extra apis IIRC.
Service workers are designed to be run independently of your web page. I.e. Your service worker can run in the background and update your apps resource files (or even cached xhr data) when your website isn't open, so that it's ready when the user accesses your site.
This means your site goes from remotely delivered to locally served. Which reduces the load times to super low.
IMO it's also nice and clean because it lets you completely separate your app and network logic.
Your web app itself can be built as if it is always online, and all the offline logic is in the separate code package in a separate thread.
Then you have to build that in your application. In typical use-cases, your application does not have to know about Service Workers, but usually not the vice versa. For example, you can decide to intercept /article/show/{id}, just get the content for the article from your API, compile it with a template you have cached, and serve that instead. From the perspective of your app, nothing has changed. It is the holy grail of progressive enhancement.
I'm pretty sure HTTP caching headers don't provide a guarantee that they will be stored for any length of time at all, the browser is free to empty it at will. They also don't guarantee that all your cached assets will be valid with respect to each other (ie your browser might cache an HTML file but not the content it refers to).
Most importantly, though, you can't simply disable HTTP caching when you notice that you're back online. Those cache entries are there now, and they're hard to get out. Service Workers, on the other hand, will just transparently stop intercepting stuff.
With respect to localStorage, I think the idea is that you absolutely can do almost an entire offline mode with it, with the caveat that your content (html, js, css, images) won't get stored there, so you can't load the page at all!
Also I think there are considerations about how difficult it is for many front end architectures to implement this transparent fallback themselves. If you're a Redux or ClojureScript type of programmer it might be utterly obvious and even trivial to implement (just add a simple middleware), but sadly not everyone is, and a lot of the offline logic would have to be implemented everywhere in your codebase. A service worker lets you do it all in one place.
It's a toss-up whether to use localStorage or a service worker if you could viably do either. Blanket logic over all your HTTP calls would be easier in a service worker, and more customized logic would be easier in localStorage, I'm guessing.
Just to articulate the difference on HTTP caching again:
Using HTTP caching for saying how long online clients should keep a value becomes impossible if you want to tell browsers to store things forever in offline mode. HTTP caching makes no distinction between whether you're online or offline.
> Every discussion about anything in Safari on HN, even if not at all related, for the last year or two has included multiple people complaining about the lack of WebRTC.
> Now it's here and there is a new complaint /s
WebRTC is 6 years old and it's been implemented in Firefox and Chrome for 5 years now ! Since then there's plenty of other DOM API that where introduced and are not supported in webkit, for instance :
- service workers
- push API
- Fetch API
- User Timing API
- Subresource Integrity
On the JavaScript side, the JSC team has been doing a great job for the past two years, leading the way in term of performance and ES2015+ support, but on the DOM side, Safari is really lagging far behind (which is, I guess, probably because they don't want the compete with there native mobile apps).
That was the only way to add apps on iPhone OS 1.0, yes. Maybe they already had the App Store in mind and intended that as a stopgap, maybe the App Store was a reaction to jailbreaks and unofficial app development…
> the complaint was always lack of WebRTC and ServiceWorker support
You have a source for that? To me nobody really started caring about ServiceWorker until the big push recently for PWAs w/ launch of Lighthouse etc. Whereas devs have always wanted browsers to keep up with JS/ES/CSS language standards.
Also "development doesn't really work like that". Who's to say the same devs implementing ES6 features could take on ServiceWorker. Maybe there's something in the codebase blocking ServiceWorker. You just don't know. Assuming one thing is being neglected in favour of the other is a huge assumption.
I feel like the internet getting angry that 'feature 1' is released whilst the 'feature 2' they want isn't, and being all 'why are they spending all their time on feature 1 instead of working on my thing' is such an old trope there should be a term for it.
(But yeah I'd like to see ServiceWorker in Safari too, though please let's not bite the hand that feeds)!
Well, same as yours: I've seen people ask for that on Hacker News in the past. Of course, there will also have been people asking about WebRTC :) My beef has mostly been with SW though.
Of course, with many developers, there will always be some that have asked for one, and some for the other. I highly doubt that someone will chime in saying that they've seen people complaining about lack of ES6 support in Safari, though :)
> Maybe there's something in the codebase blocking ServiceWorker. You just don't know. Assuming one thing is being neglected in favour of the other is a huge assumption.
Yes, this is true. That's why it's mostly "baffling", i.e. I wonder if something like you described is actually the case, or whether it's a case of different priorities or something.
But it's like saying people complain about Internet Explorer not having a feature that other browsers have. When it takes many years longer than the other browsers to implement a feature, you are effectively holding the market back. IE and Safari are the only two browsers that didn't have support until now (with only IE not having support while Edge does).
But seriously, we have a bunch of developers asking for JavaScript improvements. Maybe OP doesn't want them, fine that's useful feedback... but it would be more easily received if it came in a nicer package :)
There never was a browser monopoly on Windows just a bunch of tech illiterates who don't seem bothered by MS's "monopoly" with notepad.exe or anti-competitive moves like taking away the ability to use an alternate graphical shell.
Only one popular consumer OS has prevented the installation of alternate browsers and everyone looks the other way.
I'm not entirely interested in relitigating a past I literally lived through.
On the other hand, it is objectively true that there is only one browser platform for iOS. WebKit or nothing. If they actually supported chrome or Firefox instead of requiring them to be wrappers on webkit renderers, I would not have this complaint.
Of course, the reason this isnt being taken up by anti-trust folks is that iOS doesn't dominate the market the way windows did. So: i guess the answer is to convince my users to stop buying idevices. Whee.
Of course, the reason this isnt being taken up by anti-trust folks is that iOS doesn't dominate the market the way windows did. So: i guess the answer is to convince my users to stop buying idevices. Whee.
No. Monopolies themselves aren't illegal, especially when they're natural monopolies.
It is illegal for a company to use its monopoly to stifle competition in other, unrelated markets.
The classic case is Microsoft using its monopoly in operating systems when Windows had 95% marketshare in the emerging browser market. Remember that Microsoft threatened to cancel HP and Compaq’s Windows licenses if they continued to ship Netscape Navigator instead of IE. That's illegal.
It's not illegal to have a rules and guidelines for a platform a particular company owns. Game consoles are way more restrictive than the iOS App Store and nobody is suing them.
If I really wanted to, I could have built another browser using PNaCl and run it and distributed it on ChromeOS even before it supported Android apps where users trivially have access to other browsers. That remains impossible on iDevices to this day.
If you can't see the difference, you are only deceiving yourself.
> Only one popular consumer OS has prevented the installation of alternate browsers and everyone looks the other way.
iOS doesn't prevent the installation of alternate browsers. It prevents alternate browsers from running their own HTML renderer. Preventing alternate browsers might be legally actionable if Apple had a monopoly; preventing alternate HTML renderers is decidedly not.
Service workers are an anathema to everything Apple is trying to achieve with Safari and I would be shocked if it ever gets included. Their focus is on improving battery life, having a great user experience and maintaining a high level of privacy and security. Service workers are awful for all three. For example look at what you have to do to see running service workers:
Developer Tools > Application > Service Workers
chrome://inspect/#service-workers
If there was a rogue web site launching service workers to do something nefarious how would I know diagnose what's happening ? How would my grandmother ? Where is the transparency the web is supposed to provide ?
This is a misconception. Service workers don't sit in the background consuming resources and performing arbitrary tasks. They respond to events, typically to intermediate requests while a user is using a site.
The service worker spec was carefully and deliberately designed to give the browser, not the site, control over resource consumption. The browser is allowed to stop any service worker at almost any time. See https://github.com/w3c/ServiceWorker/blob/master/implementat...
Something here about babies and bathwater. Service workers are pretty limited in what they can do.
Is there UX work to be done? Sure. But the fundamental problem is that they fill a need that is not met at all by Apple, and not even in a silly "use metal instead of vulkan because reasons" kind of NIH but we'll support some other similar standard fashion, but in a "nope" way.
So, kudos for the speedy es6. I'm still not going to tell people to use safari on macos, and I'm still going to build crazy DIY caches for safari on iOS because I can't do stuff with service workers in a standardized way.
> If there was a rogue web site launching service workers to do something nefarious how would I know diagnose what's happening ?
What exactly are you supposing a service worker would be doing? They can't do huge downloads (the worker is shut down when there are no pages using it and it can only be reactivated by another browsing session or push message), can't receive push messages without showing a notification... there really is very little a service worker can do nefariously.
It can, however, help improve battery life by allowing you to better control the offline experience, and not needlessly activate cell radios.
> If there was a rogue web site launching service workers to do something nefarious how would I know diagnose what's happening ? How would my grandmother ? Where is the transparency the web is supposed to provide ?
How does your grandmother check if the website she visits isn't doing something nefarious without service workers? Does she run the CPU profiler to see all the JS being executed? That's pretty badass, I wish my grandmother was this cool.
I mean, where are service workers? Give me a nice, cross-platform way to handle offline-first and I'll be happy. But hey, it isn't like there's some kind of browser monopoly on iOS or anything, like there was in windows.