James Palermo

Posted on May 30

Normal to struggle with Tailwind?

#tailwindcss #help #beginners #css

I'm trying to experiment with Tailwind. It seems so... Scattered and difficult to keep track of. Should I push through and keep practicing with this method of styling or is normal CSS still going to be around for the foreseeable future?

I like structured and grouped stuff I guess.

Discussion (61)

tq-bit • May 30

It seems so... Scattered and difficult to keep track of.

There's a reason why inline styling went out of fashion.

There are some useful tools to keep Tailwind styles under control, such as

Stuff's still quite messy tho. But I'm sure standard CSS will stay.

𒊩Wii 💖💛💚💙💜💝💟 • May 30

There's a reason why inline styling went out of fashion.

And I still don't understand how or why it came back

tq-bit • May 30

I believe due to the way components are defined. Take a simple Vue SFC. There still is a separation of concerns between script, template and style. + they're meant to be reusable, almost like CSS classes are. So much for the theory.

It gets interesting when you try and reuse spacing, colors or even shadows over several components. The moment Tailwind's promise breaks is when I need the same color for, say a navbar AND a button component. Even worse, you probably have those util classes scattered over your whole codebase.

What if the client changes their mind? I want red instead of purple. You'll refactor the all components that use this coloring. Now you might say 'this can be done with a regex replace-statement'. At this very point, the circle closes if you directly applied Tailwind to the component instead of using dedicated classes.

James Palermo • Jun 1

Oh my God, I hadn't even thought of refactoring or redesigns with Tailwind.

That actually caused a legit stress response in me. 😖

Matthew Daly • May 30

It didn't - this is an extremely common misconception.

𒊩Wii 💖💛💚💙💜💝💟 • May 31

That article still only makes it sound like inline styles but a bit more convenient this time.

That still leaves the main problem though: You're inlining your styles in your document. It is inline styles.

Matthew Daly • May 31

No, it isn't, any more than an approach like BEM is. You're still using classes for styling, but the scope of those classes is generally reduced a little. It's definitely not a one-to-one relationship between Tailwind classes and single CSS rules in every case. And, by using the @apply directive you can easily extract the styles used to a stylesheet.

Fundamentally Tailwind is an abstraction over CSS that provides the following benefits:

Limits you to a predefined palette of colours, proportions and so on. You can change this palette if it restricts you, but by limiting the scope of what classes are available for styling, it helps to ensure a greater consistency in your application - for instance, you won't end up with Alice using 3px for padding, Bob using 4px and Chris using 2px
Provides consistent modifiers for things like media queries (including dark mode) and state such as focus or hover. Inline styles can't do that
Makes it much less likely CSS rules will grow out of control. By encouraging use of the predefined Tailwind classes and discouraging making your own, it makes it easy for tools like PurgeCSS to strip out unwanted styles, resulting in typically smaller CSS bundles in the production application.

It's a particularly good fit for component-based JS libraries like React or Vue where you're actively encouraged to extract common UI sections to their own component. In that context it tends to be extremely quick to style it using Tailwind once you get up to speed, making it extremely useful for prototyping. Further into your project, once you have some styles established, then if you want to reuse them in ways that template partials or separate UI components don't facilitate, then it's easy to use the @apply directive to extract common styles and create your own more conventional classes, without losing the advantages of consistency mentioned above.

Honestly, I thought the same at first and it took a while for it to click, but I'd never go back. I maintain a big legacy project with a huge pile of messy CSS that I inherited and is very difficult to strip out. That would be virtually impossible for that to happen with Tailwind.

𒊩Wii 💖💛💚💙💜💝💟 • May 31

It's definitely not a one-to-one relationship between Tailwind classes and single CSS rules in every case.

That's not the important part though. Whether you're using classes or inline styles, even if one lets you do more things with less typing, the fundamental difference is that you are inlining the actual styling into your HTML.

There may be a CSS document somewhere that defines some more powerful tools in the form of classes, but those aren't styling "rules" in the same sense as with normal CSS; they end up being more similar to CSS properties, in that they just toggle atomic design elements like a colour or the text alignment.

The actual styling is still in your HTML though, so no, it is just plainly wrong to claim utility classes are somehow fundamentally different than inlining CSS using the style attribute. They may be more powerful and convenient, and that might for many be the deciding factor as to why this approach is okay to use while inline CSS is evil; but some sort of defense has to be made. One cannot simply claim that "they're different things" and dismiss all criticism of inlining styles into HTML.

