Normal to struggle with Tailwind?

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

• VSCode Tailwind CSS Intellisense
• A Prettier Plugin for Tailwind: prettier-plugin-tailwindcss

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

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?

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.

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.

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

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 ❤️.

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.

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.