Tags: resilience

116

sparkline

Tuesday, April 26th, 2022

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).

Wednesday, March 30th, 2022

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.

Sunday, March 13th, 2022

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.

Wednesday, March 9th, 2022

When should there be a declarative version of a JavaScript API?

I feel like it’s high time I revived some interest in my proposal for button type="share". Last I left it, I was gathering use cases and they seem to suggest that the most common use case for the Web Share API is sharing the URL of the current page.

If you want to catch up on the history of this proposal, here’s what I’ve previously written:

Remember, my proposal isn’t to replace the JavaScript API, it’s to complement it with a declarative option. The declarative option doesn’t need to be as fully featured as the JavaScript API, but it should be able to cover the majority use case. I think this should hold true of most APIs.

A good example is the Constraint Validation API. For the most common use cases, the required attribute and input types like “email”, “url”, and “number” have you covered. If you need more power, reach for the JavaScript API.

A bad example is the Geolocation API. The most common use case is getting the user’s current location. But there’s no input type="geolocation" (or button type="geolocation"). Your only choice is to use JavaScript. It feels heavy-handed.

I recently got an email from Taylor Hunt who has come up with a good litmus test for JavaScript APIs that should have a complementary declarative option:

I’ve been thinking about how a lot of recently-proposed APIs end up having to deal with what Chrome devrel’s been calling the “user gesture/activation budget”, and wondering if that’s a good indicator of when something should have been HTML in the first place.

I think he’s onto something here!

Think about any API that requires a user gesture. Often the documentation or demo literally shows you how to generate a button in JavaScript in order to add an event handler to it in order to use the API. Surely that’s an indication that a new button type could be minted?

The Web Share API is a classic example. You can’t invoke the API after an event like the page loading. You have to invoke the API after a user-initiated event like, oh, I don’t know …clicking on a button!

The Fullscreen API has the same restriction. You can’t make the browser go fullscreen unless you’re responding to user gesture, like a click. So why not have button type="fullscreen" in HTML to encapsulate that? And again, the fallback in non-supporting browsers is predictable—it behaves like a regular button—so this is trivial to polyfill. I should probably whip up a polyfill to demonstrate this.

I can’t find a list of all the JavaScript APIs that require a user gesture, but I know there’s more that I’m just not thinking of. I’d love to see if they’d all fit this pattern of being candidates for a new button type value.

The only potential flaw in this thinking is that some APIs that require a user gesture might also require a secure context (either being served over HTTPS or localhost). But as far as I know, HTML has never had the concept of features being restricted by context. An element is either supported or it isn’t.

That said, there is some prior art here. If you use input type="password" in a non-secure context—like a page being served over HTTP—the browser updates the interface to provide scary warnings. Perhaps browsers could do something similar for any new button types that complement secure-context JavaScript APIs.

Saturday, March 5th, 2022

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.

Sunday, January 16th, 2022

The computer built to last 50 years | ploum.net

A fascinating look at what it might take to create a truly sunstainable long-term computer.

Wednesday, December 29th, 2021

Add a Service Worker to Your Site | CSS-Tricks - CSS-Tricks

Damn, I wish I had thought of giving this answer to the prompt, “What is one thing people can do to make their website better?”

If you do nothing else, this will be a huge boost to your site in 2022.

Chris’s piece is a self-contained tutorial!

Monday, December 13th, 2021

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.

Saturday, December 11th, 2021

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.

Tuesday, October 19th, 2021

Software developers have stopped caring about reliability

My web browser has been perfectly competent at submitting HTML forms for the past 28 years, but for some stupid reason some asshole developer decided to reimplement all of the form semantics in JavaScript, and now I can’t pay my electricity bill without opening up the dev tools. Imagine what it’s like to not know how to do that. Imagine if you were blind.

Folks, this is not okay. Our industry is characterized by institutional recklessness and a callous lack of empathy for our users.

Wednesday, September 29th, 2021

Responsible JavaScript, A Book Apart

TAKE MY MONEY!!!

If we want people to fully experience the sites we have worked so hard to craft, then we must be judicious in our use of JavaScript. In thoughtful detail, Jeremy Wagner shows how JavaScript can be used to progressively enhance server-side functionality, while improving speed and access for more visitors. By centering user needs every step of the way—from toolchains to metrics to testing—we can all contribute to a more inclusive, accessible, and resilient web.

Sunday, September 26th, 2021

The word for web is forest | New_ Public Magazine

The wood wide web has been a powerhouse metaphor for popularizing the mutualistic relationships of healthy forests. But like a struggling forest, the web is no longer healthy. It has been wounded and depleted in the pursuit of profit. Going online today is not an invigorating walk through a green woodland—it’s rush-hour traffic alongside a freeway median of diseased trees, littered with the detritus of late capitalism. If we want to repair this damage, we must look to the wisdom of the forest and listen to ecologists like Simard when they tell us just how sustainable, interdependent, life-giving systems work.

A beautiful piece by the brilliant Claire L. Evans.

The project of decentralizing the web is vast, and only just beginning. It means finding a way to uproot our expression and communication from the walled gardens of tech platforms, and finding novel ways to distribute the responsibilities of infrastructure across a collective network. But we needn’t start from nothing.

Thursday, September 9th, 2021

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.

Wednesday, September 8th, 2021

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.

Tuesday, August 3rd, 2021

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!).

Tuesday, June 29th, 2021

Solutionism

Progressive enhancement in meatspace:

IRL progressive enhancement is quite common when you think of it. You can board planes with paper boarding cards, but also with technology like QR codes and digital wallets. You can pay for a coffee with cash, card or phone. The variety serves diverse sets of people. Just like in web development, not dismissing the baseline lets us cover use cases we didn’t know existed. It is fragile, though: some manager somewhere probably has a fantasy about replacing everything with fancy tech and fancy tech only.

Tuesday, June 22nd, 2021

Design for Safari 15 - WWDC 2021 - Videos - Apple Developer

There’s a nice shout-out from Jen for Resilient Web Design right at the 19:20 mark.

It would be nice if the add-to-homescreen option weren’t buried so deep though.

Sunday, June 6th, 2021

The right tag for the job: why you should use semantic HTML - localghost

A great introduction to structuring your content well:

Using semantic HTML as building blocks for a website will give you a lovely accessible foundation upon which to add your fancy CSS and whizzy JavaScript.

Tuesday, May 11th, 2021

Design for reading: tips for optimizing content for Reader modes and reading apps

The more I consume content in reading apps, the more I am reminded of the importance and the power of progressive enhancement as a strategy to create resilient and malleable experiences that work for everyone, regardless of how they choose to consume our content.

Top stuff from Sara here!

We have a tendency to always make an assumption about how our readers are reading our content—probably in the browser, with our fancy styles applied to it. But if we make a habit out of thinking about the Web in layers and CSS as an enhancement on top of the content layer, then we can start optimizing and enhancing our users’ reading experiences regardless of their context.

Thinking about the different ways in which users access the Web only shines light on the importance of a progressively enhanced approach to building for the Web. The more we think about the Web in layers and try to improve the experience of one layer before moving to the next, the more resilient experiences we can create. That’s what the essence of progressive enhancement is about.

Monday, May 10th, 2021

Building a resilient frontend using progressive enhancement - Service Manual - GOV.UK

Using progressive enhancement means your users will be able to do what they need to do if any part of the stack fails.

What a terrific short guide to sensible web development!

  • Start with HTML
    • Using interactive elements
    • Adding the extras
    • Building more complex services
    • Testing your service
    • Do not assume users turn off CSS or JavaScript
    • Case studies and related guides