There's a separate discussion to be had about whether enough of the problems with inline CSS aren't present, or whether the most relevant ones still remain, and that discussion can be a lot more nuanced and ultimately up to personal preference and picking the right tool for the job.

Matthew Daly • May 31

The @apply directive renders much of that moot, though, since once you've settled on a style that works you can easily use that to extract common patterns into reusable classes. It depends on the context you're using it in, and for using component libraries like React it often makes less sense, but certainly if you're using Tailwind in something like Blade or Twig templates then using @apply is more commonplace.

𒊩Wii 💖💛💚💙💜💝💟 • May 31

At that point, haven't you just gone full circle and basically achieved nothing other than introducing two new dependencies?

Matthew Daly • May 31

No, because Tailwind still works as an abstraction layer. And you can combine the two approaches however you see fit - it doesn't have to be either everything using the utility classes direct or everything using the apply directive.

It's like JSX in that it sounds arse-backwards when you first hear about it, but if you try it then once you get over the hump it starts to make a lot more sense.

Nathan Hedglin • May 30

It is NOT online styles.

tq-bit • May 31 • Edited on May 31

It isn't. But it does feel like it for a lot of classes:

flex
text-center
mb-4

...

Vladimír Macháček • May 31 • Edited on May 31

Yes. Utility-First uses classes so the property:values does one thing and can be easily combined and reused.

When you define selector on your own, you are mostly going to duplicate the css property:value in it. Which causes CSS size to grow, you have to use modifiers to change the css on certain places like button button--red. This is less likely to happen with utility first.

More info => dev.to/machy8/comment/1p2jj

𒊩Wii 💖💛💚💙💜💝💟 • May 31

What you call button button--red I just call <button class="danger">, which will need one selector for the button element and one for the .red class, which will work for any element, not just buttons.

When done right, this gives you a complete n * m elements you can style, with every colour applying to every element type (although, of course, in reality some of them will not be implemented because YAGNI).

Vladimír Macháček • May 31 • Edited on May 31

My bad, the button--red example was not showing the problem enough.

I am talking about reusing a button in an efficient way. What I mean by that is, when for example a button is used on multiple places and needs various indentation, colors, paddings and alignment.
You can't solve that by just one class. How would you solve that?

𒊩Wii 💖💛💚💙💜💝💟 • May 31

The way you phrase that question doesn't even make sense when we're talking about proper rule-based CSS; what's the context for these different indentations, colours, paddings, etc.? Does it depend on the surrounding elements? are certain buttons special? Is there just no clear design idea and every button just gets positioned by hand?

Vladimír Macháček • May 31 • Edited on May 31

Stylify or Tailwind is NOT inline styling.

Stylify uses selectors like class="color:blue" that are reused, optimized, combined and etc. The same goes for Tailwind and other utility-first frameworks.
Inline styles are style="color: blue;".
More info => dev.to/machy8/comment/1p2jj

Luke Shiru • May 30

I used Tailwind extensively in my website (even for the animation on the homepage), but if you're struggling with Tailwind, one nice alternative made by a fellow member of the DEV Community is Stylify. You basically write "CSS as classnames" and it works pretty great:

<button class="
    background-color:#023
    border-radius:4px
    border:2px__solid__#012
    color:#fff
    cursor:pointer
    font-size:24px
    hover:background-color:#012
    padding:24px
">
    I'm a fancy looking button
</button>

If you had another element with let's say padding:24px, they both use the same classname for that, so you get the same benefits from Tailwind.

They have a demo in the site itself you can try out, and it shows the output CSS and HTML.

Cheers!

tq-bit • May 30 • Edited on May 31

but if you're struggling with Tailwind, one nice alternative made by a fellow member of the DEV Community is Stylify.

I really mean no harm or offense, but this project seems like the worst of both worlds.

Additional ~~bundle size~~ mental load for no visible value added
No separation of concerns at all

Perhaps somebody can elighten me - why would I do this?

Luke Shiru • May 30

The same reasons you'll have to use tailwind: It doesn't add additional bundle size and you don't need that "separation of concerns"?

