Progressive Web App for FixMyStreet · Issue #1996 · mysociety/fixmystreet

Here’s a Github issue that turned into a good philosophical debate on how to build a progressive web app: should you enhance your existing site or creating a separate URL?

(For the record: I’m in favour of enhancing.)

Progressive Web App for FixMyStreet · Issue #1996 · mysociety/fixmystreet

Tagged with

Related links

Progressive enhancement brings everyone in - The History of the Web

This is a great history of the idea of progressive enhancement:

It is an idea that has been lasting and enduring for two decades, and will continue.

Tagged with

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.

Tagged with

You can use Web Components without the shadow DOM

So what are the advantages of the Custom Elements API if you’re not going to use the Shadow DOM alongside it?

  1. Obvious Markup
  2. Instantiation is More Consistent
  3. They’re Progressive Enhancement Friendly

Tagged with

JavaScript dos and donts @ Mu-An Chiou

Straightforward smart sensible advice that you can apply to any feature on a website.

Tagged with

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!

Tagged with

Related posts

Making the website for Research By The Sea

Having fun with view transitions and scroll-driven animations.

Browser support

Here’s Clearleft’s approach to browser support. You can use it too (it’s CC-licensed).

Applying the four principles of accessibility

Here’s how I interpret the top-level guidance in the Web Content Accessibility Guidelines.

Speculation rules

A performance boost in Chrome.

Baseline progressive enhancement

If a browser feature can be used as a progressive enhancement, you don’t have to wait for all browsers to support it.