A nice little walkthrough of a straightforward Service Worker for a content-based site, like a blog.
The life cycle of a Service Worker—with all its events and states—is the one bit that I’ve never paid that much attention to. My eyes just glaze over when it comes to installation, registration, and activation. But this post explains the whole process really clearly. Now it’s starting to make sense to me.
Andrew picks out his favourite bits from this year’s Google I/O, covering web payments, CSS containment, and—of course—Service Workers and progressive web apps, although he does note (and I concur):
I wish Google would focus as much attention on ‘normal’ sites that perform navigations as they do on so called ‘app-shell’ (which is just a new name for single-page apps, as far as I can tell), but then many people will be building SPAs and these recipes will make those apps fly. In news publishing we seem to flip flop between traditional page navigations and SPAs, but I’ve never found a SPA news site (or a native app) that I really like more than a normal website. Maybe a really good progressive web app will change that. But I’m not convinced.
Still, as he says:
All this really just underscores how flexible ServiceWorker is and that with it we can disagree on what the right solution is, but we can all get what we want anyway.
Jason looks at the business reasons for and against building progressive web apps. In short, there’s everything to gain and nothing to lose.
Seriously, why would you not add a Service Worker and a manifest file to your site? (assuming you’re already on HTTPS)
The roadmap for progressive web apps from Microsoft; not just their support plans, but also some ideas for distribution.
This ongoing series about the nuts’n’bolts of implementing Service Workers is really good. This one is great for getting to grips with the cache API.
Dave turned Day Trip into a progressive web app.
Starting this week, Android users (~13% of our active user base) who use DayTrip more than once will eventually be asked if they want to install our web app to their Home Screen. That’s important real estate for a small startup like ourselves.
Minimum viable Service Worker tutorial. Copy, paste, and don’t ask questions.
Remy sums up the psychological end goal of progressive apps (HTTPS + Service Worker + manifest JSON file) prompting an add to home screen action:
This high bar of entry will create a new mental model for our users.
If I add this app to my home screen, it will work when I open it.
It’s a shame that this charge to turbo-boast the perception of the web on mobile is a bit one-sided: I would love to see Apple follow Google’s lead here. But if Android succeed in their goal, then I think iOS will have to follow suit just to compete.
I hadn’t heard of the
save-data header. This article shows how you can use a Service Worker to sniff for it and serve up smaller assets, but I’m guessing you could also sniff for it from the server.
Myself and Batesy spent last week in Ipswich doing an intense design sprint with Suffolk Libraries. Leon has written up process from his perspective as the client—I’ll try to get a case study up on the Clearleft website soon.
This is really great write-up; it captures the sense of organised chaos:
I can’t recommend this kind of research sprint enough. We got a report, detailed technical validation of an idea, mock ups and a plan for how to proceed, while getting staff and stakeholders involved in the project — all in the space of 5 days.
Microsoft are officially on board with implementing Service Workers in Edge:
Roadmap Priority: High — We intend to begin development soon.
Ooh, I really like this idea! Pointing to your Service Worker the same way you point to your style sheet makes a lot of sense to me.
Lyza has written an excellent deep dive into Service Workers, complete with code.
I’m really chuffed that she gave me a shout-out to my exhortation:
So if you decide to play around with Service Workers, please, please share your experience.
Adrian documents how he’s using Service Workers on Soundslice. I could imagine doing something similar for The Session.
A great piece by Christian on taking a responsible, customer-focused approach to building on the web.
You don’t have to support old browsers and terrible setups. But you are not allowed to block them out. It is a simple matter of giving a usable interface to end users. A button that does nothing when you click it is not a good experience. Test if the functionality is available, then create or show the button.
Calum has set up a Service Worker on his site. Here he muses on the potential for offline experiences.
A hands-on look at building a progressive web app with Service Workers, manifest files, HTTPS, and all that good stuff. This is nice and balanced, extolling the virtues but also warning about the potential difficulties in implementing this stuff.
One nitpick though: there’s talk of graceful degradation, and while I get that that’s the outcome, I think it’s better to think in terms of progressive enhancement, which is the approach.
This is a nifty use of Service Workers—using a cache to mitigate unresponsive Content Delivery Networks.
The stuff in here about
Promise.race is particularly useful for “lie-fi” scenarios: instead of thinking about the network connection in a binary way (either it’s available or it isn’t), considering the scenario of a crappy network connection seems more realistic.
Bruce gives a great run-down of what’s involved in creating one of those new-fangled progressive apps that everyone at Google and Opera (and soon, Mozilla) are talking about: a secure connection, a service worker, and a manifest file.
Crucially, in browsers that don’t support it, you have a normal website. It’s perfect progressive enhancement.
Funnily enough, this here website—adactio.com—is technically a progressive app now.
At their simplest, Progressive Web Apps are application-like things hosted on your web server. If you’re as old as me, you might call them “web sites”
Outlining the architectural thinking required to create what the Google devrel folks are calling progressive apps.
Browsers without service worker support should always be served a fall-back experience. In our demo, we fall back to basic static server-side rendering…
…but this is only one of many options.
Hmmm. In my opinion, sending usable HTML on first request isn’t an implementation detail—it’s crucial. But on the whole, this approach is very sensible indeed.
A great walkthrough of setting up a Service Worker for a blog. The code is here but more importantly, as Brandon says:
I wouldn’t be able to implement this myself if it wasn’t for some of the awesome people I mentioned earlier sharing their experience. So share, share, share!
Another clear explanation by Nicolas of using Service Worker, this time on CSS Tricks.
I really like Alex’s framing of best-of-breed progressively enhanced websites as “progressive apps” (although Bruce has some other ideas about the naming).
It’s a shame that the add-to-homescreen part isn’t standardised yet though.
It’s very early days for ServiceWorker, but Jake is on hand with documentation and instructions on its use. To be honest, most of this is over my head and I suspect it won’t really “click” until I try using it for myself.
Where it gets really interesting is in the comments. Stuart asks “What about progressive enhancement?” And Jake points out that because a ServiceWorker won’t be installed on a first visit, you pretty much have to treat it as an enhancement. In fact, you’d have to go out of your way to make it a requirement:
You could, of course, throw up a splash screen and wait for the ServiceWorker to install, creating a ServiceWorker-dependant experience. I will hunt those people down.
This is a breath of fresh air: a blogging platform that promises to keep its URLs online in perpetuity.
Charles Arthur analyses the data from Google’s woeful history of shutting down its services.
So if you want to know when Google Keep, opened for business on 21 March 2013, will probably shut - again, assuming Google decides it’s just not working - then, the mean suggests the answer is: 18 March 2017. That’s about long enough for you to cram lots of information that you might rely on into it; and also long enough for Google to discover that, well, people aren’t using it to the extent that it hoped.
A one-stop-shop with links to the authentication settings of various online services. Take the time to do a little Spring cleaning.
This could be a handy little service for sharing locally-hosted sites.
A very handy looking API that turns file uploading (and conversion) into a service.
This is the reason why we chose Vzaar for hosting the videos on the Reprieve website.
Elliot gives a rundown of the font delivery services for the web that are on the way.
Another font-linking service is on the way.
Jeff's got something up his sleeve that will help the cause of web typography.
Gareth is putting some wisdom of crowds behind the design of APIs. Vote on the principles that you think are important in a good API.
If anybody out there has some experience with the Amazon Associates Web Service API and XSLT, I could do with some help.
A handy little RESTful ping service to answer the eternal question: "is it just me or is my site really down?"
This is good news. You can expect Gravatar service to get faster and better.
Early adopters of the iPhone now get a $100 of Apple Store credit. Nice bit of customer management.
Dopplr can has API.
The second part of Gareth's series for Digital Web on APIs. This time he's got some PHP code samples for parsing XML and JSON.
PayPal has a new competitor. Amazon is now offering a payment services to developers.
Ben Buchanan on how most supposedly open Web 2.0 (sic) sites are really walled gardens lacking interoperability.
Yet another reason never to fly with Ryanair.
I'm loving this mashup of lolcats, Twitter and Flickr. Occasionally the text and the picture matches up in a serendipitously hilarious way.
Multimap's API is now open and free as in beer (as long as the traffic is within reasonable bounds). This is good stuff. And they're all in with the Open Street Map guys too.
Track Cindy and Jason on their trip across the country... mashup style.
Aral just posted his extensions to the Twitter API.
A nice collection of royalty free texture photos using the Flickr API.
Machine tags will now be available through the Flickr API (that's triple tags to you and me).
Dave Winer doesn't get JSON.
A nifty mashup in which Twitter bots update twice a day with weather updates. I am now friends with Brighton Weather. I feel so in touch with nature.
Users of the Google API take note: you're okay, but anyone else who wants to put Google search on their site is screwed.
Users of the Flickr API take note: the path to images has changed.
A cool way of looking at photos from your Flickr contacts, built using the Flickr API by Jason Garber and Jeremy Carbaugh (who are here with me at Refresh Orlando).
Here's an API for accessing material that is censored in countries like China or Iran.You can use this API to republish that information on other sites, circumventing the censorship.
The W3C Validator now has an API. It's SOAP only unfortunately, but this could still prove to be immensely useful for rolling into a CMS.
This new method in the Flickr API could be used to create some fun zeitgeist-driven mashups.
Hallelujah! I've been waiting for Flickr to add this method. Now the API is truly complete.
You can now get responses from the Flickr API formatted as JSON.
Jonathon has found some circumstantial evidence of an API for searching the iTunes music store. That could be really interesting. It might be fun to mash it up with Amazon's API.
He has decided to prove that he can walk to Cork -- the location of the nearest Apple repair center -- faster than Apple can arrange for the pickup of his broken Mac.
Cameron has written a great article on using APIs with Ajax. I love the idea of using .htaccess to fake a proxy and get around the same-site restriction.
Version 2 of Google's Maps API is out. Changes, changes, read all about it.
Douglas Crockford has written a wrapper function to allow the easy interchange of JSON data between servers.
As a follow-up to my post about Yahoo's term extractor, I should point out that Tagyu also has an API. It's RESTful and simple.
Make Flickr photos into magazine covers - another fun use of the API.
CNET's News.com explains why web services are so cool.
A handy guide to using a wrapper for the Google Maps API.
A very cool mashup of two APIs: events from EVDB and maps from Google Maps.
This is cool and frightening in equal measures. Eric uses the Google API to demonstrate the effect of nuclear detonations on American cities.
Geo-tagging meets social software. I must check this out and investigate the API.
PayPal moves into the territory of merchant accounts. With an API no less!
The BBC is going to be offering an API. Hallelujah!
Tim Bray on the politics and practicalities of Web services.