About the bundle size: If you have this concern, it becomes evident that you haven't tried atomic CSS solutions yet. In the particular case of Stylify, You write your code as you'll write custom CSS, but it produces a bunch of atomic CSS classes that are reused across your webapp, and you don't need to learn a bunch of classNames or have to look them up constantly as you'll had to do with tailwind, because is just CSS with some conventions over how to write it. But yeah, size is not an issue with this kind of solutions, you just have the minimum CSS you need.
About separation of concerns: This is in the same level that Tailwind, Emotion/Styled Components, and other "CSS-in-JS" solutions are. You can google about the "separation of concerns" argument with CSS-in-JS, but the short version is: "Styling shouldn't be considered a concern".

Maybe you can share why you consider "separating CSS" is relevant, or why you think the bundle size will be affected negatively.

tq-bit • May 30 • Edited on May 30

TL:DR

[...] "separating CSS" is relevant [...] - because it keeps your project maintainable by a team of devs, designers and other team members.

[...] why you think the bundle size will be affected negatively - in fact, judging just by size, I don't think it will. But the value of using this style of applying styles, in my eyes, does not outweigh its costs

I get your points. I'm biased on a few as well, so lots of words would probably not convince. Let me try and elaborate with a few:

About bundle size:
Perhaps phrasing on my first point was poor. With additional bundle size, I meant: It's another package I have to take care of during my dev workflow. I understand your point with atomic component design - it's a pattern where utility CSS frameworks such as Tailwind+PurgeCSS really shine. Because when you develop, you must make compromises between technical cost ( and debt ) vs. value added.

In a nutshell: The value I see at first and second glance does not outweigh the cost of using this package. It's just my opinion. It might as well be wrong and I'm sure there are projects where this will save a lot of time. I just cannot envision them clearly.

About SOC
As per your advice, I did Google "separation of concerns css in js". The first entry that came up led me to the book 'Programming JavaScript Applications by Eric Elliott', where the first sentence reads:

Separation of concerns is the idea that each module or layer in an application should only be responsible for one thing and should not contain code that deals with other things

As per my understanding:

HTML = structure
CSS = style
JS = interactivity

So if you say

"Styling shouldn't be considered a concern"

I say:

"Then neither should interactivity be"

Let's create a single language that does HTML, CSS + JS at once. Even better: Let's all use .jsp for everything again. That'll be fun.

In all honesty: There's a reason why there are whole CSS design systems, such as BEM or SMACCS around. If properly applied, they empower you to scale your product without compromise. Or shift it over to other teams without a lot of struggle.

Or refactor / rewrite a big chunk of your HTML templates. If you scrap your Tailwind-powered views, all the styling is gone for good. If you use a design system, all CSS classes will persist and you can quickly prototype new pages.

Now you might argue: "But this works with Tailwind too!". Sure it does, but building the templates AND the styles at once from scratch doubles the mental payload you might have to carry. If you already have a guiding star, it'll be much easier.

Luke Shiru • May 30 • Edited on May 30

I get your points, and as you mentioned, we might be biased based on what we consider to have "enough weight". I'll have a TL;DR as well if you don't want to go into detail:

TL;DR:

Bundle size: I generally prefer to have a bigger dev bundle size if that produces a smaller production bundle size.
Separation of concerns: The layers Eric talks about are modules, not CSS/JS/HTML. As a functional programmer, he's all over composition, and the atomic approach enables that in CSS.

Bundle size: Your concern was about the number of dependencies in your project at dev time, which I don't consider a blocker if that will produce a smaller bundle size for the user and will still be fast in development (which is the case for Atomic CSS solutions).
Separation of concerns: You find a really good quote, but I think you might have not interpreted it correctly:

Separation of concerns is the idea that each module or layer in an application should only be responsible for one thing and should not contain code that deals with other things

I think you interpret structure, style, and interactivity are different layers, but Eric is talking about modules. With modules/components generally speaking HTML, CSS and JS never leave the folder they are in, so separating styles or having them "inlined" is pretty much the same from the "outside world". You might argue that you sometimes need some functionality of that module in another, to that I say: "Then why is that functionality inside a single module when is a shared behavior?". The same applies to styles, if you need a style to be shared between different modules, then those styles shouldn't be locked inside a single module, and instead, be shared. That's why I meant with "Styling shouldn't be considered a concern", maybe a better wording would be: "Styling shouldn't be considered an app-wide concern, it is a module concern, and at that level, having it in a separated file is no different of having it inline".

