Link tags: ress

Progress Without Disruption - Christopher Butler

We’ve been taught that technological change must be chaotic, uncontrolled, and socially destructive — that anything less isn’t real innovation.

The conflation of progress with disruption serves specific interests. It benefits those who profit from rapid, uncontrolled deployment. “You can’t stop progress” is a very convenient argument when you’re the one profiting from the chaos, when your business model depends on moving fast and breaking things before anyone can evaluate whether those things should be broken.

We’ve internalized technological determinism so completely that choosing not to adopt something — or choosing to adopt it slowly, carefully, with conditions — feels like naive resistance to inevitable progress. But “inevitable” is doing a lot of work in that sentence. Inevitable for whom? Inevitable according to whom?

Don’t judge a book by its cover

Some neat CSS from Tess that’s a great example of progressive enhancement; these book covers look good in all browsers, but they look even better in some.

Dynamic Datalist: Autocomplete from an API :: Aaron Gustafson

Great minds think alike! I have a very similar HTML web component on the front page of The Session called input-autosuggest.

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.

Custom Asidenotes – Eric’s Archived Thoughts

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.

Most of What We Call Progress - Yusuf Aytas

Every engineer eventually overbuilds something. You think you’re being smart. You’re thinking ahead, building for growth and before you know it, you’ve created a system ten times heavier than your actual problem. That’s the trap. We keep designing for imaginary futures for scale that may never come and call it engineering. But it’s not engineering. It’s over-engineering.

The industry rewards it too. Nobody gets promoted for keeping things small and sane. You get promoted for complexity.

Software can be finished - Ross Wintle

There’s quite a crossover between resilience and longevity:

1. Understand the requirements
2. Keep scope small and fixed
3. Reduce dependencies
4. Produce static output
5. Increase Quality Assurance

The present and potential future of progressive image rendering - JakeArchibald.com

When I set about writing this article, I intended it to be a strong argument for progressive rendering. But after digging into it, my feelings are less certain.

What You Need to Know about Modern CSS (2025 Edition) – Frontend Masters Blog

Here’s a comprehensive round-up of new CSS that you can use right now—you can expect to see some of this in action at Web Day Out!

Optimizing PWAs For Different Display Modes — Smashing Magazine

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.

Hack to the Future - Frontend - Matt Hobbs

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’m more proud of these 128 kilobytes than anything I’ve built since | by Mike Hall | Jul, 2025 | Medium

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.

Polishing your typography with line height units | WebKit

I should be using the lh and rlh units more enough—they’re supported across the board!

A Web Component UI library for people who love HTML | Go Make Things

I’m obviously biased, but I like the sound of what Chris is doing to create a library of HTML web components.

Hiding elements that require JavaScript without JavaScript :: dade

This is clever: putting CSS inside a noscript element to hide anything that requires JavaScript.

A pragmatic browser support strategy | Go Make Things

1. Basic functionality should work on any device that can access the web.
2. Extras and flourishes are treated as progressive enhancements for modern devices.
3. The UI can look different and even clunky on older devices and browsers, as long as it doesn’t break rule #1.

Ten years ago today I coined the shorthand “js;dr” for “JavaScript required; Didn’t Read”. - Tantek

Practice Progressive Enhancement.

Build first and foremost with forgiving technologies, declarative technologies, and forward and backward compatible coding techniques.

All content should be readable without scripting.

If it’s worth building on the web, it’s worth building it robustly, and building it to last.

mirisuzanne/track-list: Enhance a list of audio tracks with playlist controls

This is very nice HTML web component by Miriam, progressively enhancing an ordered list of audio elements.

The web on mobile (a response) | Clagnut by Richard Rutter

Rich suggests another reason why the UX of websites on mobile is so shit these days:

The path to installing a native app is well trodden. We search the App Store (or ironically follow a link from a website), hit ‘Get’ and the app is downloaded to our phone’s home screen, ready to use any time with a simple tap.

A PWA can also live on your home screen, nicely indistinguishable from a native app. But the journey to getting a PWA – or indeed any web app – onto your home screen remains convoluted to say the least. This is the lack of equivalence I’m driving at. I wonder if the mobile web experience would suck as badly if web apps could be installed just as easily as native apps?

Build for the Web, Build on the Web, Build with the Web – Web Performance and Site Speed Consultant

If I was only able to give one bit of advice to any company: iterate quickly on a slow-moving platform.

Excellent advice from Harry (who first cast his pearls before the swine of LinkedIn but I talked him ‘round to posting this on his own site).

1. Opt into web platform features incrementally
2. Embrace progressive enhancement to build fast, reliable applications that adapt to your customers’ context
3. Write code that leans into the browser, not away from it

I’m not against front-end frameworks, and, believe me, I’m not naive enough to believe that the only thing a front-end framework provides is soft navigations, but if you’re going to use one, I shouldn’t be able to smell it.