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.

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)?

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.

That said I do understand that avoiding this could be desirable.

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

and

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

?

"finally" seems wrong here :)

I'll also note that Safari 10.1 was first with SharedArrayBuffer ;)

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.

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.

You are privileged to be able to work with Safari.

Imagine if you had to work with its bastard deformed brothers WKWebView and UIWebView.

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

They also already have Custom Elements v1 support, which is still in progress in Firefox.

Timing and SRI they announced in this release (11).

Service Workers is THE big gap, at this point it feels like they're actually very afraid of progressive web apps.

(That said, 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.