Link tags: progressive

431

sparkline

CSS { In Real Life } | My Browser Support Strategy

This is a great succinct definition of progressive enhancement:

Progressive enhancement is a web development strategy by which we ensure that the essential content and functionality of a website is accessible to as many users as possible, while providing an improved experience using newer features for users whose devices are capable of supporting them.

Progressively Enhanced Builds - Jim Nielsen’s Blog

Rather than thinking, “how do I combine a bunch of disparate content, templates, and tooling into a functioning website?”, you might think “how do I start at a functioning website with content and then use templates and build tooling to enhance it?”

I think Jim is onto something here. The more dependencies you have in your build process, the likelier it is that over time one of them will become a single point of failure. A progressive enhancement approach to build tools means you’d still be able to launch your site (even if it’s not in its ideal state).

I want to be able to view, edit, and if need be ship a website, even if the build process fails. In essence, if the build does fail I can still take all the source files, put them on a server, and the website remains functional (however crude).

Web Components as Progressive Enhancement - Cloud Four

This is exactly the pattern of usage I’ve been advocating for with web components—instead of creating a custom element from scratch, wrap an existing HTML element and use the custom element to turbo-charge it, like Zach is doing:

By enhancing native HTML instead of replacing it, we can provide a solid baseline experience, and add progressive enhancement as the cherry on top.

Be the browser’s mentor, not its micromanager. - Build Excellent Websites

This one-page site that Andy has made to illustrate his talk at All Day Hey is exactly what I was talking about with declarative design.

Give the browser some solid rules and hints, then let it make the right decisions for the people that visit it, based on their device, connection quality and capabilities. This is how they will get a genuinely great user experience, rather than a fragmented, broken one.

Make Beautifully Resilient Apps With Progressive Enhancement

You had me at “beautifully resilient apps with progressive enhancement”.

This is a great clear walkthrough of enhancing a form submission. A lot of this seems like first principles to me, but if you’ve only ever built single page apps, then thinking about a server-submission process first might well be revelatory.

Make it boring — jlwagner.net

People are propelled by their interests, and web developers have a lot of space to be interested in all sorts of stuff. For you, it may be JavaScript ‘n Friends, or HTML and CSS. Maybe it’s all that stuff, but put aside your preferences for a moment and answer me this: what are you helping people to do? If the answer involves any remotely routine or crucial purpose, consider putting aside your personal desire for excitement. Instead, make boring things that are usable, accessible, and fast. Ours is a job done by people for people, not a glamorous rockstar gig.

Excellent advice from Jeremy who wants us to build fast, reliable, resilient websites …even if the technologies involved in doing that don’t feel exciting.

Central to that endeavor is recognizing that the browser gives you a ton of stuff for free. Relying on those freebies requires a willingness to not npm install a solution for every problem — especially those that are best solved with CSS and HTML. Those technologies may seem boring, but boring is fast. Boring is usable. Boring is resilient and fault tolerant. Boring is accessible. When we rely wholesale on JavaScript to build for the web, we’re inevitably reinventing things. At worst, our reinventions of rock-solid HTML features — such as client-side form validation  — break in unexpected ways despite our carefully written tests. At best, a flawless reimplementation of those features adds unnecessary code to applications, and depends on a technology less fault-tolerant than CSS and HTML.

Progressive Enhancement, the New Hotness™ | Go Make Things

Here’s a great explanation of progressive enhancement, complete with practical examples and myth-busting. Pass it ‘round!

If you care about quality engineering, you want as much fault tolerance in the things you build as possible.

Add Responsive-Friendly Enhancements to `details` with `details-utils`—zachleat.com

This is how a web component should be designed! Zach has made a custom element that wraps around an existing HTML element, turbocharging its powers. That’s the way to think about web components—as a progressive enhancement.

How to progressively enhance a nav menu | Go Make Things

A lot of folks assume that progressive enhancement means having to write the same code twice, but often, it can be as simple as extending the pattern you already have once the JS loads.

“Evergreen” Does Not Mean Immediately Available | CSS-Tricks - CSS-Tricks

Smart advice on future-proofing and backward-compatibility:

There isn’t a single, specific device, browser, and person we cater to when creating a web experience. Websites and web apps need to adapt to a near-infinite combination of these circumstances to be effective. This adaptability is a large part of what makes the web such a successful medium.

