Tags: resilience

If Not React, Then What? - Infrequently Noted

Put the kettle on; it’s another epic data-driven screed from Alex. The footnotes on this would be a regular post on any other blog (and yes, even the footnotes have footnotes).

This is a spot-on description of the difference between back-end development and front-end development:

Code that runs on the server can be fully costed. Performance and availability of server-side systems are under the control of the provisioning organisation, and latency can be actively managed by developers and DevOps engineers.

Code that runs on the client, by contrast, is running on The Devil’s Computer. Nothing about the experienced latency, client resources, or even available APIs are under the developer’s control.

Client-side web development is perhaps best conceived of as influence-oriented programming. Once code has left the datacenter, all a web developer can do is send thoughts and prayers.

As a result, an unreasonably effective strategy is to send less code. In practice, this means favouring HTML and CSS over JavaScript, as they degrade gracefully and feature higher compression ratios. Declarative forms generate more functional UI per byte sent. These improvements in resilience and reductions in costs are beneficial in compounding ways over a site’s lifetime.

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

Oh, how I wish that every team building for the web would use this sensible approach!

The goal isn’t to write less code | Go Make Things

The goal isn’t to write less code.

It’s to ship less code to users. Better code. Faster code. More resilient code.

THIS!

Sooooo many front-end developers don’t grasp this fundamental principle: it’s not about you!

It’s about time I tried to explain what progressive enhancement actually is - Piccalilli

Progressive enhancement is a design and development principle where we build in layers which automatically turn themselves on based on the browser’s capabilities.

The idea of progressive enhancement is that everyone gets the perfect experience for them, rather than a pre-determined “perfect” experience from a design and development team.

Every website and web app should have a service worker | Go Make Things

Needless to say, I agree with this sentiment.

I’ve worked with a lot of browser technology over the years. Service workers are pretty mind-blowing.

minimum interesting service worker

An interesting idea from Tantek for an offline page that links off to an archived copy of the URL you’re trying to reach—useful for when you’re site goes down (though not for when the user’s internet connection is down).

Web Content Accessibility Guidelines—or WCAG—looks very daunting. It’s a lot to take in. It’s kind of overwhelming. It’s hard to know where to start.

I recommend taking a deep breath and focusing on the four principles of accessibility. Together they spell out the cutesy acronym POUR:

1. Perceivable
2. Operable
3. Understandable
4. Robust

A lot of work has gone into distilling WCAG down to these four guidelines. Here’s how I apply them in my work…

Perceivable

I interpret this as:

Content will be legible, regardless of how it is accessed.

For example:

• The contrast between background and foreground colours will meet the ratios defined in WCAG 2.
• Content will be grouped into semantically-sensible HTML regions such as navigation, main, footer, etc.

Operable

I interpret this as:

Core functionality will be available, regardless of how it is accessed.

For example:

• I will ensure that interactive controls such as links and form inputs will be navigable with a keyboard.
• Every form control will be labelled, ideally with a visible label.

Understandable

I interpret this as:

Content will make sense, regardless of how it is accessed.

For example:

• Images will have meaningful alternative text.
• I will make sensible use of heading levels.

This is where it starts to get quite collaboritive. Working at an agency, there will some parts of website creation and maintenance that will require ongoing accessibility knowledge even when our work is finished.

For example:

• Images uploaded through a content management system will need sensible alternative text.
• Articles uploaded through a content management system will need sensible heading levels.

Robust

I interpret this as:

Content and core functionality will still work, regardless of how it is accessed.

For example:

• Drop-down controls will use the HTML select element rather than a more fragile imitation.
• I will only use JavaScript to provide functionality that isn’t possible with HTML and CSS alone.

If you’re applying a mindset of progressive enhancement, this part comes for you. If you take a different approach, you’re going to have a bad time.

Taken together, these four guidelines will get you very far without having to dive too deeply into the rest of WCAG.

Your site or app should work as much as possible without JavaScript | Go Make Things

Photoshop in the browser? That needs JS.

But the reality is, most of what we build is either static HTML or mostly just forms and page reloads. We can build the web that way by default, and progressively enhance a more Ajaxy experience on top of it.

