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

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.

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.

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.

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

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.

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

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?

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.

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

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.

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

Why did Svelte affect your stance towards Tailwind?

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

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

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

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.

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.