There’s definitely something “alien” about a service worker—it’s kind of like a virus that gets installed on the user’s device. I’ve taken to describing it as “a man-in-the-middle attack on your own website” which makes sound a bit scarier than is necessary.

When it seems like all our online activity is being tracked by Google, Facebook, and co., it comforts me to think of all the untracked usage out there, from shared (or fake) Facebook accounts to the good ol’ sneakernet:

Packets of information can be distributed via SMS and mobile 3G but also pieces of paper, USB sticks and Bluetooth.

Jake goes into the details of what exactly is happening when a service worker is installed or replaced.

This is easily the most complex part of working with service workers, and I think I’m beginning to wrap my head around it, but the good news is that, for the most part, you don’t really need to know the ins and outs of this to get started (and dev tools are now making it easier to nuke from orbit if this begins to bite).

This is a truly fantastic example of progressive enhancement applied to a form.

What I love about this is that it shows how progressive enhancement isn’t a binary on/off choice: there are layers and layers of enhancements here, from simple inline validation all the way to service workers and background sync, with many options in between.

We should be asking why we need a framework or a tool before just dropping it in. It’s not to say that you shouldn’t learn new things. YOU ABSOLUTELY SHOULD BE CONTINUOUSLY LEARNING! But you should ensure that you have a solid base to work from.

PPK responds in his typically strident way to posts by Tim and Bastian. I don’t agree with everything here, but I very much agree with this:

It’s not about what works for you. It’s about what works for your users.

If a very complicated set-up with seven brand-new libraries and frameworks and a bunch of other tools satisfies you completely as a web developer but slows your sites down to a crawl for your users, you’re doing it wrong.

If serving your users’ needs requires you to use other tools than the ones you’d really like to use, you should set your personal preferences aside, even though it may make you feel less good. You have a job to do.

I’ve been thinking a lot lately about how we evaluate technologies (it will be the subject of my next talk). Tim is thinking along the same lines. I like his list of four questions to ask when weighing up the pros and cons of any web tool:

Chrome is going to refuse to parse document.write for users on a slow connection. On the one hand, I feel that Google intervening in this way is a bit icky, but I on the other hand, I totally support this move.

This keeps happening. Google announce a change (usually related to search) where I think “Ooh, that could be interpreted as an abuse of a monopoly position …but it’s for ver good reason so I’ll keep quiet.”

Anyway, this should serve as a good kick in the pants for bad actors (that’s you, advertisers) to update their scripts to be asynchronous.

This is a really great step-by-step walkthrough of adding a service worker to a website. Mike mentions the gotchas he encountered along the way, and describes how he incrementally levelled up the functionality.

If you’ve been going through a similar process, please write it down and share it like this!

A gripping history lesson of the internet and the ARPANET before it, emphasising the role of government funding.

Silicon Valley often likes to pretend that innovation is the result of entrepreneurs tinkering in garages. But most of the innovation on which Silicon Valley depends comes from government research, for the simple reason that the public sector can afford to take risks that the private sector can’t.

It’s precisely the insulation from market forces that enables government to finance the long-term scientific labor that ends up producing many of the most profitable inventions.

Today we have an internet effectively controlled by a small number of private companies.

Instead of trying to escape the bigness of the Internet, we should embrace it — and bring it under democratic control. This means replacing private providers with public alternatives where it’s feasible, and regulating them where it’s not.

There is nothing in the pipes or protocols of the Internet that obliges it to produce immense concentrations of corporate power. This is a political choice, and we can choose differently.

A nice introduction to progressive web apps. There’s a little bit of confusion about permissions—whether a site has been added to the home screen or not has no effect on the permissions granted to it (for things like push notifications)—but the wrap-up nails the advantages of using the web:

No more waiting to download an app, no more prompts for updating an app. From a developer perspective, it means we will be able to iterate a lot quicker. We don’t need to wait for app store approvals anymore, and we can deploy at our own leisure.

Another advantage that a progressive web app has over a native mobile app is that it is linkable, hence it is easier to share and, probably even more importantly, can be indexed by search engines. This makes discoverability of the app a lot better.