The result is an app that’s faster to load, faster to run, and less prone to breaking… without much additional work for your developers.

Manifesto for a Humane Web

I endorse this message.

This manifesto is intended as a personal response to the current state of the web. It is a statement of intent and a call to arms, inviting you, the reader, to go forth and build humane websites, and to resist the erosion of the web we know and love.

The invisible seafaring industry that keeps the internet afloat

A fascinating in-depth look at the maintenance of undersea cables:

The industry responsible for this crucial work traces its origins back far beyond the internet, past even the telephone, to the early days of telegraphy. It’s invisible, underappreciated, analog.

Snook’s Law:

It’s a truism that people don’t think about infrastructure until it breaks, but they tend not to think about the fixing of it, either.

The web is mostly links and forms | Go Make Things

In the same vein as that last link, Chris says what we’re all thinking:

Most of what we build is links from one page to another, and form submissions that send data from the browser to the server.

Cold-blooded software

Warm-blooded software:

Maybe your CI isn’t working because one of the services you depend on got bought or ran out of money. You add a new dependency and find yourself needing to upgrade your compiler. Another package you depend on is deprecated, and doesn’t work with the latest version of the compiler.

I aspire to build cold-blooded software:

You work alone, make some changes when you’re inspired, and then don’t touch it again for another year, or two, or three.

Web Components Will Outlive Your JavaScript Framework | jakelazaroff.com

Decision time:

There’s a cost to using dependencies. New versions are released, APIs change, and it takes time and effort to make sure your own code remains compatible with them. And the cost accumulates over time.

This post is about more than web components:

If we want our work to be accessible in five or ten or even 20 years, we need to use the web with no layers in between. For all its warts, the web has become the most resilient, portable, future-proof computing platform we’ve ever created — at least, if we build with that in mind.

An Ode to Living on The Grid

A terrific interview with Deb Chachra. Her new book, How Infrastructure Works sounds excellent!

Using Stencil to make a live poll Web Component

Before getting into the details of the code, Matt hits the nail on the head talking about the the one thing that web components have that no framework can offer: longevity.

Quoting Stuart Brand:

Old systems break in familiar ways. New systems break in unexpected ways.

Well! The web is an old system.

Aaron Gustafson

Progressive enhancement begins with constructing a robust and universally accessible foundation, designed to cater to all users, regardless of individual or technological circumstances. From here, advanced features can be strategically layered to enhance the user experience wherever feasible. Even as these enhancements roll out, guided by the capacities of different devices, the quality of network connections, or the availability of specific APIs, the core functionalities should remain steadfast and accessible to all.

Jack Franklin – Abstractions, complexities and off-ramps – All Day Hey! 2023 - YouTube

This is a terrific talk by Jack on how to deal with the tooling involved in modern front-end development:

• Maintaining control,
• Dependency awareness,
• Lean on browser primitives,
• Have an exit strategy.

Efficiency trades off against resiliency - Made of Bugs

Past some point, making a system more efficient will mean making it less resilient, and, conversely, building in robustness tends to make a system less efficient (at least in the short run).

This is true of software, networks, and organisations.

When we set metrics or goals for a system or a team or an organization that ask for efficiency, let us be aware that, absent countervailing pressures, we are probably also asking for the system to become more brittle and fragile, too.

When JavaScript Fails

So, if progressive enhancement is no more expensive to create, future-proof, provides us with technical credit, and ensures that our users always receive the best possible experience under any conditions, why has it fallen by the wayside?

Because before, when you clicked on a link, the browser would go white for a moment.

JavaScript frameworks broke the browser to avoid that momentary loss of control. They then had to recreate everything that the browser had provided for free: routing, history, the back button, accessibility features, the ability for search engines to read the page, et cetera iterum ad infinitum.

Remote Synthesis | The Price Developers Pay for Loving Their Tools Too Much

• Don’t wrap too much of your identity in a tool.
• Every tool will eventually fade.
• Flexibility is a valuable skill
• Changing tools does not mean starting over.

I agree with pretty much every word of this article.