You mentioned BEM and SMACCS, which were pretty common with global styles to avoid conflicts based on conventions, but wouldn't it be better if we didn't have those conflicts, to begin with? CSS Modules, Atomic CSS, Shadow DOM, and so on are all solutions that came after and allow us to code our styles in a "modular" way, avoiding globals as much as possible. Is pretty funny if you think about it, that we see global values as something bad in every language out there, but in CSS some consider it to be good when is as bad as in other languages. You wouldn't write all your JS values in globals with naming conventions, why is it fine to do that with CSS?

Thanks for going into detail. I really value it when folks discuss in detail instead of leaving it at "I don't like it lol" because the conversation ends up being valuable for not only us but also other folks reading it.

Cheers!

tq-bit • May 31

First off:

Thanks for going into detail. I really value it when folks discuss in detail [ ... ]

That thanks goes back to you, on top of it (I can't believe I write this): Thank you for staying on topic.

I do understand your points, and while I can't relate, I figure: The concept doesn't have to work for me as long as it does for you.

A few closing words from my side:

You find a really good quote, but I think you might have not interpreted it correctly:

It was the first quote I stumbled across. If I were to pick something more substantial, I'd go for Adam Wathan's article in which he speaks about his transition from "Semantic CSS" to "Utility first".

What even this article is missing: Global CSS variables. I'm talking about the color-brand or text-small that exist above your modular style scope.

Granted, you can extend Tailwind with your own classes. But I don't want to play hide and seek with colors when receiving feedback from a client. Imagine they want each h1 tag in gray-200 colors now instead of gray-300 when:

in dark-mode
the text is hovered
the user is on a mobile device

The only change I'd like to make is the variable --text-color-primary and be done with it. The rest will be handled by SCSS utility functions.

so separating styles or having them "inlined" is pretty much the same from the "outside world"

Can't agree. CSS is, indeed, a layer on top of structured HTML. It can-and imo. has to-be abstracted to make it maintainable. And changeable within a reasonable amount of time. Within a CSS structure, I then separate again-between variables, base styles, component styles, utility styles, and so forth.

This is (almost) also true for components. But extending components by, say variants with Tailwind or Stilify, will undoubtedly lead to unreadable templates.

The same applies to styles, if you need a style to be shared between different modules, then those styles shouldn't be locked inside a single module, and instead, be shared

I think I caught you here. The idea of sharing is only possible if you actually do separate by concerns. For instance, inline styles cannot be shared. Stilify CSS can, because it feels like reverse-engineered inline styles.

then those styles shouldn't be locked inside a single module,

And I'm fully with you: Why declare styles in your HTML while you can do the same in CSS?

leob • May 30 • Edited on May 30

You're very kind to say you mean no harm or offense, I'd be a bit more harsh and say that this is just a terrible idea.

Nathan Hedglin • May 30

Lol same 🤮.

leob • May 30

Woa, and how is this supposed to be maintainable? Hard-coded values all over the place, that doesn't really sound like a great idea to me ... you could just as well put a style attribute on your HTML elements and stuff all your CSS styling in there, that's just as horrible but even simpler.

Luke Shiru • May 30 • Edited on May 31

A see a few misconceptions but that's ok...

how is this supposed to be maintainable?

If you worked with any kind of Atomic CSS solution, you know the answer to this, but instead of doing what you'll do with CSS Modules or similar solutions and have two different files per component:

/* FancyButton.module.css */
.FancyButton {
    background-color: #023;
    border-radius: 4px;
    border: 2px solid #012;
    color: #fff;
    cursor: pointer;
    font-size: 24px;
    background-color: #012;
    padding: 24px;
}

.FancyButton:hover {
    background-color: #012;
}

// FancyButton.jsx
import styles from "./FancyButton.module.css";

const FancyButton = props => (
    <button className={styles.FancyButton} {...props} />
);

Or instead of having some kind of global style with conventions such as BEM, you actually have styles defined inline in the component itself:

const FancyButton = props => (
    <button
        class="
            background-color:#023
            border-radius:4px
            border:2px__solid__#012
            color:#fff
            cursor:pointer
            font-size:24px
            hover:background-color:#012
            padding:24px
        "
        {...props}
    />
);

you could just as well put a style attribute on your HTML elements and stuff all your CSS styling in there

Not really, the difference with libs such as Tailwind and Stylify is that if you have a consistent design system, then your final CSS has only what you need, nothing more, nothing less, without having to do manual optimizations. So taking the examples above, if you had that CSS Module for FancyButton and then you had a FancyInput with pretty much the same styles, the final result will be smaller with the Atomic CSS approach, and the performance will also be better.

I know is easy to assume "this is the same as inlining a style tag", but it isn't, the idea is to make it "as easy" as inlining, but with the benefits of not doing it. When I saw Tailwind for the first time I thought similar things, but the same happen to me when I first saw JSX and React until I actually tried it and understood it. There's a reason giants like Twitter or Meta use Atomic CSS all over the place.

Give it a try in a small project, and let me know hot it goes :D

leob • May 31

Thanks a lot for this extensive answer, I wasn't familiar with Atomic CSS (but I was with Tailwind, and it's more or less the same concept) ...

