you're unfairly conflating things and putting the blame for a lack of care or understanding on tailwind vs on the dev themselves. nothing about tailwind forces you to build inaccessible or "div soup" apps

can tailwind be used poorly? absolutely. but that's true of any tool

i've been writing CSS for ~20 years and am quite capable with it, having used CSS, Less, SASS/SCSS, Stylus, PostCSS etc. the reason i have settled on Tailwind for the last few years is precisely because it enables me to build more robust application styling.

tailwind frees you from having to spend excessive time building abstractions of styles/classes that will invariably change. placing the styles directly into the markup that is affected by it reduces cognitive load, prevents excessively loose selectors affecting styles unintentionally and really aids in debugging. jumping into codebases with bespoke css frameworks is always more complex and fragile than a tailwind codebase for anything but the most simple sites/apps

add to that the ability to have consistent type, color and sizing scales, reduced bundle sizes, consistency for any developer who knows tailwind and a very robust ecosystem (and thus llms are very familiar with it) and tailwind is a really excellent choice for a lot of teams

tailwind is like most tools; it can be used well or poorly depending on who is using it

While I agree I do think there's some "aspiration of purity/correctness" in your approach that I've long let go of.

I look at the royal mess that is HTML/CSS/JS as a necessary evil, required when we want to target browsers. To me it's "just the presentation layer".

In my work I put a lot more emphasis on correctness in the db schema, or business logic in the backend.

When it comes to the messy presentation layer I prefer to write a little as possible, while still ending up with somewhat maintainable code. And for this Tailwind fits the bill really well: LLMs write it very well, new devs understand it quick, and it's quite easy to read-back/adjust the code later.

I 100% agree a Tailwind project is not the best way for a new dev to learn HTML/CSS. But then I prefer the new dev to focus on great db schemas, intuitive APIs, test-able biz logic, etc. Fiddling with the mess that's HTML/CSS is not the place where I consider human attention is best spent on (or where developers pick up skills to become much better developers).

> 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.

IMO this is the fundamental problem with HTML and CSS. You'll always have some part of the styling in the HTML due to needing extra divs and spans. At that point splitting the styling outside into the CSS splits your attention and Tailwind "solves" that by moving everything back into HTML.

Note that I don't like Tailwind, but I would rather have a way of styling that does not need to rely on the existance of extra divs and spans to work.

A few counterpoints:

Treating markup and styles separately is great, in principle, but you'll always need additional markup for certain things. We knew this going back to the early 2000s.

There is nothing about Tailwind itself that forces you to use divs and spans instead of the appropriate HTML tag.

Documents and interfaces are different. Tailwind makes a lot more sense for interfaces. You can use Tailwind for the interface and scoped HTML selectors for other content.

Tailwind is around 4x faster and has practically no overhead compared to writing a complex CSS codebase. Whatever you think of it, this is always a benefit in its corner.

Using tailwind doesn't lead to any inherent concession of accessibility. How do you come to that conclusion?

If I look at their component library, they also do the work of including aria attributes for you https://tailwindcss.com/plus/ui-blocks/marketing/sections/pr... (first exsmple with free code I've found).

If we're not talking landing pages, which are more like digital brochures, I always start with markup and then add css classes on top.

It's unfortunate Inverted Triangle CSS (ITCSS) isn't more popular. Instead of resisting the cascade, it embraces it and makes it work for the developer.

The summary: write your CSS in specificity order [1]:

    /scss/
    ├── 1-settings.         <- global settings
    ├── 2-design-tokens     <- fonts, colors, spacing, etc.
    ├── 3-tools             <- Sass mixing, CSS functions, etc.      
    ├── 4-generic           <- reset, box sizing, normalize, etc.
    ├── 5-elements          <- basic styles: headlines, buttons, links
    ├── 6-skeleton          <- layout grids, etc.
    ├── 7-components        <- cards, carousels, etc.
    ├── 8-utilities         <- utility and helper classes
    ├── _shame.scss         <- hacks to be fixed later    
    └── main.scss

[1]: https://matthiasott.com/notes/how-i-structure-my-css

