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.
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.
> 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
The problem with tailwind is that semantic HTML should be entirely free of styling decisions in the ideal case. That also goes for styling classes like flex flex-col etc.
The way I would do it is to give the HTML some semantic meaning:
<section class="info-for-nerds">...</section>
We can then decide how to treat section.info-for-nerds. Someone who reads the HTML immediately knows that this section is the bit that gives slightly too much information for nerds. That is what semantic means. The class adds meaning in a semantic sense, that helps to interpret the purpose of the element.
Then in CSS you would just style the semantic.info-for-nerds text fully with flex, flex-col, the whole shabang. If there are other info boxes that share style adding a general info-box class is probably a good idea. Again, this is semantic. I don't say red-box. I say what the box is intended to mean, not how it looks.
If you need the Infobox to look different in another context (or want to be sure your selector doesn't leak) you use the cascading bit of the language;
Notice btw. that I also prefer to use semantic HTML elements like section, article, main, aside over generic ones like div. Using these well may even mean you don't need any classes at all. If you have three nested divs classes are the only way to k ow which one is the article. If you have main containing article containing section, that may literally be all the info you need.
> “…nothing about tailwind forces you to build inaccessible or "div soup" apps
can tailwind be used poorly? absolutely.
[…]
tailwind is like most tools; it can be used well or poorly depending on who is using it.”
Hmm. Your reply refutes the div-soup accusation, but doesn’t provide any explanation.
> 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
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).
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
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
ITCSS basically does away with specificity wars in a CSS codebase. Usually the only place !important is the utility layer.
> 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.
I agree. I don't really like Tailwind, nor similar CSS frameworks. The whole idea was to separate styling from HTML, and Tailwind is putting it back into HTML through the backdoor. It's just a way to do styling from your HTML without having to touch the CSS, by inserting styling info in your HTML. That's exactly what we were trying to move away from.
It does make that easier for people to choose to do, but I would argue that it shouldn’t be held against tailwind that people do this. Also, sorry, but I’m doubtful that when using CSS that no markup would be changed to better accommodate the final layout…just like tailwind?
If the first tool in your tool chest is to change the markup, then it doesn’t matter which method of styling you apply. If your first goal is clean markup and accessibility…then It doesn’t matter which method of styling you apply.
Yeah, while you certainly can write semantic HTML with Tailwind, it absolutely doesn't encourage it. It's funny how Tailwind is conceptually going back to inline styles.
But sure, if you have <Title>, <Header> and <Button> components etc. instead of using HTML elements <h1>, <header>, <button> etc. directly, then why not stuff the CSS into the components as well? It all depends on whether you prefer to use components, HTML elements or a combination as your favourite abstraction.[0]
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.
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.
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.
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.
I should probably note a detail I left out here: I myself care a lot about standards, and simply am stating that I wouldn't push teams around me to suddenly drop Tailwind even if I personally would rather not have to rely on things like it everywhere. Less that my opinion goes away and more that I don't presume it's the only valid option at scale.
But in my personal projects, I myself have just stopped using libraries entirely for styling.
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.
Your comment is getting downvotes, not necessarily because you are wrong, but 1) CSS is indeed hard, complex and often confusing, which is partly why Tailwind exists in the first place 2) your comment points out some inconvenient facts, and people don't like that
"beyond a junior level" -- I doubt this will change your mind, but this post is from the author of Tachyons, a "pre-Tailwinds" competitor that didn't get the same traction:
And the tldr is that he downloaded and read the CSS for several major websites at the time (post is from 2016) and they were all hodge-podge of terribleness.
Maybe all the devs writing that CSS were junior, but imo it's more than CSS just doesn't have the abstractions to match the level of OCD/bespokeness that designers spec into every Figma -- move this box by _this_ much / _that_ much / etc.
I'm a big hater of Tailwind but also know that most CSS out there is an absolutely clusterf of outdated rules and !important wars. There's no winning when some dude jumps into the codebase and fixes a bug by adding margin-right to "p"
CSS linters never really picked up steam and even with them, what's lintable is quite limited.
Do you have an actual list of arguments with the steps you take to boil them down to ignorance?
CSS is a design system, as like any system it can be poorly designed. Poorly designed systems require more effort to operate, and you can even call that "skills", but that just ignores the core issue of comparing design of those systems
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.
I'm a fan of removing any dependencies on external libraries and writing my own solution from scratch, but there's a good reason why I decided not to do so with Tailwind: They offer an optimization for production that ensures that you never ship more than the bare minimum of CSS needed. This means you can keep your palette of color, spacing, and other options fully enumerated in `globals.css` and elsewhere, without worrying whether you're using all those variants in production. Moreover, if you're working within a framework, such as Next.js, this minimization step automatically happens when you build, without even having to worry about whether it's happening. This alone is a compelling reason, at least for me, not to migrate from Tailwind.
Also, I've never found any restrictions in Tailwind in using inline CSS that weren't readily navigable, or in implementing really nice responsive grids that handle different screen widths for instance using Tailwind's grid tooling. I definitely have solved each of the scenarios described in this article using Tailwind or a Tailwind-CSS combination, but it's true that they don't have grid-column-areas natively. Still, I haven't yet found that to be a significant restriction in getting responsive grid layouts.
I think the biggest issue with Tailwind is simply that it takes a long time to get used to reading it. We all learn that inline CSS is bad, globally scoped CSS is best, etc., and we get used to seeing clean simple HTML. Then we look at real-world code featuring Tailwind and it just looks so hard to read at first, especially because the lines are so long. I guess I just have been using it long enough that I've gotten completely used to the way it looks, but I do remember it took me a very long time to get comfortable with reading Tailwind. After a long while, I concluded that, for me, Tailwind really is more efficient and maintainable and even more readable, but it definitely took quite a bit.
She writes from a place of vulnerability and honesty. Most people write to sound smart and she writes to say "I don't know it all but there are some things I discovered I want to share." I almost feel like she writes to share things with people she loves, even though she doesn't know them directly.
She spoke alongside Randall Munroe at the last Strange Loop (RIP). Some people waited to talk to him afterwards, but I waited to talk to her. I don't think she got my joke that she should rewrite her bash scripts into perl and for that I'm truly sorry.
css applies attributes to objects via graph queries
the queries are tightly coupled to the tree. you must work hard to avoid scatter gun edits now. it doesn't make much sense to have attributes stores in a separate location to their use
it would be like assigning all of your instances attributes using decorators
111 comments
[ 5.1 ms ] story [ 86.8 ms ] threadBut 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.
Hmm, yes, simply have the LLM write good with no mistakes.
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.
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.
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
The way I would do it is to give the HTML some semantic meaning:
We can then decide how to treat section.info-for-nerds. Someone who reads the HTML immediately knows that this section is the bit that gives slightly too much information for nerds. That is what semantic means. The class adds meaning in a semantic sense, that helps to interpret the purpose of the element.Then in CSS you would just style the semantic.info-for-nerds text fully with flex, flex-col, the whole shabang. If there are other info boxes that share style adding a general info-box class is probably a good idea. Again, this is semantic. I don't say red-box. I say what the box is intended to mean, not how it looks.
If you need the Infobox to look different in another context (or want to be sure your selector doesn't leak) you use the cascading bit of the language;
Notice btw. that I also prefer to use semantic HTML elements like section, article, main, aside over generic ones like div. Using these well may even mean you don't need any classes at all. If you have three nested divs classes are the only way to k ow which one is the article. If you have main containing article containing section, that may literally be all the info you need.Hmm. Your reply refutes the div-soup accusation, but doesn’t provide any explanation.
> 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?
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
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).
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
The summary: write your CSS in specificity order [1]:
ITCSS basically does away with specificity wars in a CSS codebase. Usually the only place !important is the utility layer.[1]: https://matthiasott.com/notes/how-i-structure-my-css
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.
If the first tool in your tool chest is to change the markup, then it doesn’t matter which method of styling you apply. If your first goal is clean markup and accessibility…then It doesn’t matter which method of styling you apply.
Is this true at all anymore, except for SEO optimized sites/content?
For apps, it’s all layout, isn’t it — and HTML, JS, CSS have all evolved heavily to support UI-first, haven’t they?
But sure, if you have <Title>, <Header> and <Button> components etc. instead of using HTML elements <h1>, <header>, <button> etc. directly, then why not stuff the CSS into the components as well? It all depends on whether you prefer to use components, HTML elements or a combination as your favourite abstraction.[0]
[0]: https://mastrojs.github.io/blog/2025-11-27-why-not-just-use-...
It scopes CSS to components by default, and keeps HTML, CSS and JavaScript seperate.
We actually loved it so much that we've taken over maintenance for a fork here: https://github.com/anyblades/pico
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 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.
But in my personal projects, I myself have just stopped using libraries entirely for styling.
https://mrmrs.cc/writing/scalable-css/
And the tldr is that he downloaded and read the CSS for several major websites at the time (post is from 2016) and they were all hodge-podge of terribleness.
Maybe all the devs writing that CSS were junior, but imo it's more than CSS just doesn't have the abstractions to match the level of OCD/bespokeness that designers spec into every Figma -- move this box by _this_ much / _that_ much / etc.
CSS linters never really picked up steam and even with them, what's lintable is quite limited.
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.
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.
I'm a fan of removing any dependencies on external libraries and writing my own solution from scratch, but there's a good reason why I decided not to do so with Tailwind: They offer an optimization for production that ensures that you never ship more than the bare minimum of CSS needed. This means you can keep your palette of color, spacing, and other options fully enumerated in `globals.css` and elsewhere, without worrying whether you're using all those variants in production. Moreover, if you're working within a framework, such as Next.js, this minimization step automatically happens when you build, without even having to worry about whether it's happening. This alone is a compelling reason, at least for me, not to migrate from Tailwind.
Also, I've never found any restrictions in Tailwind in using inline CSS that weren't readily navigable, or in implementing really nice responsive grids that handle different screen widths for instance using Tailwind's grid tooling. I definitely have solved each of the scenarios described in this article using Tailwind or a Tailwind-CSS combination, but it's true that they don't have grid-column-areas natively. Still, I haven't yet found that to be a significant restriction in getting responsive grid layouts.
I think the biggest issue with Tailwind is simply that it takes a long time to get used to reading it. We all learn that inline CSS is bad, globally scoped CSS is best, etc., and we get used to seeing clean simple HTML. Then we look at real-world code featuring Tailwind and it just looks so hard to read at first, especially because the lines are so long. I guess I just have been using it long enough that I've gotten completely used to the way it looks, but I do remember it took me a very long time to get comfortable with reading Tailwind. After a long while, I concluded that, for me, Tailwind really is more efficient and maintainable and even more readable, but it definitely took quite a bit.
She writes from a place of vulnerability and honesty. Most people write to sound smart and she writes to say "I don't know it all but there are some things I discovered I want to share." I almost feel like she writes to share things with people she loves, even though she doesn't know them directly.
She spoke alongside Randall Munroe at the last Strange Loop (RIP). Some people waited to talk to him afterwards, but I waited to talk to her. I don't think she got my joke that she should rewrite her bash scripts into perl and for that I'm truly sorry.
css applies attributes to objects via graph queries
the queries are tightly coupled to the tree. you must work hard to avoid scatter gun edits now. it doesn't make much sense to have attributes stores in a separate location to their use
it would be like assigning all of your instances attributes using decorators