Apple's latest release notes indicate their support for Service Workers.
- Service Workers. Implement background scripts for offline web applications and faster web pages.
- Payment Request. Provide a consistent user payment experience in Safari using a standards-based API.
- Security Improvements. Improved protection against memory corruption and code execution attacks.
- Web Inspector Updates. New designs for the Network Tab and the Styles sidebar in the Elements Tab.
The Service Worker API that acts as a network proxy for the browser that gives web developers more control over requests. This means better experiences in bad network conditions and developers get access to certain app architecture concepts which can improve user experience in all conditions.
Safari's support will put a huge dent in the Can I Use numbers for the better. What this means for me and my team is that we can start confidently leaning in to Service Workers with more of our time and effort. We still have to build applications that progressively enhance from browsers which do not support them, but that extra layer of complication can now be justified. For some teams, they could have reached that justification earlier, but in my mind Service Workers had to be considered more experimental before this major browser got onboard.
App Shell Architecture
One application design enabled by Service Workers is called App Shell Architecture, where the layout and re-used assets of a web page are cached for re-use and the network requests center more around the data being passed over in order to render content of the page as a secondary request. Similar page-construction choices are already somewhat popular in web dev land but they are not necessarily a great choice without this caching layer in my opinion. If you cannot cache the shell, I really wouldn't advise making so many calls home just to render the first content. You want less latency, not more.
We do not make use of this architexture right now, and that's why this Safari update is important. I think it just puts us over the hump where we can put these ideas front of mind. It gives us enough browser support to build paths where the page layout can be stored on the user's machine—desktop or mobile.
We are certainly web-first shop and there is no native dev.to option yet, and I would not want to put the cart before the horse, but this might give us an excuse to stay fully web even on mobile for a while. But I don't want to commit too far in that direction. The development benefits of only having a single application are great if the user experience helped by powerful browser APIs.
Our application already makes use of networking logic at the edge via our CDN Fastly and leaning in to Service Workers gives us one more edge layer. A request that has never been handled by Service Workers is still likely to be handled at an edge node.
If you live in New Zealand we don't expect you to come all the way to Utah for your content. Service Workers mean that much of the HTML (and other assets, of course) can stay with you on your browser so your next visit is much faster to show you some layout and sends fewer bytes over the wire. We still want to provide the same crisp load without service workers, but we have the tools to cater a really good overall web experience for consistent users.
This move might ease some heartburn over Safari. I'm glad we have dipped our toes in Service Workers so we are not just catching up now, but I am also glad we did not try jumping in head first a year ago only to maintain a more complicated cross-browser compatibility for only 2/3rds support.
Happy coding ❤️