I agree with the criticism of tailwind. IMO any good criticism warrants at least an opinion on what should be done instead or some corrective or remedial patterns.

there is a reason why tailwind got as popular as it is today. And it only highlights the gaps in either what HTML and CSS provide for the task at hand or the difficulty in that approach. This must not be lost in any criticism.

another observation is none of technical user interface decisions or discussion emphasis on the tree data structure that is inherent to every major user interface rendering mechanism relevant today. there are inherent benefits and drawbacks of it being a tree structure that neither of the developers nor the framework leverage. when thought of as a tree, it benefits from adding certain constraints and naming conventions that allow more artistic expression using just HTML and CSS that I have not seen tailwind or any other framework encourage

What's a good source to learn how to develop like this - to create HTML / CSS structure that's accessible?

EDIT: ignore. I can see you have some links in your profile. Will check it out.

You're not wrong, and I mostly agree with you. I die inside when I see the div soup that a lot of sites have become. However, I think there is value in being able to have the important parts of CSS merged into the HTML a bit. Where that line is, is certainly up for debate (and I don't have the answer), but I've found a lot of my tailwind sites are more readable to me than my pre-tailwind sites, often because I don't have to context-switch and open a different file to be able to reason about the styling on an element. For big stuff the second file can be nice, but there's a lot of style tweaking that is great to be able to do right there in the HTML. Tailwind does really lead you to ignore the css file though (or keep it highly minimal), which I agree is becoming an anti-pattern.

I find your comment quite refreshing.

25 years ago, I was appalled how Microsoft Frontpage could transform a very simple word document (with little formatting) into an utterly indecipherable mess of HTML that rendered correctly.

With very simple transformations, I could paste the text of the document into notepad and add just a few heading tags for the same rendered result but a much more understandable source.

CSS had a lot of promise for simplifying the HTML content, but the world tried its hardest to prevent that.

Now we have multi-megabyte monsters for simple webpages (before even counting graphics).

> 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.

To be fair plopping a `div` everywhere started way before Tailwind. I blame React and the mess that is CSS in JS for this.

HTML is marking up the meaning of the document. You should start there. Then style with CSS.

This is precisely how I do it.

Code that generates HTML. Once I can see all the content on the screen in some kind of Netscape Navigator 1.0 nightmare, then I go back and add styles to make it look pretty.

It's not hard. It just requires thought and planning.

(The best planning tool I've found is a pencil and grid paper, not the web design SaaS-of-the-moment. However, it's surprisingly hard to find good pencil sharpeners these days.)

> 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.

I wholeheartedly disagree. That mindset is not caused by Tailwind, but by being ignorant.

You can perfectly create an HTML document with semantic meaning and the add Tailwind just as any other CSS framework or pure CSS to it.

And DIVs do not carry meaning, they are specifically to add functionality or styling, so you can throw in as many as you like. Using them abundantly isn't good style, but the way you make it sound that they're evil isn't good either.

> 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're putting the cart before the horse. Or forgetting either the cart or the horse. Tailwind doesn't force anything. And "semantic HTML" or "semantic CSS" are not really a thing, and have as much bearing on how many divs a page has, as Tailwind.

And the reason is simple: there's literally nothing else in HTML than divs and spans. The amount of usable primitives is absolutely laughable, and trying to combine them in any useful manner results in as much soup with Tailwind as without Tailwind.

> 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.

Which part of Tailwind isn't readable, isn't future-proof, or doesn't match HTML and CSS specs?

How is "px-4" none of that, but ".ytp-big-mode.ytp-cards-teaser-dismissible .ytp-cards-teaser-label" (Youtube's CSS) or ".swg-button-v2-light[disabled]" (Washington Post) or "legacy-popover--arrow-end-bottom:after" (Spotify) are?

> The opening example on Tailwind's website is nothing but divs and spans.

Oh no! And what are the opening examples on any of the "proper pure-as-god-intended CSS" sites?

CSS is badly designed and uses a confusing, separate DSL with arbitrary rules designed before the Internet was widely used, before web apps existed, before smartphones etc

It's trash and throwing it out is good. Not learning it is good. Tailwind is a solution to a real problem.

More importantly, AI is good at it already and it's unlikely humans will need to understand HTML/CSS at all within a year or two. There's no reason to spend time learning how the gears work, just put the cover back on

It's worse than that; the common arguments for Tailwind literally derive from total ignorance of how CSS is made to work, and a disposal of guidelines that developers would worship in any other context (i.e. Don't Repeat Yourself).

