119 slides from Sarah on a wide range of SVG magic (with code).
Paul goes into detail describing how he built a progressive web app that’s actually progressive (in the sense of “enhancement”). Most of the stuff about sharing code between server and client goes over my head, but I understood enough to get these points:
- the “app shell” model is not the only—or even the best—way of building a progressive web app, and
- always, always, always render from the server first.
Another great deep dive by Heydon into a single interface pattern. This time it’s the tooltip, and its cousin, the toggletip.
There’s some great accessibility advice in here.
Riffing on Rachel’s talk at Patterns Day:
At the Patterns Day conference last month, Rachel Andrew mentioned something interesting about patterns. She said that working with reusable interface components, where each one has its own page, made her realise that those work quite well as isolated test cases. I feel this also goes for some accessibility tests: there is a number of criteria where isolation aids testing.
Hidde specifically singles out these patterns:
- Collapsible (“Show/hide”)
- Form field
- Video player
This looks like a sensible way to detect if the user is offline, and provide appropriate feedback, like making certain links or forms inactive.
Thanks to jQuery, you probably don’t need jQuery. Just look at all these methods that started life in jQuery, that are now part of the standardised DOM API:
This primer on progressive web apps starts by dispelling some myths:
- Your thing does not have to be an “Application” to be a PWA.
- PWAs are not specifically made for Google or Android.
- PWAs are ready and safe to use today.
Then it describes the three-step programme for turning your thing into a progressive web app:
- The Manifest.
- Go HTTPS.
- The Service Worker.
We don’t want the field to de-democratize and become the province solely of those who can slog through a computer science degree.
So we need new tools that let everyone see, understand, and remix today’s web. We need, in other words, to reboot the culture of View Source.
Dave explains how Jekyll Includes are starting to convert him to web components. The encapsulation is nice and neat. And he answers the inevitable “but why not use React?” question:
I like that Web Components are an entirely client-side technology but can be rendered server-side in existing tech stacks whether it’s Jekyll, Rails, or even some Enterprise Java system.
This is a really great screencast on getting started with React. I think it works well for a few reasons:
- Sarah and Chris aren’t necessarily experts yet in React—that’s good; it means they know from experience what “gotchas” people will encounter.
- They use a practical use-case (a comment form) that’s suited to the technology.
- By doing it all in CodePen, they avoid the disheartening slog of installation and build tools—compare it to this introduction to React.
- They make mistakes. There’s so much to be learned from people sharing “Oh, I thought it would work like that, but it actually works like this.”
There’s a little bit of “here’s one I prepared earlier” but, on the whole, it’s a great step-by-step approach, and one I’ll be returning to if and when I dip my toes into React.
A great collection of learned lessons from implementing service workers.
I really, really like it when people share their own personal experiences and “gotchas!” like this.
As you might expect, lots of sites just don’t work, but there are plenty of sites that work just fine—Google search, Amazon, Wikipedia, BBC News, The New York Times. Not bad!
Of all the sites to pick to demo progressive web apps, we get the cesspit that is Hacker News …I guess it is possible to polish a turd.
Anyway, here are some examples of using frameworks to create alternative Hacker News readers. So the challenge here is to display some text to read..
That’s right: React appears in both. See, it’s not about the tools; it’s about how you use ‘em.
I love, love, *love, traintimes.org.uk—partly because it’s so useful, but also because it’s so fast. I know public transport is the clichéd use-case when it comes to talking about web performance, but in this case it’s genuine: I use the site on trains and in airports.
Matthew gives a blow-by-blow account of the performance optimisations he’s made for the site, including a service worker. The whole thing is a masterclass in performance and progressive enhancement. I’m so glad he took the time to share this!