> I got curious about what writing more semantic HTML would feel like.
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.
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
> nothing about tailwind forces you to build inaccessible or "div soup" apps
Totally agree. I feel like this was more a by product of React. Not that React forced this either, but it felt like the rise in both went hand in hand for some reason.
While I think it's true that none of the current top FE technologies force the div soup, they don't discourage it either. It would be nice if what ever FE technologies catch on next did try to encourage better practices around things like accessibility. Make the path of least semantic HTML the path of least resistance and allow people to fall into the pit of success, ya know?
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
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).
This isn't about "purity/correctness" it's about the real experience of a blind person. Accessibility means caring about the HTML.
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 use Tailwind and have all kinds of "screen reader" directives in my templates.
Not sure if it helps, but if we get our first blind user I will gladly make some admends to make it more usable for them.
It seems that Tailwind is now blamed for the mess that is HTML/CSS. Tailwind certainly allows for accessible designs; it may not be the ideal solution, sure, but what we aim for is "good enough".
> but if we get our first blind user I will gladly make some admends to make it more usable for them.
Isn't this slightly backwards? Why would blind users sign up if the platform isn't usable for them in the first place? It has to be usable for them for them to become users :)
It's not just blind people, but also people with reduced eyesight. As I'm getting older, I really appreciate good contrast and the possibility to zoom in without breaking the layout.
if we get our first blind user I will gladly make some admends to make it more usable for them.
Not good enough. You have to be accessible before it is needed in order to avoid legal liability.
And how do you expect to get a blind user if they already cannot use your product?
None of the doctors I build web sites for are currently blind. I know this because I talk to them regularly. But I still build the web sites for the future, when HR might hire a doctor or nurse or other person who is blind, or partially sighted, or has trouble with their muscles, or has difficulty distinguishing colors.
Doing the right thing isn't that hard. Not doing it is just lazy.
We use tailwind and are capable of building accessible websites without any issue. People could make all the same mistakes with CSS for accessibility. It’s the not knowing how to make accessible content that leads to inaccessible content, not the tool you use to implement the styling.
You call it lazy. I call it "focus" or avoiding pre-mature optimization.
I find the "legal liability" claim hilarious... I do better than 95% of the web: as I said I HAVE some screen reader directives (just did not test it), and labels to make the app more accessible.
Sounds like you're kind of just talking your book though. Person who makes accessible sites suggests you need an accessible site. Blind people aren't the only ones who might need modifications. You could have an infinitely long list of adjustments for all kinds of disabilities, and tell me I'm lazy for not doing each of them. Why are blind people special?
You are lazy for not doing accessibility adjustments, because accessibility isn't for blind users. It's for the deaf ones, the ones with poor eyesight, the ones with mental deficiencies, the ones with motor issues like Parkinson's, the ones browsing your site shitfaced at 4AM, and so on and so on.
Accessibility isn't a checklist to cover your ass for a percentage of the population: it's for everyone. It literally makes your website less shit. You slapping an aria-label doesn't fix things.
Every moment you spend doing accessibility is a moment you spend not doing other things. You could argue it has a high RoI to do accessibility, fine, but that doesn't make it lazy _not_ to do it. Maybe I have even higher RoI/EV stuff to be doing.
What does Tailwind have to do with accessibility? Most significant HTML markup is block level elements. The CSS is completely orthogonal.
I feel like old-school frontend devs bring up accessibility as a kind of bogeyman.
It reminds me of the myth that CSS style X or Y breaks accessibility "because screen readers expect semantic CSS classes". Zeldman (of A List Apart) promulgated that disinformation for years, until someone actually told him screen readers don't work that way. 90% of people who use a11y as a rhetorical cudgel have never actually used AT themselves.
But why would I spend any time mastering this skill when we have AI now?
Disability software that uses both the markup and the on-screen visual for decision making is likely imminent and would render most of this no longer necessary.
Claude Cowork is already doing navigation and web browsing by screenshot showing this is possible.
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.
As someone who wrote CSS for 20 years and who was against using Tailwind because of “principles” I must say that Tailwind is just awesome. Every minute spent trying to make sense of the structure past you or your colleagues came up with is a minute that could be spent on something more important.
Every time someone says that Tailwind sucks, it’s like hearing the old me speak.
Same here. It’s super weird take to me now. Maybe if you’re just writing plain HTML and CSS tailwind would be worse, but assuming there’s a component system you’re going to be just fine. The cascade of CSS is such a foot gun. Localized styles work great and tailwind abstracts away hardcoded values with relative ones
> 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.
Divitis was a thing long before React came along. It was a common solution to styling problems even in the jQuery/Dojo days. Getting stuff to look similar across IE6 and FF before CSS3 relied heavily on divs.
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.
The "open a different file" reasoning piece is a common pro-Tailwind statement and I do see the upsides.
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 don't have to context-switch and open a different file to be able to reason about the styling on an element
Unless you're coding on a VT100 terminal, you just put the HTML in one window and the CSS in another. Subdivide as necessary, or as your monitor space allows.
Heck, we were doing that back in 1989 on IBM PCs with MDA displays.
If your CSS is so out of control that you can't wrap your brain around it, it's time to refactor or split into individual CSS component files.
It seems that everyone is forgetting the web inspector as a tool for designing web pages. You can tweak properties and styles in a live environment, and then transfer your preferences to the css files.
> 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?
> 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.
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.)
One thing that has always struck me about Tailwind is that practically every argument its proponents use more or less boils down to “I never learnt CSS beyond a junior level”. It’s super common to hear Tailwind advocates say things like “Without Tailwind, we would just have one big disorganised CSS file that always grows uncontrollably and ends up with loads of obsolete stuff in it and !important everywhere! Tailwind is so much better!”.
CSS is a skill just like any other technical skill. If all you do is learn the bare minimum so you can bodge things until you get something that looks right, then your ambitions are going to outpace your ability to keep things organised very quickly.
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 common arguments against Tailwind usually derive from total ignorance of working with CSS on large scale projects with many team members.
And when this is pointed out you’ll usually get replies that just hand wave it away as not a problem, as if things like BEM were invented for no reason.
And the cascading thing is a nightmare even after years.
Whenever i have written CSS/TailwindCSS which was unproblematic to extend it was when i literally switch thinking to use least amount of properties and let the page flow.
Whenever i see tons of css i know it’s brittle and will cause hours of wasted time down the line to fix something which already should have been fixed.
What, exactly, is the "nightmare" that "the cascading thing" is causing for you? Is it the concept of inheritance? Is it that more specific rules override more general ones?
Because there's not much else to it, really.
> Whenever i see tons of css i know it’s brittle and will cause hours of wasted time down the line to fix something which already should have been fixed.
Look, you're basically arguing that other developers produce spaghetti code in CSS -- an argument that I sympathize with! -- but tailwind is just as bad, if not worse. Any moderately complex pile of tailwind-based UI ends up an inconsistent mish-mash of half-styled elements and spaghetti code where a developer was banging rocks together trying to center a div without understanding divs (or rocks). The only thing you can really say for it is that it minimizes the blast radius of incompetence.
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?
For me Svelte and LLM completely removed my need for Tailwind. Turns out I was using it primarily to avoid CSS collision, and (to me) more logical syntax, rather than the self-imposed constraints.
I think the (misuse of) so-called "separation of concerns" has been the most harmful thing that happened in web front end development. HTML can CSS are the same kind of concerns: the presentation layer. The idea that HTML is purely semantic and has nothing to do with presentation is just burying the head in the sand.
Separating HTML and CSS into different files is just like separating a bunch of methods/functions into different files, or splitting one monorepo into git submodules. Yeah, it sometimes makes sense, but if you're doing it for the sake of separating things then just stop.
I think the only point of Tailwind is to make front end devs realizing how much separation of concerns is misunderstood and misused as a dogma. Once you realize that you can ditch Tailwind if you like.
Tailwind crazy adoption is something that makes me happy to nowadays be doing mainly boring stuff in distributed cloud systems and agents, instead of WebUIs.
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>
Very clean, easy to understand, and (as someone who started hand writing DHTML) it still feels very much like DHTML with more convenience and modern affordances.
Trash article and absolutely pathetic comments here. Downvote as much as you want, idc, but people who don't understand what utility classes are in Tailwind and what power they bring should read the docs instead of talking.
Relying on React or Typscript in LLM era seems very stupid, just have the LLM setup whatever dom manipulation you want and have it write decent JS without slop. Far more offline compatible development almost negligible supply chain issues as well. At least ones you can control.
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.
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.
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.
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.
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 got curious about what writing more semantic HTML would feel like.
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.
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
> nothing about tailwind forces you to build inaccessible or "div soup" apps
Totally agree. I feel like this was more a by product of React. Not that React forced this either, but it felt like the rise in both went hand in hand for some reason.
While I think it's true that none of the current top FE technologies force the div soup, they don't discourage it either. It would be nice if what ever FE technologies catch on next did try to encourage better practices around things like accessibility. Make the path of least semantic HTML the path of least resistance and allow people to fall into the pit of success, ya know?
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
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).
This isn't about "purity/correctness" it's about the real experience of a blind person. Accessibility means caring about the HTML.
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 use Tailwind and have all kinds of "screen reader" directives in my templates.
Not sure if it helps, but if we get our first blind user I will gladly make some admends to make it more usable for them.
It seems that Tailwind is now blamed for the mess that is HTML/CSS. Tailwind certainly allows for accessible designs; it may not be the ideal solution, sure, but what we aim for is "good enough".
> but if we get our first blind user I will gladly make some admends to make it more usable for them.
Isn't this slightly backwards? Why would blind users sign up if the platform isn't usable for them in the first place? It has to be usable for them for them to become users :)
It's not just blind people, but also people with reduced eyesight. As I'm getting older, I really appreciate good contrast and the possibility to zoom in without breaking the layout.
And how does tailwind or the structure of the underlying html of the page change or affect that?
if we get our first blind user I will gladly make some admends to make it more usable for them.
Not good enough. You have to be accessible before it is needed in order to avoid legal liability.
And how do you expect to get a blind user if they already cannot use your product?
None of the doctors I build web sites for are currently blind. I know this because I talk to them regularly. But I still build the web sites for the future, when HR might hire a doctor or nurse or other person who is blind, or partially sighted, or has trouble with their muscles, or has difficulty distinguishing colors.
Doing the right thing isn't that hard. Not doing it is just lazy.
We use tailwind and are capable of building accessible websites without any issue. People could make all the same mistakes with CSS for accessibility. It’s the not knowing how to make accessible content that leads to inaccessible content, not the tool you use to implement the styling.
You call it lazy. I call it "focus" or avoiding pre-mature optimization.
I find the "legal liability" claim hilarious... I do better than 95% of the web: as I said I HAVE some screen reader directives (just did not test it), and labels to make the app more accessible.
Sounds like you're kind of just talking your book though. Person who makes accessible sites suggests you need an accessible site. Blind people aren't the only ones who might need modifications. You could have an infinitely long list of adjustments for all kinds of disabilities, and tell me I'm lazy for not doing each of them. Why are blind people special?
You are lazy for not doing accessibility adjustments, because accessibility isn't for blind users. It's for the deaf ones, the ones with poor eyesight, the ones with mental deficiencies, the ones with motor issues like Parkinson's, the ones browsing your site shitfaced at 4AM, and so on and so on.
Accessibility isn't a checklist to cover your ass for a percentage of the population: it's for everyone. It literally makes your website less shit. You slapping an aria-label doesn't fix things.
Every moment you spend doing accessibility is a moment you spend not doing other things. You could argue it has a high RoI to do accessibility, fine, but that doesn't make it lazy _not_ to do it. Maybe I have even higher RoI/EV stuff to be doing.
Accessibility is done while you do it. Not as an afterthought.
But if you're having a higher ROI writing absolute crap, feel free, it's not my website.
What does Tailwind have to do with accessibility? Most significant HTML markup is block level elements. The CSS is completely orthogonal.
I feel like old-school frontend devs bring up accessibility as a kind of bogeyman.
It reminds me of the myth that CSS style X or Y breaks accessibility "because screen readers expect semantic CSS classes". Zeldman (of A List Apart) promulgated that disinformation for years, until someone actually told him screen readers don't work that way. 90% of people who use a11y as a rhetorical cudgel have never actually used AT themselves.
But why would I spend any time mastering this skill when we have AI now?
Disability software that uses both the markup and the on-screen visual for decision making is likely imminent and would render most of this no longer necessary.
Claude Cowork is already doing navigation and web browsing by screenshot showing this is possible.
I guarantee you no one is working on this.
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.
Benchmarks?
As someone who wrote CSS for 20 years and who was against using Tailwind because of “principles” I must say that Tailwind is just awesome. Every minute spent trying to make sense of the structure past you or your colleagues came up with is a minute that could be spent on something more important.
Every time someone says that Tailwind sucks, it’s like hearing the old me speak.
Same here. It’s super weird take to me now. Maybe if you’re just writing plain HTML and CSS tailwind would be worse, but assuming there’s a component system you’re going to be just fine. The cascade of CSS is such a foot gun. Localized styles work great and tailwind abstracts away hardcoded values with relative ones
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.
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.
> 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.
Divitis was a thing long before React came along. It was a common solution to styling problems even in the jQuery/Dojo days. Getting stuff to look similar across IE6 and FF before CSS3 relied heavily on divs.
It did for sure. And Tailwind absolutely doesn’t need to be done this way. I think this is a correlation-not-causation issue
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.
The "open a different file" reasoning piece is a common pro-Tailwind statement and I do see the upsides.
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 don't have to context-switch and open a different file to be able to reason about the styling on an element
Unless you're coding on a VT100 terminal, you just put the HTML in one window and the CSS in another. Subdivide as necessary, or as your monitor space allows.
Heck, we were doing that back in 1989 on IBM PCs with MDA displays.
If your CSS is so out of control that you can't wrap your brain around it, it's time to refactor or split into individual CSS component files.
Maybe even split it into a set of small reusable coherent utility classes
It seems that everyone is forgetting the web inspector as a tool for designing web pages. You can tweak properties and styles in a live environment, and then transfer your preferences to the css files.
> 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?
> 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.
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.)
A life framework, consensus, that how the man face the thing that they crafting.
One thing that has always struck me about Tailwind is that practically every argument its proponents use more or less boils down to “I never learnt CSS beyond a junior level”. It’s super common to hear Tailwind advocates say things like “Without Tailwind, we would just have one big disorganised CSS file that always grows uncontrollably and ends up with loads of obsolete stuff in it and !important everywhere! Tailwind is so much better!”.
CSS is a skill just like any other technical skill. If all you do is learn the bare minimum so you can bodge things until you get something that looks right, then your ambitions are going to outpace your ability to keep things organised very quickly.
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 common arguments against Tailwind usually derive from total ignorance of working with CSS on large scale projects with many team members.
And when this is pointed out you’ll usually get replies that just hand wave it away as not a problem, as if things like BEM were invented for no reason.
Yeah, that's a straw-man. I've worked on large-scale projects with many team members, and it's perfectly possible to use CSS as it was designed.
But sure, like most tools, it starts with understanding how it works.
And the cascading thing is a nightmare even after years.
Whenever i have written CSS/TailwindCSS which was unproblematic to extend it was when i literally switch thinking to use least amount of properties and let the page flow.
Whenever i see tons of css i know it’s brittle and will cause hours of wasted time down the line to fix something which already should have been fixed.
What, exactly, is the "nightmare" that "the cascading thing" is causing for you? Is it the concept of inheritance? Is it that more specific rules override more general ones?
Because there's not much else to it, really.
> Whenever i see tons of css i know it’s brittle and will cause hours of wasted time down the line to fix something which already should have been fixed.
Look, you're basically arguing that other developers produce spaghetti code in CSS -- an argument that I sympathize with! -- but tailwind is just as bad, if not worse. Any moderately complex pile of tailwind-based UI ends up an inconsistent mish-mash of half-styled elements and spaghetti code where a developer was banging rocks together trying to center a div without understanding divs (or rocks). The only thing you can really say for it is that it minimizes the blast radius of incompetence.
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 Tailwind easy to understand when you look at the codebase, rather than putting in more effort to learn a pure CSS codebase?
No, I don’t think that’s the case at all.
Isn't that part of the argument of Tailwind being easier to scale?
I think that was true at the beginning. But Tailwind is quickly approaching the multi-headed hydra it was trying to replace.
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.
Isn't the same true of those who use a library that wraps SQL?
I have been writing a "clean" web development guide focusing on writing HTML and CSS that scales well: https://webdev.bryanhogan.com/
Maybe it's useful for people here. I don't use Tailwind or similar for styling, just CSS with modern frameworks like Astro or Svelte.
For every project I have the following CSS files:
- reset.css
- var.css
- global.css
- util.css
Other styling is scoped to that specific component or layout.
Using a JavaScript framework kind of defeats the whole purpose doesn’t it?
css modules with react are really nice to work with. Plain css scoped to a component. The two arnt always at odds
For me Svelte and LLM completely removed my need for Tailwind. Turns out I was using it primarily to avoid CSS collision, and (to me) more logical syntax, rather than the self-imposed constraints.
Why did Svelte affect your stance towards Tailwind?
Presumably because you just put the styles in the component.
I think the (misuse of) so-called "separation of concerns" has been the most harmful thing that happened in web front end development. HTML can CSS are the same kind of concerns: the presentation layer. The idea that HTML is purely semantic and has nothing to do with presentation is just burying the head in the sand.
Separating HTML and CSS into different files is just like separating a bunch of methods/functions into different files, or splitting one monorepo into git submodules. Yeah, it sometimes makes sense, but if you're doing it for the sake of separating things then just stop.
I think the only point of Tailwind is to make front end devs realizing how much separation of concerns is misunderstood and misused as a dogma. Once you realize that you can ditch Tailwind if you like.
So, we're just going a full circle back now. Interesting.
_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.
Tailwind crazy adoption is something that makes me happy to nowadays be doing mainly boring stuff in distributed cloud systems and agents, instead of WebUIs.
Oh, have we reached the end of the pendulum swing and are now swinging back to ordinary CSS again.
Curious if you noticed any performance differences after switching — did bundle size or load times change at all?
oh is this stupid hype of defining design in html with a random framework finally over? thank god!
I'm lucky to have learned the web with Angular 2.x
It scopes CSS to components by default, and keeps HTML, CSS and JavaScript seperate.
Vue single-file components (SFC[0]) still works this way.
Very clean, easy to understand, and (as someone who started hand writing DHTML) it still feels very much like DHTML with more convenience and modern affordances.[0] Vue SFC docs: https://vuejs.org/guide/scaling-up/sfc.html
tailwind is an anti-pattern that breaks separation of concerns rule. i'm amazed how it became so popular.
I am so happy that the only time I have to touch css anymore is for simple internal tools and pico is usually enough for them.
Trash article and absolutely pathetic comments here. Downvote as much as you want, idc, but people who don't understand what utility classes are in Tailwind and what power they bring should read the docs instead of talking.
Nature is healing
Thats why I maintain the successor to tachyons: https://tachyonsneo.com No build pipeline. Resort to CSS when utilites make no sense. No lock in.
Can you clarify how this relates to Tachyons - do all Tachyons features work? Or is it a subset of Tachyons?
What I don't get about tailwind is: why not just use the style attribute at the point?
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?
Relying on React or Typscript in LLM era seems very stupid, just have the LLM setup whatever dom manipulation you want and have it write decent JS without slop. Far more offline compatible development almost negligible supply chain issues as well. At least ones you can control.
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.
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.
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.
This makes no sense. LLMs and agents benefit from (good) abstraction as much as humans do.
I hope I never have to work with you.
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.
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.