Why I don't like Tailwind CSS(aleksandrhovhannisyan.com)
aleksandrhovhannisyan.com
Why I don't like Tailwind CSS
https://www.aleksandrhovhannisyan.com/blog/why-i-dont-like-tailwind-css
313 comments
I never got the point of Tailwind: having an element with utility classnames on it that each add one CSS rule, like class="flex flex-wrap" doesn't seem any better than just having the equivalent inline styles on it. Sure, the Tailwind utility classes are shorter, but the abstraction doesn't simplify anything. It's just some set of aliases you'll need to have memorized, and it's just moving the one-off combining of styles from the inline style property to the class property. It seems like something built to superficially follow the common wisdom of avoiding overusing inline styles.
I want to echo the author's recommendation of styled-jsx. I've been using it with React for a few years now and love it. Like Tailwind, the styling is conveniently co-located with your elements, but it's just regular CSS properties with their full power instead of a set of aliases crammed into the class property. It also encapsulates the styles to the component's own elements by default, which is very good at encouraging making encapsulated components. The codebase I'm working on used to have a mess of CSS files, and CSS files for various screens often messed with the internal styling of common components used within the screen which would regularly cause us surprises whenever we updated those common components without realizing how they were abused across the application. Now that we're using styled-jsx, proper component-level encapsulation is enforced by default, and it really helps guide us toward making the components themselves be responsible for their own styling needs, which keeps things much more understandable and more local with less "spooky action at a distance" (external styles modifying the component's internals).
I want to echo the author's recommendation of styled-jsx. I've been using it with React for a few years now and love it. Like Tailwind, the styling is conveniently co-located with your elements, but it's just regular CSS properties with their full power instead of a set of aliases crammed into the class property. It also encapsulates the styles to the component's own elements by default, which is very good at encouraging making encapsulated components. The codebase I'm working on used to have a mess of CSS files, and CSS files for various screens often messed with the internal styling of common components used within the screen which would regularly cause us surprises whenever we updated those common components without realizing how they were abused across the application. Now that we're using styled-jsx, proper component-level encapsulation is enforced by default, and it really helps guide us toward making the components themselves be responsible for their own styling needs, which keeps things much more understandable and more local with less "spooky action at a distance" (external styles modifying the component's internals).
I feel like an old man yelling at clouds, but I actually like CSS, with classes, specifity, and the cascade.
Maybe the difference is that other people build apps with lots of components. When I write HTML I mostly build web pages - a lot of text, some images, and maybe a menu.
I need to be able to tweak properties among a lot of different elements at the same time. E.g. change the font face on all elements in the main area, change the color of all links that are not special links, rotate all titles and underline them, and so on. It's an iterative approach, as I evolve the design in HTML (I don't have a designer team that hands me a psd I just have to copy). To do this with Tailwind, you'd have to use components, and you'd have to add another layer of abstraction to affect the right components together.
And I know nobody really uses CSS Zen Garden style themes - but it is great to be able to take a HTML snippet and use it in another project with minimal changes and a different CSS design.
CSS has shortcomings - it's missing a way to "include", it could have more complex selectors, it can get unwieldy in larger projects - but it is also does a couple of things really well.
Maybe the difference is that other people build apps with lots of components. When I write HTML I mostly build web pages - a lot of text, some images, and maybe a menu.
I need to be able to tweak properties among a lot of different elements at the same time. E.g. change the font face on all elements in the main area, change the color of all links that are not special links, rotate all titles and underline them, and so on. It's an iterative approach, as I evolve the design in HTML (I don't have a designer team that hands me a psd I just have to copy). To do this with Tailwind, you'd have to use components, and you'd have to add another layer of abstraction to affect the right components together.
And I know nobody really uses CSS Zen Garden style themes - but it is great to be able to take a HTML snippet and use it in another project with minimal changes and a different CSS design.
CSS has shortcomings - it's missing a way to "include", it could have more complex selectors, it can get unwieldy in larger projects - but it is also does a couple of things really well.
I understand the author points, and the article is well written. But, I moved to tailwind for different projects and now I use it nearly exclusively.
I don't want to argue whenever it is good or bad, but it solves my problems. When you are deep down some html component, being able to style it without having to find the css file is very pleasant. The code is also more maintainable as there is no "domino effect". You change what you want to change, and you are done.
As for vendor lock in, tailwind is MIT licensed, I don't see the issue here. Of course if you use X, you are going to depend on X. And if they release a breaking update, just pin the old version. I'm happy with improvement in tailwind 2, but to me the framework is complete, I don't mind it being frozen.
Concerning the long lines, I agree, but you can just put newlines between class names. Class name is a cdata list, newlines are ignored: https://www.w3.org/TR/html401/types.html#type-cdata What I do is that I group classes by function, like color on one line, margin/padding on another...
I don't want to argue whenever it is good or bad, but it solves my problems. When you are deep down some html component, being able to style it without having to find the css file is very pleasant. The code is also more maintainable as there is no "domino effect". You change what you want to change, and you are done.
As for vendor lock in, tailwind is MIT licensed, I don't see the issue here. Of course if you use X, you are going to depend on X. And if they release a breaking update, just pin the old version. I'm happy with improvement in tailwind 2, but to me the framework is complete, I don't mind it being frozen.
Concerning the long lines, I agree, but you can just put newlines between class names. Class name is a cdata list, newlines are ignored: https://www.w3.org/TR/html401/types.html#type-cdata What I do is that I group classes by function, like color on one line, margin/padding on another...
"I am fortunate to have only worked with Tailwind CSS in local sandboxes, and not in any production projects or on an actual team of other devs."
Does anyone else get frustrated when people post blogs like this without actually using the technology in any meaningful way? I was also skeptical of Tailwind, and disliked it for the first 2 weeks or so of using it, but now I'm not so sure.
This reminds me of the phenomenon in outdoor gear where 75% of the reviews are people who bought a tent and set it up in their backyard and for some reason deigned it necessary to write a review.
Does anyone else get frustrated when people post blogs like this without actually using the technology in any meaningful way? I was also skeptical of Tailwind, and disliked it for the first 2 weeks or so of using it, but now I'm not so sure.
This reminds me of the phenomenon in outdoor gear where 75% of the reviews are people who bought a tent and set it up in their backyard and for some reason deigned it necessary to write a review.
I had to stop immediately at “Tailwind makes code hard to read” and you’re telling me your home rolled css solution is any easier to read and understand? I would very much argue against that, as a home grown solution comes with zero precedent about how it works, so you have to go reverse engineer it from one or more source files, whereas tailwind is tailwind is tailwind in every file in every codebase.
It’s okay if you don’t like something, but if you’re going to publish a hate piece like this you’re going to get criticism like this.
It’s okay if you don’t like something, but if you’re going to publish a hate piece like this you’re going to get criticism like this.
"If you can suppress the urge to retch long enough to give it a chance, I really think you’ll wonder how you ever worked with CSS any other way.” - Adam Wathan
The advantage of Tailwind [1] is very subtle over the short term (such as not having to constantly context switch between HTML & CSS files), but dramatically impactful over the long term.
Both in terms of time-savings, as well as code quality and ability to work with others quickly.
It really is something that you must earnestly try to gain an appreciation for.
My initial reaction was the same as the authors when I first came across it. Actually using it on a real life project changed my mind.
[1] - https://planflow.dev/blog/the-main-advantage-of-tailwindcss.
The advantage of Tailwind [1] is very subtle over the short term (such as not having to constantly context switch between HTML & CSS files), but dramatically impactful over the long term.
Both in terms of time-savings, as well as code quality and ability to work with others quickly.
It really is something that you must earnestly try to gain an appreciation for.
My initial reaction was the same as the authors when I first came across it. Actually using it on a real life project changed my mind.
[1] - https://planflow.dev/blog/the-main-advantage-of-tailwindcss.
I wanted to like Tailwind and, I tried to tolerate it for a few months. To me, it always felt like a less opinionated Bootstrap, but arguably a lot more to learn. The same approach of having to remember class names and syntax is no different than Bootstrap. The differentiator of course, is Tailwind has better tooling support and feels less static, but it's still quite a convoluted beast to wrap your head around.
There does come a time when Tailwind starts to click, you've memorised some of the class names and you get a feel for it. But, I still found myself consulting the documentation to do things "the right way" ultimately spending hours reading documentation, when I could have written plain old CSS. The maintainability aspect in the long-run is the selling point of a solution like Tailwind. CSS without some semblance of order can wreak havoc on a codebase.
These days I am using plain old CSS on a component level inside of Aurelia 2. My components are Web Components utilising Shadow DOM features which scope my styles to the component, but also using Constructable Stylesheets to reuse styles throughout my app. In combination with CSS Variables and Shadow Parts, it's an incredibly powerful workflow that takes a lot of the pain of CSS out of development, it's closer to the metal and feels way nicer.
There does come a time when Tailwind starts to click, you've memorised some of the class names and you get a feel for it. But, I still found myself consulting the documentation to do things "the right way" ultimately spending hours reading documentation, when I could have written plain old CSS. The maintainability aspect in the long-run is the selling point of a solution like Tailwind. CSS without some semblance of order can wreak havoc on a codebase.
These days I am using plain old CSS on a component level inside of Aurelia 2. My components are Web Components utilising Shadow DOM features which scope my styles to the component, but also using Constructable Stylesheets to reuse styles throughout my app. In combination with CSS Variables and Shadow Parts, it's an incredibly powerful workflow that takes a lot of the pain of CSS out of development, it's closer to the metal and feels way nicer.
Valid points but it's still ultimately down to personal preference and I happen to really like Tailwind. Some people get into this mindset that a project simply shouldn't exist because they, or someone else, writes about why it's bad.
Also filesize isn't as big of an issue that the author makes it out to be.
https://tailwindcss.com/docs/optimizing-for-production
Also filesize isn't as big of an issue that the author makes it out to be.
https://tailwindcss.com/docs/optimizing-for-production
I do disagree with a lot of points in this. Tailwind is noisy, and sure its not a silver bullet but it removes one thing from out todo list: css architecture. We are really bad at this, esp. naming stuff. With tailwind we are just getting things done and it looks great.
Recommending jsx styles has at least the same amount of shortcomings as tailwind, the whole post feels like „i dont like and you shouldnt either, because what i use is obviously better.“ :shrug:
Recommending jsx styles has at least the same amount of shortcomings as tailwind, the whole post feels like „i dont like and you shouldnt either, because what i use is obviously better.“ :shrug:
Taiwind CSS is how you get incoherent overall design. Each element is customized to "look" nice but there is no overall architecture and design system. Padding here and padding there, this bold and that bold - visually tuning the entire page to look nice, but lacks a level of design coherency that is achieved best with a classic CSS based approach. You can do it with Taiwind to "remember" standard padding/spacing and Tachyons does it better than Tailwind, but I personally prefer the classic method even though its not as immediate as Tailwind classes inline with HTML.
People are allured by the rapid prototyping aspects of Tailwind which is the main bait. It's pretty fast to see results immediately without openining the css file.
People are allured by the rapid prototyping aspects of Tailwind which is the main bait. It's pretty fast to see results immediately without openining the css file.
When I started in a project that made use of tailwind, I initially exactly felt the points the author is making here: The HTML is a mess, dev-tools don't play as nice, why would anyone like this?
Unlike the author though, I have grown to love it - not having to look at two files to understand what's going on (html/css) really felt like a big boon, especially for "trivial" UIs that just need a bit of flexbox, css-breakpoints and a margin here and there to get going. For more complex stuff, falling back on custom classes is still perfectly fine.
Also, the "html becomes a mess" argument was only an initial issue. Once you get used to the tailwind-classes, most of it becomes fairly readable - the examples of the author are, in my opinion, just as unreadable in css, especially if you're not a design-oriented css-geek (like myself).
Unlike the author though, I have grown to love it - not having to look at two files to understand what's going on (html/css) really felt like a big boon, especially for "trivial" UIs that just need a bit of flexbox, css-breakpoints and a margin here and there to get going. For more complex stuff, falling back on custom classes is still perfectly fine.
Also, the "html becomes a mess" argument was only an initial issue. Once you get used to the tailwind-classes, most of it becomes fairly readable - the examples of the author are, in my opinion, just as unreadable in css, especially if you're not a design-oriented css-geek (like myself).
Designer who has to touch PHP code:
- yeah, I like having the whole project's code in one big index.php file. No context switching, no need to go through dozens of files (controllers, models, etc.) to understand what the system is about. No semantic naming at all. My productivity is high!
The majority of the comments here that praise Tailwind seem to be from people who are actually not " 100% frontenders", but perhaps "fullstack devs" or even "backend devs" that have to touch HTML/CSS from time to time. It's understandable that the practicality of Tailwind attracts people who work occasionally on the frontend.
- yeah, I like having the whole project's code in one big index.php file. No context switching, no need to go through dozens of files (controllers, models, etc.) to understand what the system is about. No semantic naming at all. My productivity is high!
The majority of the comments here that praise Tailwind seem to be from people who are actually not " 100% frontenders", but perhaps "fullstack devs" or even "backend devs" that have to touch HTML/CSS from time to time. It's understandable that the practicality of Tailwind attracts people who work occasionally on the frontend.
I hated Tailwind until I went whole hog on a project. There are so many nice little benefits to it, and those compound. Maintenance is a huge win. I haven’t accidentally broken styles once since switching to Tailwind. The VS Code tooling is great. The workflow is great. The reduced context switching is great. Using it with Preact is great, and my app’s bundle size is still smaller than just the dependencies on most React projects I’ve worked on, so I think the bloat is overblown.
I’m sure there are downsides, but the upsides so far seem to dramatically outweigh the downsides.
I’m sure there are downsides, but the upsides so far seem to dramatically outweigh the downsides.
I think it's a fairly compelling article. There is a lot of hand-waving around tailwind; I have never seen so many people collectively play the "I can't articulate why it's good, but after using it for a while I can never go back!!" card about a technology before. But I think author hit the nail on the head about the benefit of tailwind: rapid prototyping, but that's about it. I will use tailwind for my next small project. But I can't deny that it is indeed technical debt, albeit one that I have grown to indulge.
Like many discussions, Tailwind is a topic on which some of us are guilty of not stepping back and realising that others have different views mostly due to their background and the tools that they've used, and that those views are totally valid.
For example, I also don't like Tailwind (or, for that matter, Tachyons or any of the similar tools). I find it absolutely infuriating to work on a site that uses it, it is a massive drag on my productivity, and offers quite literally nothing that I want.
But here's the thing – I was a front-end specialist for years. I know how to write CSS and Sass, how to build UIs from them, and I have an established set of patterns and helpers for doing so. I used to be a graphic designer too, so doing things like building an application-specific design system is my bread-and-butter. For me, Tailwind is a massive distracting abstraction on top of a thing that I'm already completely comfortable using.
Other people aren't necessarily in the same position. It takes a lot of time and work to start thinking in terms of the way that styling works on the web, and CSS is pretty different to many of the languages and tools that developers are used to. If you're a back-end developer who is primarily interesting in implementing a straightforward and functional UI for something, then investing lots of time in the quite different skill set of front-end styling probably doesn't offer a good return. So there are sets of tools out there which make it easy to write simple, organised, and maintainable sets of styles, without having to get right into the weeds.
Of course as always YYMV and you might be a CSS expert who loves the consistency of this kind of framework. But I'd definitely back up the idea I've seen some other people mention – there's no obvious right or wrong, or objectively correct answer.
For example, I also don't like Tailwind (or, for that matter, Tachyons or any of the similar tools). I find it absolutely infuriating to work on a site that uses it, it is a massive drag on my productivity, and offers quite literally nothing that I want.
But here's the thing – I was a front-end specialist for years. I know how to write CSS and Sass, how to build UIs from them, and I have an established set of patterns and helpers for doing so. I used to be a graphic designer too, so doing things like building an application-specific design system is my bread-and-butter. For me, Tailwind is a massive distracting abstraction on top of a thing that I'm already completely comfortable using.
Other people aren't necessarily in the same position. It takes a lot of time and work to start thinking in terms of the way that styling works on the web, and CSS is pretty different to many of the languages and tools that developers are used to. If you're a back-end developer who is primarily interesting in implementing a straightforward and functional UI for something, then investing lots of time in the quite different skill set of front-end styling probably doesn't offer a good return. So there are sets of tools out there which make it easy to write simple, organised, and maintainable sets of styles, without having to get right into the weeds.
Of course as always YYMV and you might be a CSS expert who loves the consistency of this kind of framework. But I'd definitely back up the idea I've seen some other people mention – there's no obvious right or wrong, or objectively correct answer.
Ive been doing CSS in every flavor imaginable for twenty years now. Until Tailwind came along it was always my least favorite part of coding for the web. Tailwind eliminates all that accidental coupling that eventually turns every CSS codebase into a tar pit nobody dares to clean up.
Don’t knock until you’ve given it a fair chance.
Don’t knock until you’ve given it a fair chance.
>This means that you have to first learn Tailwind’s specific syntax before you can fluently string its utility classes together to achieve powerful results.
what kind of argument is that?
what kind of argument is that?
I tried the 'functional CSS' approach a few years ago and whilst at first I found it pleasurable to use, I ultimately grew to hate it. The biggest pain-points for me were exposed when returning to older code -- parsing the intertertwined mix of utiltiy class names and html added a level of overhead that I didn't have before. Additionally, later on in projects I'd encouter more edge cases where I need to provide bespoke styling for certain elements. As soon as you need to mix functional with traditional CSS I found the overhead to increase further.
Utility classes are good, don't worry about that. Utility classes are a required part of any good CSS system.
Programming with only utility classes, and patterns like OOCSS and BEM are bad, and we've stopped using these for literally decades.
The more important question is how do these libraries work under the hood, which is both little understood and rarely included in analysis. Breaking out CSS files is critical, any CSS created and inserted by Javascript is unforgivable in production. Focusing on what the libraries do in production is the key. And if your tool needs some special DSL to use native CSS features like @keyframes, don't use that tool. Period.
The author is right in that CSS is 100% a solved problem, and the answer is component scoped CSS with some global utility classes (which can come from Bootstrap or wherever if you choose to use such a framework). There's nothing better, it solves every need, and doesn't come with any of the baggage of other systems.
Programming with only utility classes, and patterns like OOCSS and BEM are bad, and we've stopped using these for literally decades.
The more important question is how do these libraries work under the hood, which is both little understood and rarely included in analysis. Breaking out CSS files is critical, any CSS created and inserted by Javascript is unforgivable in production. Focusing on what the libraries do in production is the key. And if your tool needs some special DSL to use native CSS features like @keyframes, don't use that tool. Period.
The author is right in that CSS is 100% a solved problem, and the answer is component scoped CSS with some global utility classes (which can come from Bootstrap or wherever if you choose to use such a framework). There's nothing better, it solves every need, and doesn't come with any of the baggage of other systems.
We often talk about the rule of three in software development. The idea is that you don’t start looking for abstractions until you have at least three instances where that abstraction will be useful. The problem with component based or semantic CSS is that it forces you to define abstractions for everything up front even if n=1.
The beauty of Tailwind is that you can still define abstractions when they are needed and pay the price of using abstractions but you can also handle the many one offs every site has in a much cleaner and more direct way.
The beauty of Tailwind is that you can still define abstractions when they are needed and pay the price of using abstractions but you can also handle the many one offs every site has in a much cleaner and more direct way.
Tailwind brings with it the same issues that css-in-js does: the inability to just reload css curing the development cycle. When working with css (or a language that complies to css), any changes to the style are pushed to the browser without a page refresh. With tailwind and css-in-js, changes to style require changes to js/html and therefore require an entire page reload which both slows down my feedback loop and breaks any state I had established in my test app.
> But I can’t imagine that it’s possible to create a tool that does the reverse: converting Tailwind to semantic HTML and CSS. The only thing you could realistically convert Tailwind to is some other utility framework (e.g., Bootstrap) that locks you in with its own syntax and class names.
I don't understand what is impossible about this. A standard tree walker and a GUI tool to define the individual components will suffice. Or to make things simpler, have a command line tool that takes in the CSS selector/XPath of the desired tag/component and generate the relevant CSS. There are already browser extensions that can do this. Also, nothing is stopping you from writing semantic HTML. Vanilla Tailwind is an (almost) one-to-one bijective mapping to CSS. It does not define your HTML unless you are using prebuilt components.
I don't understand what is impossible about this. A standard tree walker and a GUI tool to define the individual components will suffice. Or to make things simpler, have a command line tool that takes in the CSS selector/XPath of the desired tag/component and generate the relevant CSS. There are already browser extensions that can do this. Also, nothing is stopping you from writing semantic HTML. Vanilla Tailwind is an (almost) one-to-one bijective mapping to CSS. It does not define your HTML unless you are using prebuilt components.
Semantic vs utility classes is a religious war that will outlive us all, so I'll try to stick to my personal experience and not get too far into the weeds.
With that said: this resonates strongly with my experience using utility classes (Bootstrap, not Tailwind, but I think it's close enough for these purposes). On the giant front-end codebase that I used to manage - which didn't use any CSS libraries or utility classes - here are some things I learned:
- It's okay to have semantic classes and also bundle commonly repeated styles under reusable classes. Most of our classes were component-specific, but we had maybe four or five cases where a particular set of multiple(!) CSS properties were repeated in all sorts of different semantic contexts, so we encapsulated those as "utility" classes. However, when it was just one property getting used frequently...
- We learned that inline styles aren't the devil. It's perfectly fine to do `style="display:flex; margin-left:1em;"`. The only disadvantage this has compared to utility classes is brevity. And in exchange, it's much more readable and carries zero bloat or lock-in. The verbosity also encourages you to move styles to a more meaningful place once the amount reaches a certain threshold.
- For consistency in styling/spacing/branding: just use CSS variables. Preprocessor variables work fine, as do native custom-properties. `margin-left: var(--m-4);` works just as well as `class="ml-4"`, with the added benefit that it can be used equally well inline or in a stylesheet (and, again, no bloat or lock-in). Another interesting benefit is that that value can be reused and assigned to other properties; for example, maybe in one spot you want to `padding-left: var(--m-4);`.
- Unpopular opinion: your HTML and CSS aren't really separate concerns in most cases. Sometimes you can find repetition that can be factored out, and if so that's great, but the CSS that controls your layout is and always will be intimately tied to the DOM structure it's targeting. Given this, in my experience, you're much better off having hyper-specific class names (most of the time!) and, if you find it helpful, some sort of componentization/scoping system to make sure they stay hyper-specific and don't leak (I didn't find that we needed the latter, though only because we followed very strong conventions).
That's just my two cents. In my decade of writing CSS I've come out against utility classes as a formal methodology, though I'm also very comfortable hand-writing CSS and I've mostly worked at small companies, so those factors and others may bias my opinion.
With that said: this resonates strongly with my experience using utility classes (Bootstrap, not Tailwind, but I think it's close enough for these purposes). On the giant front-end codebase that I used to manage - which didn't use any CSS libraries or utility classes - here are some things I learned:
- It's okay to have semantic classes and also bundle commonly repeated styles under reusable classes. Most of our classes were component-specific, but we had maybe four or five cases where a particular set of multiple(!) CSS properties were repeated in all sorts of different semantic contexts, so we encapsulated those as "utility" classes. However, when it was just one property getting used frequently...
- We learned that inline styles aren't the devil. It's perfectly fine to do `style="display:flex; margin-left:1em;"`. The only disadvantage this has compared to utility classes is brevity. And in exchange, it's much more readable and carries zero bloat or lock-in. The verbosity also encourages you to move styles to a more meaningful place once the amount reaches a certain threshold.
- For consistency in styling/spacing/branding: just use CSS variables. Preprocessor variables work fine, as do native custom-properties. `margin-left: var(--m-4);` works just as well as `class="ml-4"`, with the added benefit that it can be used equally well inline or in a stylesheet (and, again, no bloat or lock-in). Another interesting benefit is that that value can be reused and assigned to other properties; for example, maybe in one spot you want to `padding-left: var(--m-4);`.
- Unpopular opinion: your HTML and CSS aren't really separate concerns in most cases. Sometimes you can find repetition that can be factored out, and if so that's great, but the CSS that controls your layout is and always will be intimately tied to the DOM structure it's targeting. Given this, in my experience, you're much better off having hyper-specific class names (most of the time!) and, if you find it helpful, some sort of componentization/scoping system to make sure they stay hyper-specific and don't leak (I didn't find that we needed the latter, though only because we followed very strong conventions).
That's just my two cents. In my decade of writing CSS I've come out against utility classes as a formal methodology, though I'm also very comfortable hand-writing CSS and I've mostly worked at small companies, so those factors and others may bias my opinion.
One thing I rarely see mentioned in discussions about Tailwind is inheritance - one of CSS's biggest strengths but also biggest weaknesses. With Tailwind, you never even have to think about inheritance ever again! No class can ever be accidentally overridden by another added elsewhere. This is a huge win for stability when working in bigger teams.
Sure, scoped CSS also handles this but most developers are not building JavaScript SPAs. They're building monolith applications or WordPress/Magento/Craft/whatever themes where a handful of stylesheets are included via a <link> tag.
Sure, scoped CSS also handles this but most developers are not building JavaScript SPAs. They're building monolith applications or WordPress/Magento/Craft/whatever themes where a handful of stylesheets are included via a <link> tag.
I don't feel like it does vendor lock-in. It only really locks you into using utility CSS, but you can "eject" at any time by throwing out the framework and keeping your compiled file with utility classes.
I completely agree with the maker's point that class names are the bane of CSS design. However, styled components have been amazing in this regard. I've tried a lot of solutions over the past 8 years and this is my favorite by far. No extra crap, but you still get reusability and the syntax is like plain CSS. I tried JSS but I can't get over defining styles as JS objects, not to mention made Typescript slow to a crawl.
React example:
``` import styled from 'styled-components';
const Button = styled.button` padding: 4px; font-weight: bold; `;
const PrimaryButton = styled(button)` background: ${primaryColor}; color: white; `;
```
React example:
``` import styled from 'styled-components';
const Button = styled.button` padding: 4px; font-weight: bold; `;
const PrimaryButton = styled(button)` background: ${primaryColor}; color: white; `;
```
Well I agree on the premise to some extent, but I don't feel like all the examples and points are as high impact as others. For example, I don't think that styled-jsx is really the solution to the problem - writing the stylesheets inside JSX? Sounds.. strange.
From what I can see, Tailwind doesn't offer a solution to the div-soup HTML at times becomes. When I look at five or more nested divs I kinda forget what I'm even looking at. Having semantic names is crucial in maintaining a layer of abstraction that helps to map the HTML inside your brain as entities with specific purposes. I myself use JSX and name my elements as Container, ButtonGroup or TooltipWrapper for example.
The other problem I see are the conditional class names - how does Tailwind deal with them? Do you write if-else class names? Doesn't seem very clean. I myself use styled components where I add properties, such as visible={isVisible}, and resolve them inside the stylesheet where the value matters.
The benefits of Tailwind, however, seem also evident to me as abstracting away CSS into much smaller number of utility CSS classes does appear to be a very quick way to make decent layouts. It's just that having done plenty of CSS/SCSS I don't find it too time-consuming to write the CSS myself. And also because of the previous points.
From what I can see, Tailwind doesn't offer a solution to the div-soup HTML at times becomes. When I look at five or more nested divs I kinda forget what I'm even looking at. Having semantic names is crucial in maintaining a layer of abstraction that helps to map the HTML inside your brain as entities with specific purposes. I myself use JSX and name my elements as Container, ButtonGroup or TooltipWrapper for example.
The other problem I see are the conditional class names - how does Tailwind deal with them? Do you write if-else class names? Doesn't seem very clean. I myself use styled components where I add properties, such as visible={isVisible}, and resolve them inside the stylesheet where the value matters.
The benefits of Tailwind, however, seem also evident to me as abstracting away CSS into much smaller number of utility CSS classes does appear to be a very quick way to make decent layouts. It's just that having done plenty of CSS/SCSS I don't find it too time-consuming to write the CSS myself. And also because of the previous points.
I ended up creating my own utility classes for projects instead of adopting Tailwinds.
My issue with Tailwinds from a design standpoint is that it allows for too many combinations, which is the issue with plain CSS. Having less choices makes things more consistent and IMO easier to read.
For example, a font style in our project includes the family, weight, line-height, alignment, and size in one class. This is called something like `Font16RR`. Responsive sizing is handled in the class itself (so, it may be 20pt on large screens, even though it is called "16").
We also have utilities for a small set of spacers, margins, colors, and layouts.
These are defined in parallel with the UI designer, so we both call them the same thing and we agree it's a "big deal" to add a new one. This has reduced the number of styles in a large legacy app dramatically, making everything look much more consistent.
This has the added benefit of being very easy to provide different themes which was a requirement of the project. I admit that this system requires other front end developers to either 1) Internalize the design system or 2) Receive specific mockups and copy them verbatim.
Would love to hear the perspective of anyone who has worked on whitelabel software and had to manage multiple themes and/or worked with very strict design systems with Tailwinds.
My issue with Tailwinds from a design standpoint is that it allows for too many combinations, which is the issue with plain CSS. Having less choices makes things more consistent and IMO easier to read.
For example, a font style in our project includes the family, weight, line-height, alignment, and size in one class. This is called something like `Font16RR`. Responsive sizing is handled in the class itself (so, it may be 20pt on large screens, even though it is called "16").
We also have utilities for a small set of spacers, margins, colors, and layouts.
These are defined in parallel with the UI designer, so we both call them the same thing and we agree it's a "big deal" to add a new one. This has reduced the number of styles in a large legacy app dramatically, making everything look much more consistent.
This has the added benefit of being very easy to provide different themes which was a requirement of the project. I admit that this system requires other front end developers to either 1) Internalize the design system or 2) Receive specific mockups and copy them verbatim.
Would love to hear the perspective of anyone who has worked on whitelabel software and had to manage multiple themes and/or worked with very strict design systems with Tailwinds.
#3 can be solved with PurgeCSS.
OP wrote:
> Because every new class name that you introduce could have potentially hundreds of property-value combinations, and that translates to more compiled CSS—which, of course, means a larger network request, and potentially slower performance.
After PurgeCSS you can end up with a 15kb CSS bundled payload even before gzip for a decently sized site. That's so much smaller than most other CSS libraries because Tailwind is very purge friendly.
OP wrote:
> Because every new class name that you introduce could have potentially hundreds of property-value combinations, and that translates to more compiled CSS—which, of course, means a larger network request, and potentially slower performance.
After PurgeCSS you can end up with a 15kb CSS bundled payload even before gzip for a decently sized site. That's so much smaller than most other CSS libraries because Tailwind is very purge friendly.
I switched to TailwindCSS a long time ago and I have zero regrets. Its so awesome I can switch to a project that is 2 years old, and make a quick layout UI change without having to look at old CSS files to find classes etc. I also can just find a tailwind class name and apply lots of cool stuff that I've normally found difficult to do via "pure" CSS files.
But I also feel that this is likely to be a thing that half prefer A, and half prefer B, and there is nothing wrong with either. In this thread is likely to be a 50/50 split between both camps, with different "ideologies" on how the front end should be done.
As the author of this article says - give it a go. If you like it, awesome. If you dont, switch back to another tool, there's not a definitive "right/wrong" answer to any of this.