As acerbic and cutting a critique of utility-first CSS (and that particular framework) as you would expect from Heydon, but hidden amongst the humour are some (also equally expected) jewels of wisdom. It's not that Tailwind and utility-first CSS are automatically bad; they have their place. But when taken as the end-all solution for CSS, they cross a line that becomes hard to ignore.

On how utility-first CSS both requires a solid knowledge of CSS to work well, and is least appealing to those that have that knowledge in the first place:

However, paradoxically, the more you learn about CSS, the less you may appreciate utility-first CSS. You might begin to question why it should exist at all.

On inheritance and the cascade, and how they can save you a huge amount of code if embraced:

In fact, I believe there’s a kind of CSS 80/20 rule wherein about 80% of your styling should be done with just 20% (or less!) of your CSS.

On where utility classes are most beneficial:

Where utility classes come in is they allow you to make occasional exceptions to these generalized styling rules.

On the innate paradox at the core of "utility-first CSS":

Utility-first CSS is exception-first CSS. And that’s not how exceptions work, in CSS or in general.

On how utility-first CSS is really only beneficial when there are a lot of design differences across an interface, and how that's probably a big ol' red flag:

To put it another way, show me a design for an interface that benefits from being coded using utility-first CSS and I will show you an interface that is fundamentally f**ked.

On Tailwind and utility-first frameworks:

So what is Tailwind really? It’s just CSS with extra steps and a brand name. Then again, you can say that about most any CSS framework.

On the fallacy of chasing the new and shiny, and believing that more recent ideas are automatically better:

But CSS isn’t new, it’s only good. And in this backwards, bullshit-optimized economy of garbage and nonsense, good isn’t bad enough.

An interesting – albeit flawed – attempt at a zero-dependencies, web standards focused, PWA based UI framework, and a potentially useful quick-start template for using web components and native APIs to build a lightweight web app. I will caution that the author has some odd ideas about both HTML and front end development in general. For example: they advocate the use of <label> wrappers for <input>, but fail to understand that you still need the id attribute for accessibility purposes. They also chose to use a range slider as the basis for a switch component 🤷‍♀️ So, I like the underlying principles and general idea, but wouldn't recommend using this as-is or copying code verbatim; it's definitely not reliable, and as the author doesn't even have their own personal website, it's hard to know how experienced they are in actual front end development.

Remy has some good arguments for why TypeScript can be just as much of an issue as it is a benefit. I've personally got a love/hate relationship with the abstraction, so it's always good to have some of my own feelings validated 😉 And it's good to hear from someone working "at scale" that these issues only compound, rather than smooth out, as that had been what I would have guessed.

On the confusing semantics:

A "well crafted" definition, type or interface (still no idea when I should use each), is often a huge cognitive load on me.

On one of the greatest frustrations:

Having to rewrite correctly and infallible JavaScript so that it was friendly enough for TypeScript to understand

A useful single-purpose site that implements most (if not all) currently spec'd PWA APIs and lets you play around with them. Good for testing cross-browser quirks and for seeing a quick overview of what you can actually achieve natively, right now.

Another attempt at a privacy-focused, simplified search engine, with some interesting filter options – called "optics" – which let you customise your results. Only want to search personal sites? Or only the Fediverse? What about ignoring the top 1,000 websites in the world completely?

(Unfortunately, this site does not appear to be indexed, nor is there any way to submit it, though there are plenty of mentions around the edges.)

The Arc browser recently added an auto-summarisation feature to its search. The result is a mash of misinformation and content theft, which Ben argues (and I fully agree) will ultimately create an even more sanitised, repetitive, and less useful web.

This is the polar opposite of the direction I want to head!

On the long-term harm that "AI" abstraction and summarisation can cause (or how do people now get paid?); emphasis mine:

Real people sometimes pay to access content, or donate to support a nonprofit publisher, or watch an ad. Those things can be annoying but pay for the content to be produced in the first place. If we strip them away, there’s no writing, information, or expression for the app to summarize. A world where everyone uses an app like this is a death spiral to an information desert.

On the loss of soul that occurs when everything is run through the same "AI" filter:

let’s not sanitize it through a banal filter that is designed to strip it of its humanity.

A really lovely article about how to help people navigate the digital world that doesn't involve having to tackle huge, global issues. Start small. Start with people. Even one at a time, it absolutely still matters.

The gist: 

There’s a chapter in the book where Hendren talks about a non-profit workshop that helps fabricate physical tools and accommodations for people with disabilities, when I read it I almost quit tech entirely.

In the same way the little workshop builds from the book bespoke accommodations, is it possible to build bespoke apps and browser extensions to help bodies meet the digital world? I use my web developer superpowers ✨ to hack websites or build small apps for myself all the time. Why not offer this skill to other people?

A brilliant site for comparing common component patterns across most of the major front end frameworks. Want to learn Svelte and already know React? Select both, pick the pattern you're wanting to replicate, and compare the two code examples.

Also useful for seeing which frameworks are most verbose/complex, which syntax patterns are gaining the widest adoption, and which tools include solutions that others push to third-party tools or developers (CSS and state management come to mind).

A potentially useful tool for making your browser's new tab page a lot more productive (even if it isn't quite what I want).

A Fine Start replaces your browser’s new tab page with a clean and simple list of your favorite links.

A critique of npm (and other package managers), the move-fast hype cycle of tech products, and the tech debt it creates.

The result is an interesting look at how our tools enable the whole VC-funding-to-enshittification nightmare circle, and some thoughts on how it could be avoided.

On why it pays to slow down and plan out a long-term course of action:

Although, I could argue that while driving 200mph is fun and exciting, you’re one small fuckup away from a major fuckup. My point is that a key factor of sustainability is making sure maintainability stays on par with growth.

On npm; I like thinking about it as fancy copy/paste:

the ability to fancy copy-paste your way into an unmaintainable situation is higher than ever

A solid example of where HTML semantics can be a little problematic:
the <meter> element. Also a good overview of where/when this element is useful.

On when to use <meter>:

A more tangible use case for the <meter> element would be to indicate something like available storage space, or percentage of remaining budget on a service where your plan only allows you a certain number of events or entit

On why you should always have a text-based label when using <meter>:

A meter is good for an at-a-glance sense of how much of something has been used, but you need to present it alongside the actual value for it to be at all useful.

On how semantics can degrade poor UX if not considered holistically:

When you're choosing the right element for the job, it's entirely possible to go too far the other way, and overuse semantic elements when actually they hinder more than they help.

A collective approach to the missing fourth R in the oft-quoted environmentalist mantra: repair. Not everyone is an electrical engineer, IT technician, or mechanic, but chances are someone living down the road is. The goal of a Repair Café is to put the two of you in touch, and thereby develop a more circular economy. This site can help you find your nearest Café, or set one up if your community is not yet covered.