91–100 of 179 posts
CSS Modules are a better solution. They compile classnames into unique identifiers, so there's no need for BEM or SMACSS conventions: https://x.com/efortis/status/1888304658080256099
What is funny with your article is that you talk about tradition, when actually these traditions are based on assumptions which are themselves based on beliefs like : "separation of structure and style are a good thing". But this belief is only true if the language to describe the structure is html or js which creates not reusable pieces of style/structure. But when you go for a different approach where everything is…
The purists ("that’s how things ought to be!") and the pragmatists ("well but it works well and people understand it seemingly").
Earlier quoted context omitted.
Almost none of that is specific to Tailwind though, you can take any design system in CSS with or without JS and make the same argument right?
What do you think tailwind is? It's a utility to generate deduped/treeshacken css classes - according to a config file the parent mentioned It's not some grand framework or something. It's literally doing exactly what the grand parent said. Define root css variables, and generate the applicable/used css classes that were used in the code
I don’t understand where the disagreement is. I was only pointing out a lot of the “magic” from Tailwind’s abstraction isn’t as magical as the GP you referred to implies.
Earlier quoted context omitted.
It makes no sense for me that @apply is frowned upon. It's what makes Tailwind actually kinda usable for me. Without it, markup looks like line noise full of boilerplate that's hard to modify in a systematic way. I think what Tailwind actually needs is more abstractions, not to discourage the use of the sole abstraction @apply
Using @apply defeats the entire purpose of Tailwind. The point of it is to localize styling alongside the markup. If you're using @apply then you're constantly context switching from your markup to your CSS files while working. There's plenty of ways to manage the bevy of classes you need. First step is making use of components to deduplicate stuff. Then in those components, use a library like class-variance-authorit…
Earlier quoted context omitted.
What do you think tailwind is? It's a utility to generate deduped/treeshacken css classes - according to a config file the parent mentioned It's not some grand framework or something. It's literally doing exactly what the grand parent said. Define root css variables, and generate the applicable/used css classes that were used in the code
I use Tailwind for work and hobby projects and what you said is exactly what I think Tailwind is and why I use it. I don’t understand where the disagreement is. I was only pointing out a lot of the “magic” from Tailwind’s abstraction isn’t as magical as the GP you referred to implies.
I see you have a .button, cool! So did you load the entire context of your project into your mind, and calculate every possible iteration of kind, size, color etc this button may have? And once you did that, did you come up with a semantically correct naming scheme that is clear and will not succumb to the inevitable .button_checkout_special_page_cta_widget a particular page will end up requiring? No? Neither did I.…
It’s funny, as someone that’s been using CSS for decades I don’t really know how to respond because the scenario outlined here is not one I recognise. My button would be a , so no, I wouldn’t have a .button class, it’s superfluous. What I would have is: - a global palette specified via CSS variables - overrides for dark mode etc specified at the global level so I don’t have to worry about it at the component level -…
This is such a bikeshedding debate. While you don't recommend it, projects with Tailwind work . Over years. You can onboard new developers to it, able to contribute productively immediately . Likewise, you can pick up work after months or years and don't have to remember or rediscover how your styling layer works. The conventions and class names come really naturally fast, and you can always look it up. It's just not…
It's so common, that there is an expensive runtime package, `tailwind-merge`, that is used by default in the most popular component library.
Earlier quoted context omitted.
It’s funny, as someone that’s been using CSS for decades I don’t really know how to respond because the scenario outlined here is not one I recognise. My button would be a , so no, I wouldn’t have a .button class, it’s superfluous. What I would have is: - a global palette specified via CSS variables - overrides for dark mode etc specified at the global level so I don’t have to worry about it at the component level -…
Are you suggesting to style the tag name directly? Because that would create chaos in a codebase. is for semantics. It's possible that other design system components need the same semantic element.
And as you say, it’s for semantics so I wouldn’t use .button anyway as it doesn’t carry the right specificity for styling.
This is such a bikeshedding debate. While you don't recommend it, projects with Tailwind work . Over years. You can onboard new developers to it, able to contribute productively immediately . Likewise, you can pick up work after months or years and don't have to remember or rediscover how your styling layer works. The conventions and class names come really naturally fast, and you can always look it up. It's just not…
Why wouldn't you? Suppose you have Button class with `btn btn-primary`. The Button accepts className override so you can do . In this case you use tailwind-merge or clsx. Your Button implementation would be clsx('btn btn-primary', className), in which case right most class name prevails.
Other than that, I agree tailwind is great. It lets you keep things all in one place. Names aren't particularly difficult to memorize and reason about and autocomplete does a great job. Build utility classes or proper components to encapsulate the styling and you're fine. What benefit do I have going to a css file to review my button styling over the actual Button component?
Earlier quoted context omitted.
You just make a design system in your tailwind.css, following the documentation. You can optionally use something like daisyui if you do not have designer skills or the time. That handles consistent sizing, spacing, text, colors, dark mode, and anything else your design system needs. It all compiles down to css in the end, so no runtime overhead and gives you the superior tailwind dx during development.
Almost none of that is specific to Tailwind though, you can take any design system in CSS with or without JS and make the same argument right?
I simply answered his question - tailwind is indeed just plain old CSS with a more ergonomic DX.