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.
Shamefully, I haven’t been doing one-to-ones with my front-end dev colleagues at Clearleft, but I’m planning to change that. This short list of starter questions from Lara will prove very useful indeed.
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 is relevant to my interests because I think I’m supposed to be a senior developer. Or maybe a technical director. I’m really not sure (job titles suck).
Anyway, I very much appreciate the idea that a technical leadership position isn’t just about technical skills, but also communication and connectedness.
When we boiled down what we’re looking for, we came away with 12 traits that divide pretty cleanly along those three areas of responsibility: technical capability, leadership, and community.
For someone like me with fairly mediocre technical capability, this is reassuring.
Now if I only I weren’t also mediocre in those other areas too…
I really, really like what Ember is aiming for here:
That’s how you get the holy grail of resilience and performance:
Subsequent visits and interactions are therefore nearly instantaneous, because they don’t rely on the network.
I sincerely hope other frameworks are paying attention to this layered approach.
Oh, and I also like this observation:
There’s an age-old argument about the difference between “web pages” and “web apps”. In reality, there’s a continuum between the two.
The World Wide Web, with all of its pages, blogs and so on- has allowed human expression in ways that would have been uneconomic and out of reach before. The most dramatic effect has been this ability for almost anyone to express himself or herself whenever they want to- and potentially be heard by many others.
Vint Cerf there, taking part in this wide-ranging discussion with, among others, Kevin Kelly and Bob Metcalfe.
The introduction leans a bit too heavily on Nicholas Carr for my liking, but it ends up in a good place.
The internet connects us cognitively and becomes a membrane through which our minds can interact, manifesting a whole new iteration of our species, who have begun to exist in a connected symbiotic relationship with technology.
The internet is the first technology we have created, that makes us more human.
Story of my life:
I have to confess I had no idea what a technical leader really does. I figured it out, eventually.
Seriously, this resonates a lot with what I find myself doing at Clearleft these days.
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.
From twenty years ago, a look back at the origins of the internet, written by its creators.
I’ve been thinking a lot about learning, teaching, mentoring, coaching …this article by Ivana McConnell from last year is packed with gold nuggets of wisdom concerning apprenticeships.
As lifelong learners, we may be reluctant to call ourselves “masters.” But that’s missing the point, and it discounts the fact that teaching is learning. We’re not there to guarantee mastery—we’re there to give our apprentices fundamentals, to foster their respect, and make journeymen (or women) out of them. Mastery will come; we just offer the tools.
I really love what Dan is doing with his apprenticeship programme—I hope we can do something like this at Clearleft.
The latest piece from Jonathan Harris explores online life in all its mundanity, presenting it in an engaging way, all the while trying to make you feel bad for doing exactly what the site is encouraging you to do.
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.
I really like this list. I might make a similar one for the Clearleft office so what’s implicit is made explicit.
It’s ok to:
- say “I don’t know”
- ask for more clarity
- stay at home when you feel ill
- say you don’t understand
- ask what acronyms stand for
- ask why, and why not
- forget things
I know exactly how Tim feels. It’s hard not to feel guilty when you’re reading something instead of spending the time doing “real work”, but it always ends up being time well spent:
Reading time can be hard to justify, even to oneself. There is no deadline. It’s not going to move any immediate projects forward (most likely). And it often feels like a waste of time, especially if your interests are diverse. But it’s important. Most great work is the product of collaborative thinking.
The Working Draft podcast is usually in German, but this episode is in English. It was recorded in a casual way by a bunch of people soaking up the sun sitting outside the venue at Beyond Tellerrand. Initially that was PPK and Chris, but then I barged in half way through. Good fun …if you’re into nerdy discussions about browsers, standards, and the web. And the sound quality isn’t too bad, considering the circumstances under which this was recorded.
Mark has dumped his brains!
Seriously, there is a lot of thought that has gone into this, and it’s just the beginning: Mark recounts the experience that Clearleft has had with delivering pattern libraries, laying the groundwork for releasing the library-generating tool that he has been building.
Watch this space.
An ongoing photography project from Curtis:
Beyond Work tells stories about humans at work, with no judgement or glorification. It’s an attempt at unearthing the social, cultural and functional world of work, that’s become invisible in everyday life.
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.
Linting CSS seems like a very good idea, especially if you’re not the only one writing the CSS. This guide is going to come in very handy when I give it a try.
A really good explanation of how a peer-to-peer model for the web would differ from the current location-centric approach.
What really interests me is the idea of having both models co-exist.
You just have to think about the ways in which our location-centrism is contributing to the problems we are hitting, from the rise of Facebook, to the lack of findability of OER, to the Wikipedia Edit Wars.
Really interesting to see how Jason, Lyza, and co. are handling the process side of responsive design by using Agile sprints. This is how we’re doing it at Clearleft too.
There’s a really good point in here about starting with small-screen sketching:
For most of the sprint, we focus on small screens. We’re often asked how things will work on wider screens early in a sprint, but we try to resist thinking about that yet.
If you’ve managed to organize your life to fit inside a New York City apartment, you’re not going to have any trouble adjusting to a big house in the suburbs. The same is true of responsive designs.
If you nail the small screen design, the larger sizes will be easy by comparison.
Bootstrap is a product of Twitter. If you want your team to work like Twitter’s team, then by all means use Bootstrap. Pick up their design language. Their tool chain. Their decisions. Don’t be surprised when it feels off every time you use it. It will.
The same goes for Material Design. Foundation. These are all products built by other teams to work for their process. Their structure.
Finding the right tool is not what I am advocating for. Making it is.
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.
We’re about to start trying out OKRs (Objectives and Key Results) at Clearleft. It’s a terrible, jargony label, and a lot of the discussion around them is steeped in valleywank, but I think they could be a useful way of helping shared understanding within a company.
I’ll be having a read through the accompanying guide.
Use a framework if you must but never presume it’s viable over the long-term. Newer and better alternatives will appear before you’re half-way through your project. Never forget frameworks are an option — you don’t have to use one.
This is a really lovely project by Dan and Nat—Christmas cards featuring the fleeting invisible constellations formed by the mesh of GPS satellites within which our planet lies.
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.
Paul takes a look back at a time in his life one decade ago. This is a great piece of personal writing.
A list of known bugs (and workarounds) in flexbox implementations. This is going to be handy to refer back to.
A wonderful sci-fi vignette from Matt.
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.
Here’s Paul’s write-up of his excellent talk at FF Conf.
Previously I’ve used the term “developer convenience” when describing the benefits of using a framework. Paul uses the term “ergonomics” to describe those benefits. I like that. I worry sometimes that the term “developer convenience” sounds dismissive, which isn’t at all my intention—making our lives as developers less painful is hugely important …but it’s just not as important as improving the lives of the end users (in my opinion …and Paul’s).
As I look at frameworks, I see the ergonomic benefits (and those are important, I agree!), but I can’t help but feel that, for many developers, investing in knowledge of the web platform itself is the best long-term bet. Frameworks come and go, it just seems to be the ebb and flow of the web, and, as I said above, they do contribute ideas and patterns. But if you ever find that the one you use no longer works for you, or has a bug that remains unfixed, being able to understand the platform that underpins it will help enormously.
This was one of favourite talks at this year’s FF Conf. But I will readily admit there’s a hefty dollop of confirmation bias in my enjoyment.
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.
In a strikingly accurate replica of the original IMP log (crafted by UCLA’s Fowler Museum of Cultural History) on one of the room’s period desks is a note taken at 10:30 p.m., 29 October, 1969—“talked to SRI, host to host.” In the note, there is no sense of wonder at this event—which marks the first message sent across the ARPANET, and the primary reason the room is now deemed hallowed ground.
Suppose the internet is “rewiring our brains” …what of it? Perhaps we can also rewire the brain of the internet.
I’m getting more radical in my view of the internet, this unconsciously-generated machine for unconscious generation. I’m feeling more sure of its cultural value and legacy, and more assertive about stating it. We built this thing, and like all directed culture of the past, it has an agency and a desire, and if you pay attention to it you can see which way it wants to go, and what it wants to fight. We made that, all of us, in time, but we don’t have full control of it. Rather, like the grain of wood, it’s something to be worked with and shaped, but also thought about and conceptualised, both matter and metaphor.
A fascinating guest post by Brian McConnell on Centauri Dreams: what if there’s a galactic equivalent to the internet, allowing civilisations to communicate with a system analogous to packet switching.
Unfortunately this kind of focussed signalling would be hard to detect. But on the other hand, it could explain the Fermi paradox.
I completely agree with Cennydd (and Peter, and Leisa). If anyone working on a project—whether they’re a designer, developer, or anything else—isn’t considering the user experience, then what’s the point of even being there? By extension, labelling your work as “UX Design” is as redundant and pointless as labelling it “Good Design.”
But my complaint is with the label, not the activities. It’s the UX Design label that has little value for me. These activities happen in all good design: if you’re not trying to create positive experience then I don’t really understand what you are doing.
The title is hyperbolic, and while I certainly think that the criticisms of HTTP here are justified, I don’t think it will be swept aside by IPFS—I imagine more of a peaceful coexistence. Still, there’s some really good thinking in here and this is well worth paying attention to.
Aaron collects some recent examples that demonstrate
- why we should use HTTPS and
- why we should use progressive enhancement.
Following on from her great conversation with Jen on The Web Ahead podcast, Rachel outlines a strategy to avoid feeling overwhelmed by the deluge of tools, frameworks, libraries, and techniques inundating front-end developers every day:
Learn your core skills well. Understand HTML and CSS, be able to build a layout without leaning on a framework. Get a solid understanding of how a website actually gets from the server to a browser, an understanding of security and accessibility. These are the basics, the constants. These things change slowly. These things sit underneath all the complexity and the tooling, the CMSs and the noise of thousands of people all trying to make their mark on this industry.
She also makes this important point:
As you are doing this don’t forget to share what you know.
This is the way to approach building for the web:
I want to make as few of those assumptions as possible. Because every assumption I make introduces fragility. Every assumption introduces another way that my site can break.
It’s progressive enhancement, but like Stuart, Tim is no longer planning to use that term.
This one-day workshop that Cennydd is running in London on July 22nd looks like it’s going to be really good.
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.
The Indieweb approach has a lot in common with Ev’s ideas for Medium, but the key difference is that we are doing it in a way that works across websites, not just within one.
Progressive Enhancement remains the best option for solving web development issues such as wide-ranging browser support, maintenance and future-proofing your application.
This looks like it’ll be brilliant! Nat is running a prototyping workshop the day before Responsive Day Out:
This workshop is for designers with no coding experience — if you’re an absolute beginner who wants to find out whether coding can help you with your job, this is for you!
I think the distinction between ‘how it works’ and ‘how it looks’ is blurrier than we think.
I love this talk.
Alex takes a long-zoom look at the web and our technology stacks, from ’60s counterculture to start-up culture, touching on open source and the indie web along the way.
A long-zoom look at life, work, and success.
I’m not usually a fan of portmanteau neologisms, but I really like Tash’s coining of the word longtrepreneur.
A walkthrough on using the iOS app Workflow to huffduff audio files from just about any app.
This year’s map from TeleGeography is looking lovely.
Alternative histories of communication.
Sensible words from Christian.
Web applications don’t follow new rules.
And frameworks will not help:
A lot of them are not really fixing fundamental problems of the web. What they do is add developer convenience. … This would be totally OK, if we were honest about it.
Tim Maughan reports on the same container ship trip that Dan W. is sending his postcards from.
I like the idea of there being an Apollo-sized project all around us, if you just know where to look.
First, towering above and over the ship, are the loading cranes. Vast structures mounted on huge, four-legged frames, they resemble the naked scaffolding of unbuilt skyscrapers, and trigger nostalgic reminders of Saturn V rocket launch towers from the 1960s.
Once in port at night I saw one suddenly fire into life next to the ship in a stroboscopic explosion of lights, before it tracked slowly above my high vantage point, bathing me in the orange glow of a dozen small halogen suns.
I’ve said it before: if your client-side MVC framework does not support server-side rendering, that is a bug. It cripples performance.
I have doubts about Angular 1.x’s suitability for modern web development. If one is uncharitably inclined, one could describe it as a front-end framework by non-front-enders for non-front-enders.
I have to admit, my initial reaction to the idea of providing free access to some websites for people in developing countries was “well, it’s better than no access at all, right?” …but the more I think about it, the more I realise how short-sighted that is. The power of the internet stems from being a stupid network and anything that compromises that—even with the best of intentions—is an attack on its fundamental principles.
On the surface, it sounds great for carriers to exempt popular apps from data charges. But it’s anti-competitive, patronizing, and counter-productive.
I’m not a new developer, but I can definitely relate to this. In fact, when I’ve spoken to any developer about this, it turns out that everyone feels overwhelmed by how much we’re expected to know. That’s not good. We should open up and talk about this more (like Charlotte is doing here).
An important clarification from Stephen:
You don’t actually design in the browser
When I speak of designing in the browser, I mean creating browser-based design mockups/comps (I use the terms interchangeably), as opposed to static comps (like the PSDs we’re all used to). So it’s not the design. It’s the visualization of the design—the one you present to stakeholders.
Personally, I think it’s as crazy to start in the browser as it is to start with Photoshop—both have worldviews and constraints that will affect your thinking. Start with paper.
Like an Enid Blyton adventure for the 21st century, James goes out into the country and explores the networks of microwave transmitters enabling high-frequency trading.
If you think that London’s skyscraper boom is impressive – the Shard, the Walkie-Talkie, the Cheesegrater, the Gherkin – go to Slough. It is not height that matters, but bandwidth.
Seb will be running this workshop again at the start of February—details here. I can’t recommend it highly enough—it’s so, so good!
I had the great honour of being invited to speak on the 200th edition of the Working Draft podcast (there are a few sentences in German at the start, and then it switches into English).
I had a lot of fun talking about indie web building blocks (rel=me, indieauth, webmention, h-entry, etc.). Best of all, while I was describing these building blocks, one of the hosts started implementing them!
Here’s a fun little interview I did recently, mostly about work stuff. It’s available for your huffduffing pleasure.
One thing that really bothers me is the way I repeatedly said “guys” to refer to my colleagues at Clearleft. I must stop doing that.
Continuous partial City And The City, courtesy of James.
Those of us who reside on the “right” side of fixed, physical borders seem to cross the electromagnetic border every day, whether overtly, by entering the right passwords and credit card numbers, or covertly, as when using VPNs to watch TV programs viewable only in other territories. Those on the “wrong” side are subjected to a different but analogous battery of tests, intensifying at the physical border but often carried out far from it, in networked enclaves or foreign transit zones or aboard floating teleconference platforms in international waters.
Angry, but true.
Don’t lock yourself into a comprehensive technology that may just die within the next few months and leave you stranded. With progressive enhancement you’ll never go wrong. Progressive enhancement means your code will always work, because you’ll always focus on providing a minimal experience first, and then adding features, functionality, and behavior on top of the content.
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.
But under the guise of innovation and progress, companies are stripping away worker protections, pushing down wages, and flouting government regulations. At its core, the sharing economy is a scheme to shift risk from companies to workers, discourage labor organizing, and ensure that capitalists can reap huge profits with low fixed costs.
There’s nothing innovative or new about this business model. Uber is just capitalism, in its most naked form.
How computers work:
One day, a man name Alan Turing found a magic lamp, and rubbed it. Out popped a genie, and Turing wished for infinite wishes. Then we killed him for being gay, but we still have the wishes.
Then we networked computers together:
The network is ultimately not doing a favor for those in power, even if they think they’ve mastered it for now. It increases their power a bit, it increases the power of individuals immeasurably. We just have to learn to live in the age of networks.
We are all nodes in many networks. This is a beautiful description of how one of those networks operates.