I see what you mean, same as Tailwind this is to be used in the context of a framework like React or Vue that allows you to create components, hence solving the problems of "repetition" and "consistency" ... you wouldn't want to create a large site with heaps of HTML where you duplicate class=background-color:#023 a hundred times across your codebase.

Vladimír Macháček • May 31

You can define components, variables and custom macros (like my-2) in Stylify if you need to. Therefore you don't have to have such repetative code.
More => dev.to/machy8/comment/1p2jj

leob • May 31

Thanks for explaining that, so with these variables you avoid sprinkling hardcoded RGB values or hardcoded font/padding/margin sizes all over your codebase ... I do understand the advantages of this approach, traditional CSS stylesheets also have their problems.

Vladimír Macháček • May 31 • Edited on May 31

Wow, this is some hell of a fight of arguments here 😆.

I am the author of Stylify and I will try to clarify some points in the thread above and bellow:

Why would anybody use such syntax

Because you don't have tu study anything. It's like CSS instead of randomly named somehow shortened classes. An example: auto-cols-auto is a class from Tailwind. The class is not self explanatory and a dev not using Tailwind daily have to go into the docs or into the dev tools to see what it does. In Stylify you write this grid-auto-columns:auto. Everyone with a bit of knowledge CSS knows what that does.
Another reason is maintainability. What if browsers comes with a property, Tailwind already shortened? An example shrink => flex-shrink: 1; (class from Tailwind). The browsers come with, for example a new shrink: auto. Then they will have to figure out a new name for the new selectory so it makes sense. Which can be confusing.
When using BEM you can end up with <div class="page-section__container page-section__container--full-size page-section__container--without-background"></div>. I can't see how property:value selectors are more bad then this.

Shure, Stylify syntax might not be for anyone. You can however define custom macros for having classes like ml-2 or py-3 if you like it more. It's just a Native Preset that you can ignore and define custom set.

There is plenty of hardcoded values

In Stylify, you can configure variables and use them anywhere.
It's just up to developer if he is going to have hardcoded values in the code or not.

Why not to put the style directly into the style="" attribute

For example a selector like color:red is generated as .color\:red{color:red}. This selector can be reused.
When you add a component in Stylify like .button that needs red text, it is generated like this .color\:red,.button{color:red}. The selector is simply attached, reused and the property:value not generated again => This means smaller bundles
In production, you can also minify this selectors to => ._zs,_zx{color:red}. This is done even by Medium.com and Facebook.
But the minification will make the blocks harder to find when debugging because of the unreadable classes? No. You can use empty class as selector, data or id attributes. Also, in Javascript we normally minify classes and selectors from const myValue to const zx and nobody cares.

Advantages over pure CSS

Selectors are dynamically generated => don't have to remember to remove them when removing css and vice versa
Selectors are combined and reused => .color\:red,.button{color:red}
Selectors are minified from long text-align:left to short _zx
You open a template file and a browser and you just type the selectors. You don't have to switch between html and css for removing, renaming and manually combining clases
The CSS size doesn't grow exponencialy, because there is a minimum of duplicated css property:value. There is some article about CSS size from Facebook
When frontend and backend engineers works on one task, then it's easy for the frontend engineer to tell the backend engineer which classes to add when he just needs to indent or align something. He doesn't have to edit CSS and hope it will work. He just copies selectors.
Dynamically generated CSS means less files in the projects => less changes => we normally generate cache, entities, migrations, js bundles and etc. So Stylify dynamically generates CSS. At least from my point of view it's more comfortable and efficient then writting it manually and think about how to pregenerate utilities or combine css files manually.

