Lots and lots of programming advice. I can’t attest to the veracity and efficacy of all of it, but this really rang true:
If you have no idea how to start, describe the flow of the application in high level, pure English/your language first. Then fill the spaces between comments with the code.
Blogging about your stupid solution is still better than being quiet.
You may feel “I’m not start enough to talk about this” or “This must be so stupid I shouldn’t talk about it”.
Create a blog. Post about your stupid solutions.
Although this piece is ostensibly about why we should be using web workers more, there’s a much, much bigger point about the growing power gap between the devices we developers use and the typical device used by the rest of the planet.
While we are getting faster flagship phones every cycle, the vast majority of people can’t afford these. The more affordable phones are stuck in the past and have highly fluctuating performance metrics. These low-end phones will mostly likely be used by the massive number of people coming online in the next couple of years. The gap between the fastest and the slowest phone is getting wider, and the median is going down.
Tom makes an endpoint for generating QR codes so you don’t have to rely on the Google Charts API.
He also provides a good definition of “serverless”:
Now, serverless is a very silly buzzword dreamed up by someone from the consultant class who love coming up with terrible names, so I promise I won’t use it any further. Your code obviously run on a server. It just means it runs on a server someone else manages.
Amazon call it a ‘Lambda Function’. Google call it a ‘Cloud Function’. Microsoft Azure call it simply a ‘Function’. But none of those are very descriptive, because, well, anyone who writes any kind of programming language generally writes functions pretty much all the time in much the same way as anyone who writes English writes paragraphs, and we don’t call our blogging software “Cloud Paragraphs”. (Someone will now, I’m guessing.)
Here’s the opening keynote I gave at Frontend United in Utrecht a few weeks back.
Less than 24 hours after I put the call out for a solution to this gnarly service worker challenge, Trys has come up with a solution.
Offline fallback page with service worker - Modern Web Development: Tales of a Developer Advocate by Paul Kinlan
Paul describes a fairly straightforward service worker recipe: a custom offline page for failed requests.
When you greet a stranger, look at his shoes.
Keep your money in your shoes.
Put your trouble behind.
When you greet a stranger, look at her hands.
Keep your money in your hands.
Put your travel behind.
I love the way that Benjamin is documenting his activities at Homebrew Website Club Brighton each week:
Another highly productive 90 mins.
Homebrew website club is on every Thursday evening 6.00-7.30pm at Clearleft. You should come along!
Two of my favourite things: indie web and service workers.
This makes me so happy. I remember saying when my book came out, that the best feedback I could possibly get would be readers making their websites work offline. The same can be said for the talk of the book.
For full hipster points, make sure you’re using these services, and then casually drop them into conversation by saying “Yeah, it’s a pretty obscure service; you probably haven’t heard of it…”
This is a really clever technique from Scott that he unveiled at An Event Apart in Seattle. It uses a header sent by a service worker to distinguish between returning and new visitors—much neater than relying on a cookie. I’ve updated my service worker on The Session to use this technique now.
Here’s a thorough blow-by-blow account of the workshop I ran in Nottingham last week:
Jeremy’s workshop was a fascinating insight into resilience and how to approach a web project with ubiquity and consistency in mind from both a design and development point of view.
A small but perfectly formed progressive web app. It’s a private, offline-first personal journal with no log-in and no server-stored data. You can read about the tech stack behind it:
Your notes are only stored on your device — they’re never sent to a server. You don’t even need to sign-in to use it! It works offline, so you can reflect upon your day on the slow train journey home.
When you stop to consider all the implications of poor performance, it’s hard not to come to the conclusion that poor performance is an ethical issue.
An interesting proposal from Jake on a different way of defining how service worker fetch events could be handled under various conditions. For now, I have no particular opinion on it. I’m going to let this stew in my mind for a while.
I love this use of e-ink to play a film at 24 frames per day instead of 24 frames per minute.
This is the real challenge for service workers:
For 30 years, we taught billions of humans that you need to be connected to the internet to consume the web via a browser! This means web users need to unlearn that web sites can’t be used offline.
Of all the buzzwords in tech, perhaps none has been deployed with as much philosophical conviction as “frictionless.” Over the past decade or so, eliminating “friction” — the name given to any quality that makes a product more difficult or time-consuming to use — has become an obsession of the tech industry, accepted as gospel by many of the world’s largest companies.