If the browser needs to parse 296kb of JavaScript to show a list of blog posts, that’s not Progressive Enhancement, it’s using the wrong tool for the job.
A good explanation of the hydration problem in tools like Gatsby.
JavaScript is a powerful language that can do some incredible things, but it’s incredibly easy to jump to using it too early in development, when you could be using HTML and CSS instead.
I’m slapping my forehead—progressive web components is a perfect name for what I’ve been calling HTML web components. Why didn’t I think of that?
A Progressive Web Component is a native Custom Element designed in two layers: a base layer of HTML and CSS that renders immediately, without JavaScript, and an enhancement layer of JavaScript that adds reactivity, event handling, and more advanced templating.
This is an excellent one-stop shop of interface patterns:
This is an organic collection of common JS patterns that can be replaced with just HTML, CSS, and no, or very low, JS. As HTML and CSS continue to mature, this collection should expand.
This episode of the Shop Talk Show is the dictionary definition of “rambling” but I had a lot of fun rambling with Chris and Dave!
Progressive enhancement is about building something robust, that works everywhere, and then making it better where possible.
You might not need (much) JavaScript for these common interface patterns.
While we all love the power and flexibility JS provides, we should also respect it, and our users, by limiting its use to only what it needs to do.
Yes! Client-side JavaScript should do what only client-side JavaScript can do.
Web browsers provide you with great features for free. Why would you choose to use tools that stop you taking advantage of that?
Have you got the perfect talk for this event? Let me know!
A one-day event all about what you can in web browsers today: Brighton, March 12th, 2026. Tickets are just £225+VAT!
Some handy tips courtesy of Chris Ferdinandi.
HTML’s new `command` attribute on the `button` element could be a game-changer.