It's really frustrating to be talking with someone about Tailwind and CSS, and realize that not only do they not know what "cascading" means, they never even considered the concept might be useful in the context of a stylesheet.

The more experienced Tailwind proponents probably have better things to do than get dragged into yet another online flamewar :) I've done tons of CSS since the 90s before looking into Tailwind. After it clicked, I've mostly tried to avoid raw CSS. In a sense, you exchange one mess for another. Personally, I'd rather deal with a localized class soup than trying to make sense of overlapping, often contradictory, cascades of styles across multiple files. Both can be implemented cleanly, but I'd much rather clean up a Tailwind mess than a CSS one. And I find the development process much more enjoyable overall.

You aren't wrong, but the _overwhelming_ majority of "full stack" devs I've worked with only know CSS at the most basic level and have little interest in learning it in depth. I myself have been programming for more than 20 years, doing web dev for almost 15, and I can't find the motivation to learn it well. There are too many technical skills to keep up with and CSS is pretty low down on my priority list. I would prefer to rely on specialists who are experts but companies aren't willing to hire dedicated front end devs.

Isn't Tailwind easy to understand when you look at the codebase, rather than putting in more effort to learn a pure CSS codebase? Isn't that part of the argument of Tailwind being easier to scale?

Isn't the same true of those who use a library that wraps SQL?

Personally, I'm not sure from my own dives into it that I'd still insist on bare CSS in a professional codebase any more than I'd insist on plain DOM manipulation. And I do at least see Tailwind classes as being a little less of a DSL than other, similar tools. But while I'm not going to be a purist about it at a workplace, I both agree with you and have noticed a layer even beyond your point: that overreliance on these things leads to not learning HTML beyond a junior level.

It gets really easy to lean on class-based CSS and use a `<div>` for everything instead of ever learning what a semantic element is.

And that contributes to other bad habits, like writing a bunch of JavaScript to define behavior that could just be natively handled by your browser.

A weird personal irony is that because no employer has ever asked me to directly write CSS, what's actually made me better at CSS is JavaScript -- namely that my understanding of selector logic has improved a lot after picking up Web scraping.

That’s the value of tailwind. You can just skip learning CSS and still get a good result. The benefit to learning it is marginal.

Sounds like a home made Tailwind of your own

Using a JavaScript framework kind of defeats the whole purpose doesn’t it?

Why did Svelte affect your stance towards Tailwind?

> It is confusing and takes time to get used to

I don’t believe Tailwind is inherently worse than pure CSS. If Tailwind had existed from day 1 on the web and you had learned it first you probably wouldn’t say this. In fact, if Tailwind had existed first somehow, and someone came up with CSS as we know it as a new revolutionary library, I’m not sure it would have succeeded.

_tailwind_ was the full circle. We had individual controls. We went to semantic controls, then back to individual controls a la tailwind.

Hope so. I’d like to be able to read the HTML templates again.

Yep. Every 7 years.

> putting all those utility classes as inline styling into my HTML is a crime against nature.

It’s really not when working with components instead of pages, and when working with variables properly

To be fair, CSS has evolved and improved A LOT in the past years, and a big reason why is Tailwind.

Because it’s a made up rule, not a law of nature. Having the styles inline on a component is very easy to reason about, it was just extremely impractical with CSS and the style attribute. Tailwind makes it easy, practical, and is actually well designed regarding its support for variables (ie. you can have a sane design system easily).

What you want to share/cascade is variables, not styles. Styling components makes it easy to make sure the styling of each component is isolated and doesn’t have unintended cascading effects. When working this way, using Tailwind is as much a good pattern than, say, CSS modules (which I like too).

To add: I dont want to go back to writing semantic css.. no thanks - I dont go in time-back machines. This is a mess.

