I always teach designers to remember that users and stakeholders aren't software designers. So we should pay careful attention to their problems, but not assume their solution is the right one (though it can be).

Getting these questions answered without insulting the requester (especially stakeholders) is an important soft skill. You have to make them feel heard, intelligent, and supported.

You haven’t read the HTML spec. There are an incredible amount of elements, including for changing just a piece of text (b, i, strong, em, and many more). Plus elements for visual aspects like images.

You need divs and spans for extra structure that isn’t there for anything but visual purpose. For things you wouldn’t describe to someone who couldn’t see the page. That’s a lot less than you think.

HTML authoring and choosing the right elements can be fun. But you have to stop thinking visually and start thinking semantically.

You might need some extra divs for layout sure. But I guarantee less than most people are using if they markup their content first.

Remember divs mean nothing. So the opening example on the Tailwind website is the accessible equivalent of “blah blah blah”.

Also if you think massive numbers of nested divs don’t have a performance impact in the DOM when reusable components are nested (because “styling”), you’re wrong.

Very similar to early React where every component had to return a single real parent element (now you can return a fragment) so people chose div.

If a power tool is poorly designed it may not force me to hurt myself but if it makes it easier that’s a problem.

I’ve usability tested and performed user research with many users needing assistive tools and I’ve used them myself as part of design.

Basic HTML authoring is good practice for many reasons.

Side note: if you aren’t deliberately choosing semantic elements and instead dropping aria attributes onto a bunch of divs this is an anti-pattern.

They fixed this later with Fragments but the damage was done.

There is such a thing as the ergonomics of the tool. Yes div soup has been around a long time. But also yes, Tailwind makes the wrong approach the easy one.

It’s ergonomics encourage adding div elements to support styles. It’s the core design loop.

You’re conflating “forces to” and “ergonomically encouraged”.

Your comment only mentions developers as the audience of HTML authoring, as opposed to users, which is a common attitude and the core problem with Tailwind.

I think that upside became more prevalent in the reusable components era, whereas previously CSS was targeting an entire HTML file (and thus the reasoning was more like SQL query than "this one element's styling").

With LLMs I think this upside is much smaller now though.

I've been teaching semantic HTML / accessible markup for a long time, and have worked extensively on sites and apps designed for screen readers.

The biggest problem with Tailwind is that it inverts the order that you should be thinking about HTML and CSS.

HTML is marking up the meaning of the document. You should start there. Then style with CSS. If you need extra elements for styling at that point, you might use a div or span (but you should ask yourself if there's something better first).

Tailwind instead pushes the dev into a CSS-first approach. You think about the Tailwind classes you want, and then throw yet-another-div into the DOM just to have an element to hang your classes on.

Tailwind makes you worse as a web developer from a skill standpoint, since part of your skill should be to produce future-proof readable HTML and CSS that it usable by all users and generally matches the HTML and CSS specs. But devs haven't cared about that for years, so it makes sense that Tailwind got so popular. It solved the "I'm building React components" approach to HTML and CSS authoring and codified div soup as a desirable outcome.

Tailwind clearly never cared about any of this. The opening example on Tailwind's website is nothing but divs and spans. It's proven to be a terrible education for new developers, and has contributed to the div soup that LLMs will output unless nudged and begged to do otherwise.

Interesting but not “reimagining” anything.

I think the real story here is how vibe coding now enables flashy demo sites like this to be built for a concept that hasn’t yet earned it.

The irony is how difficult it is to read this obviously AI-generated article due to its unnatural prose and choppy flow full of LLM-isms. The ability to write is also a skill that atrophies.

Even when AI is understandably used due to language fluency, I’d prefer to read an AI translation over a generated article.

If you don’t care enough to write it, why should I care enough to read it?

The advancements required to arrive at modern LLMs and the tech needed to get humans safely to Mars or live safely on the Moon are orders of magnitude in difference.

Keeping humans alive is hard.