Normal to struggle with Tailwind?

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.

Comments

[Saravanan-TeslaTuring]

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]

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]

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

[Andrew Baisden]

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.

[Vladimír Macháček]

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

1. 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.
2. 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.
3. 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 ❤️.

[tq-bit]

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?

[Ben Calder]

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.

[Alex Escalante]

Well… this is getting awkward…

[Vladimír Macháček]

Can you please explain what do you mean by akward?

[Marco Ledesma]

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.

[leob]

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]

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]

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.

[Marco Ledesma]

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.

[Gedi]

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.