Why we teach our students progressive enhancement | Blog Cyd Stumpel
Progressive enhancement is about building something robust, that works everywhere, and then making it better where possible.
This in an intriguing promise (there’s no code yet):
A PWA typically requires writing a service worker, an app manifest and a ton of custom code. Progressier flattens the learning curve. Just add it to your html template — you’re done.
I worry that this one line of code will pull in many, many, many, many lines of JavaScript.
Progressive enhancement is about building something robust, that works everywhere, and then making it better where possible.
An excellent example of an HTML web component from Eric:
Extend HTML to do things automatically!
He layers on the functionality and styling, considering potential gotchas at every stage. This is resilient web design in action.
There’s really good browser support for display-mode media queries and this article does a really good job of running through some of the use cases for your progressive web app.
Put the kettle on. This is a long one!
Matt takes a trip down memory lane and looks at all the frontend tools, technologies, and techniques that have come and gone over the years.
But this isn’t about nostalgia (although it does make you appreciate how far we’ve come). He’s looking at whether anything from the past is worth keeping today.
Studying past best practices and legacy systems is crucial for understanding the evolution of technology and making informed decisions today.
There’s only one technique that makes the cut:
After discussing countless legacy approaches and techniques best left in the past, you’ve finally arrived at a truly timeless and Incredibly important methodology.
I don’t normally link to articles on Medium—I respect you too much—and I do wish this were written on Mike Hall’s own site, but this is just too good not to share.
And don’t dismiss this as a nostalgiac case study from the past:
At no point did the constraints make the product feel compromised. Users on modern devices got a smooth experience and instant feedback, while those on older devices got fast, reliable functionality. Users on feature phones got the same core experience without the bells and whistles.
The constraints forced us to solve problems in ways we wouldn’t have considered otherwise. Without those constraints, we could have just thrown bytes at the problem, but with them every feature had to justify itself. Core functionality had to work everywhere, and without JavaScript crutches proper markup became essential.
This experience changed how I approach design problems. Constraints aren’t a straitjacket, keeping us from doing our best work; they are the foundation that makes innovation possible. When you have to work within severe limitations, you find elegant solutions that scale beyond those limitations.
Progressive web apps from the trenches.
In which I find a tagline for Web Day Out and a tagline for React.
Some handy tips courtesy of Chris Ferdinandi.
It’s kind of ridiculous that this functionality doesn’t exist yet.
Naming custom elements, naming attributes, the single responsibility principle, and communicating across components.