Consider doing the hard work to make it easy and never remove feature queries and @supports statements. This creates a robust approach that can gracefully adapt to the past, as well as the future.

Embrace the Platform - CSS-Tricks

This is a wonderful piece by Bram. Half history lesson, and half practical advice for building resilient websites today:

By embracing what the web platform gives us — instead of trying to fight against it — we can build better websites.

Keep it simple. Apply the Rule of Least Power. Build with progressive enhancement in mind.

HTML, CSS, and JavaScript — in that order.

Help Users Accomplish What They Came For - CSS-Tricks

If I were to point out one thing that people can do to make their website better, it is to take a moment to think about the most crucial actions that we want our users to be able to do on a page and make them as easy and accessible as possible.

All visual effects, fancy graphics, beautiful interactions, and tracking scripts should come second.

Wise words from Anna.

I hope that progressive enhancement doesn’t become yet another buzzword and that you really take a moment to help the user accomplish what they came for.

htmx - high power tools for html

I really like the progressive enhancement approach that this little library uses—it’s basically the Hijax approach I was talking about back in the days of Bulletproof Ajax but all wrapped up into a neat package that you can use entirely via HTML attributes.

Getting Started with PWAs [Workshop]

The slides from Aaron’s workshop at today’s PWA Summit. I really like the idea of checking navigator.connection.downlink and navigator.connection.saveData inside a service worker to serve different or fewer assets!

Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes - YouTube

This is a terrific and nuanced talk that packs a lot into less than twenty minutes.

I heartily concur with Rich’s assessment that most websites aren’t apps or documents but something in between. It’s a continuum. And I really like Rich’s proposed approach: transitional web apps.

(The secret sauce in transitional web apps is progressive enhancement.)

Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes

Why We Create Progressive Web Apps: A Conversation with Jeremy Keith

This is a really nice write-up by Sydney of the chat we had on her podcast.

Decoded: The When, Why, and Why Not of Progressive Web Apps

I really enjoyed talking to Sydney Lai about progressive web apps, resilient web design, and all my other hobby horses.

Alas, there’s no transcript and I can’t find a direct link to the RSS feed or the individual audio file on the podcast website so it’s not huffduffable.

How To Build Resilient JavaScript UIs — Smashing Magazine

The opening paragraphs of this article should be a mantra recited by every web developer before they begin their working day:

Things on the web can break — the odds are stacked against us. Lots can go wrong: a network request fails, a third-party library breaks, a JavaScript feature is unsupported (assuming JavaScript is even available), a CDN goes down, a user behaves unexpectedly (they double-click a submit button), the list goes on.

Fortunately, we as engineers can avoid, or at least mitigate the impact of breakages in the web apps we build. This however requires a conscious effort and mindset shift towards thinking about unhappy scenarios just as much as happy ones.

I love, love, love the emphasis on reducing assumptions:

Taking a more defensive approach when writing code helps reduce programmer errors arising from making assumptions. Pessimism over optimism favours resilience.

Hell, yeah!

Accepting the fragility of the web is a necessary step towards building resilient systems. A more reliable user experience is synonymous with happy customers. Being equipped for the worst (proactive) is better than putting out fires (reactive) from a business, customer, and developer standpoint (less bugs!).

For developers, Apple’s Safari is crap and outdated – Perry Sun | Blog

Apple dragged their feet in adding support for PWAs in Safari, and when they finally did, limited the capabilities of a PWA so that native-like app functionality wouldn’t be possible, like notifications or a home screen icon shortcut – to name just a few of the many restrictions imposed by Apple.

But it goes beyond that. On iOS, the only web rendering engine allowed is Apple’s own WebKit, which runs Safari. Third-party iOS browsers such as Chrome can only use WebKit, not their own engines (as would be permitted in Windows, Android, or macOS). And it’s WebKit that governs PWA capabilities.

Safari is very good web browser, delivering fast performance and solid privacy features.

But at the same time, the lack of support for key web technologies and APIs has been both perplexing and annoying at the same time.

The enormous popularity of iOS makes it all the more annoying that Apple continues to hold back developers from being able to create great experiences over the web that work across all platforms.