Bloated templates & maintainability

You can define components. So there doesn't have to be any utility in the template.
From my experience, you can bloat your templates by a lot of other stuff => conditions, attributes, dynamic attributes, dynamically loaded templates and etc. Blaming CSS selectors is simply wierd.

Separation of CSS from HTML

I think, this havily depends on the angle of view
Any approach can go wrong
Stylify generates CSS files using JavaScript. Selectors are in the HTML/Twig/Latte/Vue/Jsx. Stylify just scan project files and generates CSS. That's all. It doesn't have to interfiere nor be included afterwards.
When you decide not to use Stylify anymore, you just run build, get the CSS files that contains CSS similar to what you would normally write, and remove the Stylify from the project.

Although I'm developing Stylify and I like the Utility-First + Components approach and dynamically generated CSS, I understand it doesn't fits everyone. Therefore, it's good that there are more tools that do a good job like Tailwind, Bootstrap, Bulma and various approaches so everyone can use whatever suits them. Different tools and approaches for different needs 🤟.

Thanks @lukeshiru for the persistent and extensive comments in a favor of Stylify.dev ❤️.

Marco Ledesma • May 31

Not sure what benefit of this is vs just normal css. The thing that I like about tailwind, and bootstrap utility classes as well, is that text, spacing, colors, grid systems, gaps, etc. all have abstracted units of size. For example, if I type ‘text-xl’ or ‘px-8’, tailwind has a standard pixel size that are applied to these class names. You never have to hard code the actual pixel size. This gives you the benefit of changing what text-xl means in a single config file — almost like CSS variables.

This other approach, the one where you’re rewriting css inside class names, does not solve the same problem tailwind does.

Luke Shiru • May 31 • Edited on May 31

You're kinda "hardcoding" when you use px-8, if you think about it (padding-left: 2rem; and padding-right: 2rem;), same applies to text-xl (font-size: 1.25rem; and line-height: 1.75rem;). Think it this way:

<button class="px-4 py-8">Hello</button>

<!-- is kinda equivalent to ... -->

<button class="padding:4rem__8rem">Hello</button>

In tailwind you can change the sizes in tailwind.config.js, and for Stylify you can just set the rem size, but is pretty much the same experience 😄

Just to be clear, I'm not advocating in favor of Stylify over Tailwind (I personally prefer Tailwind). I just mentioned it as a good alternative to get your head around "utility CSS/atomic CSS" (as I said, if you're struggling with Tailwind). Maybe after using Stylify for a while you get the idea for Tailwind better.

You can actually see the announcement of the author itself and get your doubts cleared in his post here.

Cheers!

Marco Ledesma • May 31

I see. Although I can use rems, sure, and just change the size of rems - I think specifying an actual unit type in your css class still has a smell for me. It could just be personal preference, since I’m used to abstracting away unit types in class names. But I think the authors goal is to remove the unit abstractions, since one of his pain points of tailwind was remembering class names.

I see that the author put a lot of love into the stylify framework. Reading his post and another of his follow up post, he makes a good argument that it’s a pain to remember class names of other frameworks. I won’t trash his work since the author is passionate, and what works for him works. Just not for me I suppose.

Alex Escalante • May 31

Well… this is getting awkward…

Vladimír Macháček • May 31 • Edited on May 31

Can you please explain what do you mean by akward?

Ben Halpern • May 30

I think it's abundantly normal to struggle with a new paradigm. Tailwind is a pretty simple mental model once you get it, but it's a pretty big departure from how you do CSS right now.

I guarantee it will click soon enough.

Saravanan-TeslaTuring • Jun 7

You can use the Tailwind CSS Intellisense. If you have idea about bootstrap then tailwind is easy to understand. You can create any kind of websites without writing single extra CSS. I created 2 landing pages like that only. Final word Tailwind is super dooper

James Palermo • Jun 8

2 landing pages is, no offense, small enough that I could memorize it.

