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