Actually CSS Modules don't add any complexities. This is like everything, many like to use CSS frameworks, others prefer CSS-in-JS, others prefer libraries like Chakra UI.
I think this comes from the preferences of each one, but for example Tailwind pleases me because I can use it for web and mobile (there are dependencies on the community to use with React Native), the website load is fast because it's CSS and because the bundle build size gets smaller.
And with classNames the join of classes becomes simple even using conditional rendering.
I mean using tailwindcss inside modules adds complecity not using modules itself. Each new className gets it's own css from tailwind @apply. Which would mean the more classNames you've used with @apply the bigger your bundle size will get as you are not using utility classes anymore, but just compiling tailwind into normal css.
[number of classNames] * [number of @apply] will resuly in that much more css being generated as opposed to having tailwind as a classname where it reuses the same utility in many different places.
Now I understand what you wanted to say (sorry for being slow), it is without a doubt one of the negative aspects. In that respect I completely agree with you.
One thing I like to do is separate aesthetic readability from how easy the code is to understand.
Aesthetic readability is how visually pleasing the code looks. How "clean" and "neat" it is. This is something that tools like Prettier help with, and something that Tailwind definitely is not good at 😅
However, tailwind excels at understandability. If you ask the question "what styles does this element have", that question can't be answered any more immediately than with inline styling: you have your answer right on the element you're looking at! Other solutions require you to go to another part of the file at best, an entirely separate file at worst. Lots of context switching, lots of tedium.
The aesthetic hurdle is still too big for some, and I understand that. But this understanding of "readability" hopefully helps to see where Tailwind lovers are coming from 😊
I agree that once I got over the initial learning curve of tailwind. It does look better not having property, value pairs in the css.
Having said that i can't quite recommend using tailwindcss just for the aestetics as it fails in reducing bundle size. It has issues with linting.
Tailwindcss is soo close to being amazing, tho sadly not yet for me.
Devs should definitely not have free access to give arbitrary values to margins paddings and Font sizes, and the way tailwind let's you easily build your own design system is really nice, but the implementation is not quite there yet.
If sass/scss allowed $variables / % placeholders to contain key value pairs or whole blocks of styles. Then tailwindcss would be in trouble.
If we compare using tailwind vs. regular CSS, regular CSS would end up having the larger bundle size, right? With tailwind, you're reusing the same class name for any bit of styling. With regular CSS, you make a new class name which could share some styling with other existing class names. If you mean the size of the HTML, the repetition is very kind to gzipping and other compression algos.
It has issues with linting.
What issues? The VSCode TailwindCSS extension, for example, warns if you try to apply multiple classes with conflicting values. Also gives you nice autocomplete.
Devs should definitely not have free access to give arbitrary values to margins paddings and Font sizes
Hopefully I understand you correctly. Are you saying that tailwind does give you arbitrary values? Because half the point of tailwind is to not. The range of values is large, for sure, but it's still a much more limited subset of values than in any traditional CSS codebase. See here under "Enforced Consistency". The post is a good read overall.
Tailwind JIT does add an arbitrary values feature, e.g. p-[13px], but it's considered a last resort. Sometimes you do need some random one-off value. The style attribute was always used for that, too.
If sass/scss allowed $variables / % placeholders to contain key value pairs or whole blocks of styles. Then tailwindcss would be in trouble.
I don't see the connection here, or why this would put tailwind "in trouble". Regardless of what features come to Sass, it would still be based around writing arbitrary styles in separate files; utility CSS users want to avoid that.
If we compare using tailwind vs. regular CSS, regular CSS would end up having the larger bundle size, right? With tailwind, you're reusing the same class name for any bit of styling. With regular CSS, you make a new class name which could share some styling with other existing class names. If you mean the size of the HTML, the repetition is very kind to gzipping and other compression algos.
If you're using tailwindCss with @apply no, it is compiled to regular css, and end result is literally the same as just writing css. look at previous comments in the thread for the picture output.
Using tailwind in html jsx or tsx, it horribly reduces readability and in the docs tells you if you don't like it use apply to solve the problem it creates.
What issues? The VSCode TailwindCSS extension, for example, warns if you try to apply multiple classes with conflicting values. Also gives you nice autocomplete.
I'm mainly talking about using tailwind inside css files.
You need disable standard vsCode linting and replace it with another extension to fix it.
Hopefully I understand you correctly. Are you saying that tailwind does give you arbitrary values? Because half the point of tailwind is to not. The range of values is large, for sure, but it's still a much more limited subset of values than in any traditional CSS codebase. See here under "Enforced Consistency". The post is a good read overall.
My point was in favour for tailwind as it makes it easier to use set values provided by default by tailwind or if you got someone knowledgable that has added consistent styles to the tailwind config.
Tailwind JIT does add an arbitrary values feature, e.g. p-[13px], but it's considered a last resort. Sometimes you do need some random one-off value. The style attribute was always used for that, too.
That is a nice feature, but it at the moment fails if you need to use % instead.
I don't see the connection here, or why this would put tailwind "in trouble". Regardless of what features come to Sass, it would still be based around writing arbitrary styles in separate files; utility CSS users want to avoid that.
Assuming you use tailwind only in css to improve html readability (seperation of concerns and all that) the only benefit at the moment tailwind provides is shortening key value css pairs to single variables inside @apply.
If scss supported something similar, tailwind would be in trouble as tailwind would lose any benefit it can provide inside css.
Ah, so those points were in reference to using tailwind in css with @apply. My first comment was actually recommending not to do that for various reasons 😂
I agree that using Tailwind in CSS files with @apply is not much better than using regular CSS; if you're doing it that way, you may as well not use Tailwind.
Using tailwind in html jsx or tsx, it horribly reduces readability
I feel like people are better off getting used to the reduced aesthetic cleanliness, there are mountains of benefits when one does. I've read so many testimonials of "at first it looked horrifying, but after using it, I love it!", including from myself 😊
and in the docs tells you if you don't like it use apply to solve the problem it creates.
Assuming you mean this section of the docs, it says to use this feature to reduce repetition, not to make your HTML cleaner. Visual HTML cleanliness is a complete non-goal with tailwind. That's just something people co-opted when they saw @apply as a "solution" to Tailwind looking weird and unusual.
If scss supported something similar, tailwind would be in trouble as tailwind would lose any benefit it can provide inside css.
To be fair, SCSS already has features like parametric mixins and functions that let you mimic what @apply can do, so Tailwind is already "in trouble" in that sense. But generally? Nah. Even then, I personally haven't had a use for Sass in ages, even before I started using Tailwind.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Using tailwind in css modules seems like added complexity with little benefit.
Readability is lost due to everything being inline.
Utility classes are lost and converted into simple css which results in the same bundle size.
I'm really trying to like tailwind but the more i use it the more flaws it seems to have.
Actually CSS Modules don't add any complexities. This is like everything, many like to use CSS frameworks, others prefer CSS-in-JS, others prefer libraries like Chakra UI.
I think this comes from the preferences of each one, but for example Tailwind pleases me because I can use it for web and mobile (there are dependencies on the community to use with React Native), the website load is fast because it's CSS and because the bundle build size gets smaller.
And with classNames the join of classes becomes simple even using conditional rendering.
I mean using tailwindcss inside modules adds complecity not using modules itself. Each new className gets it's own css from tailwind @apply. Which would mean the more classNames you've used with @apply the bigger your bundle size will get as you are not using utility classes anymore, but just compiling tailwind into normal css.
[number of classNames] * [number of @apply] will resuly in that much more css being generated as opposed to having tailwind as a classname where it reuses the same utility in many different places.
Now I understand what you wanted to say (sorry for being slow), it is without a doubt one of the negative aspects. In that respect I completely agree with you.
One thing I like to do is separate aesthetic readability from how easy the code is to understand.
Aesthetic readability is how visually pleasing the code looks. How "clean" and "neat" it is. This is something that tools like Prettier help with, and something that Tailwind definitely is not good at 😅
However, tailwind excels at understandability. If you ask the question "what styles does this element have", that question can't be answered any more immediately than with inline styling: you have your answer right on the element you're looking at! Other solutions require you to go to another part of the file at best, an entirely separate file at worst. Lots of context switching, lots of tedium.
The aesthetic hurdle is still too big for some, and I understand that. But this understanding of "readability" hopefully helps to see where Tailwind lovers are coming from 😊
I agree that once I got over the initial learning curve of tailwind. It does look better not having property, value pairs in the css.
Having said that i can't quite recommend using tailwindcss just for the aestetics as it fails in reducing bundle size. It has issues with linting.
Tailwindcss is soo close to being amazing, tho sadly not yet for me.
Devs should definitely not have free access to give arbitrary values to margins paddings and Font sizes, and the way tailwind let's you easily build your own design system is really nice, but the implementation is not quite there yet.
If sass/scss allowed $variables / % placeholders to contain key value pairs or whole blocks of styles. Then tailwindcss would be in trouble.
If we compare using tailwind vs. regular CSS, regular CSS would end up having the larger bundle size, right? With tailwind, you're reusing the same class name for any bit of styling. With regular CSS, you make a new class name which could share some styling with other existing class names. If you mean the size of the HTML, the repetition is very kind to gzipping and other compression algos.
What issues? The VSCode TailwindCSS extension, for example, warns if you try to apply multiple classes with conflicting values. Also gives you nice autocomplete.
Hopefully I understand you correctly. Are you saying that tailwind does give you arbitrary values? Because half the point of tailwind is to not. The range of values is large, for sure, but it's still a much more limited subset of values than in any traditional CSS codebase. See here under "Enforced Consistency". The post is a good read overall.
Tailwind JIT does add an arbitrary values feature, e.g.
p-[13px], but it's considered a last resort. Sometimes you do need some random one-off value. Thestyleattribute was always used for that, too.I don't see the connection here, or why this would put tailwind "in trouble". Regardless of what features come to Sass, it would still be based around writing arbitrary styles in separate files; utility CSS users want to avoid that.
If you're using tailwindCss with @apply no, it is compiled to regular css, and end result is literally the same as just writing css. look at previous comments in the thread for the picture output.
Using tailwind in html jsx or tsx, it horribly reduces readability and in the docs tells you if you don't like it use apply to solve the problem it creates.
I'm mainly talking about using tailwind inside css files.
You need disable standard vsCode linting and replace it with another extension to fix it.
My point was in favour for tailwind as it makes it easier to use set values provided by default by tailwind or if you got someone knowledgable that has added consistent styles to the tailwind config.
That is a nice feature, but it at the moment fails if you need to use % instead.
Assuming you use tailwind only in css to improve html readability (seperation of concerns and all that) the only benefit at the moment tailwind provides is shortening key value css pairs to single variables inside @apply.
If scss supported something similar, tailwind would be in trouble as tailwind would lose any benefit it can provide inside css.
Ah, so those points were in reference to using tailwind in css with
@apply. My first comment was actually recommending not to do that for various reasons 😂I agree that using Tailwind in CSS files with
@applyis not much better than using regular CSS; if you're doing it that way, you may as well not use Tailwind.I feel like people are better off getting used to the reduced aesthetic cleanliness, there are mountains of benefits when one does. I've read so many testimonials of "at first it looked horrifying, but after using it, I love it!", including from myself 😊
Assuming you mean this section of the docs, it says to use this feature to reduce repetition, not to make your HTML cleaner. Visual HTML cleanliness is a complete non-goal with tailwind. That's just something people co-opted when they saw
@applyas a "solution" to Tailwind looking weird and unusual.This part of the docs specifically says not to rely on class names to extract components.
To be fair, SCSS already has features like parametric mixins and functions that let you mimic what
@applycan do, so Tailwind is already "in trouble" in that sense. But generally? Nah. Even then, I personally haven't had a use for Sass in ages, even before I started using Tailwind.