Where I'm struggling is when you have a lot of pages and all the HTML is heavily... "Cluttered."

Saravanan-TeslaTuring • Jun 24

It's depends how you are reusing the variables from Tailwind Config. You should have the plan when you are starting the project. Like colors, button sizes, border radius and everything. Only you are going to reuse that. Then whenever new designs you are adding you have to add that in config. Another biggest advantage for tailwind is arbitrary values. You can add particular styles in class itself. But you can't reuse those values again. So if you are creating big application or small application it does not matter. If you are reusing the styles properly, Then outcome will be really nice. Thanks

Ben Sinclair • May 30

Normal CSS is going to stay around.

If you have to use something like Tailwind I'd suggest avoiding using any of its utility classes in your HTML. Build your own classes, and include the utilities in them instead, so the HTML doesn't become littered with non-semantic attributes.

This will make it easier to see what's going on, and mean your project can be maintained in the future without resorting to search-and-replace choring.

The way most people use it, and the way most examples show, yes, it's "scattered", but you don't have to do that.

Nathan Hedglin • May 30

NOT THIS. If you're on a professional project with tailwind and you're defining your own classes then your PRs will be denied. I'd deny any code that doesn't fit the teams approach.

The whole point is to use utility classes; like it or not.

For personal project then do whatever.

Ben Sinclair • May 30

Adding non-semantic classes to HTML is two steps back.

Nathan Hedglin • May 30

Nope, HTML has semantics NOT css.

I've seen Tailwind scale. To each their own.

Nathan Hedglin • May 30 • Edited on May 30

You define the structure. That's the whole point

It is a library not a framework that has a predefined structure.

You define the structure. On enterprise projects there is a design system. Tailwind makes it extremely easy to build reusable components around that design system.

For small projects and beginners not working off of professional designs then sure it's a bit difficult to define your own design system.

The problem with normal CSS

First let's understand WHY Tailwind was created. I've worked on Sass projects that use BEM. After awhile you'll never find which CSS class you want to use or if you do, you'll end up copy-paste-rename. Sure mixins help but that takes a lot of diligence and refactoring.

BEM defines the structure of your components in CSS which is wrong. CSS should be as HTML and structure agnostic as possible.

Ultimately, you'll run into duplicate code problem in CSS and your styles will just keep growing.

It works well IF all your components are all define ahead of time but that's rare. Eventually, things will change.

Design System

The whole point of a design system is to Limit styles and approaches. This keeps styles and code consistent and reusable.

My tailwind project doesn't allow colors outside of the predefined color palette. No one can just do color:#FA27BC . Also, one doesn't need to dig through CSS classes or Mixins to find what is similar to reuse, refactor or copy-paste-modify.

In fact, the Tailwind Config Viewer auto-documents ALL styles including custom ones.

More than Inline styles

Classes can use media queries
Classes limit repeating CSS
Classes allow caching. stylesheets cache much longer than the HTML that changes more often.
Classes can include multiple properties at once.
Classes support pseudo selectors and pseudo elements etc.
Classes can define keyframes for animation
Sticking to only classes help with specificity issues.
Classes (stylesheets) can be processed with Post-CSS, SASS etc. Which Tailwind generates classes for media queries etc.
Utility classes don't grow your CSS over time. Much easier to maintain.
Classes can apply to new HTML in WYSIWYGs.
Utility classes are easier to auto-document and learn. BONUS: editor / lint support. You get autocomplete to find what you need and errors if something is wrong.

Atomic Design and Tailwind like FP for CSS

My atoms have styles to define what a button looks like. One can use a button without writing any CSS, not even classes.

Molecules define more complex multi-element components. They layout their children.

Templates define specific layouts for components.

Organisms are the fully fledge data-driven components. Components go from generic to specific. Atom -> Molecule -> Organism

My interns can build a whole new page in 30 minutes because everything is reusable. Complex layouts aren't difficult because they're built from smaller simpler layouts.

This creates a design system that is crazy fast to develop. The styling stays consistent because everything is based off of reusable atoms. The CSS utility clases are just like atoms.

Just putting 50 Tailwind classes on Every html element is WRONG and ugly. That's a symptom that your components are too big.

Conclusion