Just using tailwind and anchoring around a design system like shadcn is just way easier for a team to align around than somebodys made up css language.

Vue single-file components (SFC[0]) still works this way.

    <template>
    <!-- Largely just HTML -->
    </template>

    <script setup lang="ts">
    // JS/TS as you would expect
    </script>

    <style scoped>
    /* Component scoped styles here */
    </style>

[0] Vue SFC docs: https://vuejs.org/guide/scaling-up/sfc.html

HTML is the content layer. CSS is the presentation layer.

There are different types of separation of concerns :) https://x.com/simonswiss/status/1664736786671869952

+1 for Pico CSS! It’s fantastic.

We actually loved it so much that we've taken over maintenance for a fork here: https://github.com/anyblades/pico

Can we stop with this kind of trash opinion? Do you genuinely believe people use Tailwind because they don’t know any better? I understand why many people have a visceral reaction against Tailwind when learning about it for the first time, but when you actually use it, you really can understand why some of the "anti-pattern" stuff you learned about CSS doesn’t really apply with Tailwind.

With Tailwind:

    <button class="bg-blue-600 text-white px-4 py-2 rounded">

    <button style="background-color: var(--color-blue-600); color: white; padding: 8px 16px; border-radius: 4px; border: none;">

    <button class="bg-blue-600 hover:bg-blue-500 active:bg-blue-700
      text-white px-4 py-2 rounded transition-colors
      focus:outline-none focus:ring-2 focus:ring-blue-400">

Even more interesting with Tailwind, a div with dark mode and responsive styles:

    <div class="
      bg-white dark:bg-zinc-900
      p-4 md:p-8
      rounded-xl
      shadow-sm dark:shadow-none
      border border-zinc-200 dark:border-zinc-700
    ">

Now your first instinct might be to "that’s unreadable", but keep in mind HOW you actually read and write this code. You’re not actually reading it to understand what it does like you do with iterative code. You see how the browser renders it, and you just adapt the code. Tailwind code is mostly write-only and maintained by viewing what the component looks like. This code doesn’t need to be reusable either, the whole component needs to be. The Tailwind code inside is unique.

It's much more verbose and can't do everything Tailwind can anyway.

E.g. how do you style a child on parent hover with the style attribute?

Can you clarify how this relates to Tachyons - do all Tachyons features work? Or is it a subset of Tachyons?

Layout design issues are orthogonal to choice of language and framework. You can apply the article's approach to plain static pages and to SPAs.

I tend to work closer to the latter end and find that both React and Typescript are extremely helpful to make my code extensible and maintainable. YMMV.

This makes no sense. LLMs and agents benefit from (good) abstraction as much as humans do.

This works great for small sites/apps, but really starts to fall apart if/when it gains complexity where React starts to make sense. I've tried a few times to "just use plain javascript" with the LLM and initial results are often much better, but if the site grows a bit too complex, the LLM starts making a lot of mistakes and it can be hard to reason about as a human and get it on the right track. That hasn't been the case with the React apps IME.

React maybe (because there are alternatives).

But for mid/large projects, I find that TypeScript brings sanity to JavaScript.

I love some quick and dirty JS project. But after a certain project size I begin the see runtime errors like undefined, NaN, 'false/true' concatedted to URLs, and so on. TypeScript eliminates a ton of those.

Why write in rust if LLM can write assembler for any architecture?

What a strange take. LLMs produce plausibly correct output, which is exactly where plain JavaScript and DOM manipulation will result in a spaghetti mess.

Frameworks like React that add structure to the data flow, component encapsulation, and a huge repertoire of patterns to train on, plus Typescript for immediate compile-time feedback loops… those are what LLMs thrive on.

I agree, specially for simple apps. it's much easier to upgrade if you are not relying on 3rd party or NPM's. Don't have to worry about code injections.

I have these two https://reddit.premii.com and https://hn.premii.com/ both works without any changes. Reddit will stop working once they kill the apis but until then it will work.

> just have the LLM setup whatever dom manipulation you want and have it write decent JS without slop.

Hmm, yes, simply have the LLM write good with no mistakes.

I hope I never have to work with you.