You absolutely don't have to use Tailwind but most of the haters don't understand how to use it appropriately. Maybe they've never worked with 5,000 LOC CSS files that can't be refactored without breaking something.

It is an amazing tool for building a custom design system. Like any tool, it isn't always the best fit.

Jared White • May 30

Tailwind's actually pretty terrible for creating a custom design system. It's fine for rapid prototyping when you just want to copypasta UI examples off the web and not really think about component design and styling APIs.

Otherwise, I always recommend using a good set of CSS variables as design tokens and then design components using semantic class names or better yet custom elements, and setting additional component-specific CSS variables—and shadow parts if you're using the shadow DOM.

Nathan Hedglin • May 31

Interesting. It has worked amazing for me using Atomic Design. Atoms are the smallest components that have styles on them. I can then build new components from them without writing any CSS. Templates are components that manage layout.

Again, you have to put the Tailwind classes into a structure. If you don't, then yes it's terrible.

I've had my junior devs build new pages and components rapidly. Much faster and more maintainable than writing CSS.

Edge • May 30

TailwindCss essentially improves inline styling.

If you learn Tailwind you'l find yourself with ease when it comes to writing normal CSS, as many class names are similar in CSS.

Take this example:

<div class="flex items-center justify-center h-screen"> Hello World! </div>

It can easily be converted to:

.class {
  display: flex;
  align-items: center;
  justify-content: center;
  height:100vh;
}

It's also all about practice, eventually you'll get it.

Ben Calder • May 31

To me Tailwind feels like the CSS equivalent of JQuery: it's a supposedly easier alternative for those who don't want to learn CSS properly 🤣
If you're not comfortable with Tailwind just use CSS or an established preprocessor like SCSS.

Mostafa Said • May 30

I really didn't take anytime learning TailwindCSS. It was simple enough to get used to it in just few days. You would just peak on the docs many times till it sticks in your brain and that's it.

Try to push yourself out of the comfort zone to learn what's new and popular. It became popular for a reason.

limorkeez • May 30

I've decided to learn Tailwind for the first time while working on the backend-oriented class project recently. It was a bit hard at first, had to spent some time to search for the class names. But it got better, eventually I got pretty comfortable to use it on the next project. I guess with some practicing it will become easier, just like anything else.

MJCoder • May 30

Having a good grasp of Vanilla CSS is a must, with anything new, it will take time to get use to it, I have the docs open while working on Tailwind - I've recently started using it on a site I am building for myself locally. It can be overwhelming but perservering will pay off.

Cate • May 30

I used tailwind for first time last week on a class project together with reactjs and it was a bit confusing to me. I almost restarted the whole project with bootstrap, which I'm used to. I liked its ability to customize my own css eg colors...but I felt like it's making my jsx code too huge ....for now I will stick with bootstrap for class projects as I learn tailwind, because I feel its worth knowing it.

Wemerson Queiroz • May 30

My experience so far is nothing but happiness …

I’m just doing my first project , although the learning curve is being painful, it’s more rewarding(at least for me as beginner ) then plain css or bootstrap…

What I’ve noticed so far is that it’s much more about memorising the classes at this early stage rather than suffering with css…

Gedi • May 30

I will asume that you are using React, Vue or some sort of framework with it.

If that is the case, you building components. each component has it's own classes and as best practive of component based project you want to splint everything in the small reusible pieces. At that point you end up with not that much messy classes per component. And when you need to look in each component, you can see it's functionality & style in case file. ( building it is great too as you don't need to swap between files for style & functionality ).

i use tailwind with all my projects and i thinks it's a great too as it's not opinionated and simple to understand at glance.

Dendi Handian • May 30 • Edited on May 31

struggle with tailwind could also means struggle with css itself.
tailwind (and other framework like bootstrap) is a gift to any backend-oriented developer.

Aung Myat Moe • May 30

Just make 5 or 10 websites using tailwid you will get it quickly

Andrew Baisden • May 31

Tailwind is seriously popular these days keep at it eventually you will figure it out. All you need is more time and practice to get good with it.

leob • May 30

Study the docs? I'm pretty sure the docs will address your concerns, because a lot of people have exactly those same concerns when first confronted with the rather unique approach of Tailwind.

Bruno Domingues • May 30

I decided to start a personal project with tailwind to learn, but i´m struggling a lot with it too. But i believe training is the key to make it easier.