Tailwind is a lot like Sass already, its utility classes with some helpers, however unlike Sass you don't have to write out everything.
And thanks to PostCSS you don't have to write that classes in the HTML you can make your own class and use the @apply line so your css file not got a ton of repeating code you can do far more on one line with Tailwind them you do with Sass.
You also not have to duplicate your selectors in your media queries blocks and many extra stuff like that you will be able to just handle more easy...
With smaller css files you can make changes faster and still got your pretty meaningful classes...
Also thanks to the JIT in the new version it's much faster then SASS overall or at least on my PC.
There is far more to Tailwind than you know, you may want to look into it before you type things like this... :D
My comment just say how to fix all his issues with Tailwind?
First of all Bootstrap and TailwindCSS are every different like Tailwind don't come with it's own components... and the classes will not really change all that much over the years because they base on the CSS it self.
Using a system like SASS with utility placeholders would compile into much smaller CSS
This is false thanks to TailWindsCSS JIT the files you export just got the css you need noting more, noting less... I would say it would be the same size or smaller... smaller if you disable the basic reset. This is not an issue anymore for some time now!
HTML classnames more meaningful.
Almost my complete comment is about not having to put any TailWindCSS classes in the html and that you can use it really easy in css it self with the @apply
Tailwind reminds me of the pre-css world where all styling was done with HTML attributes repeated again and again in a nearly illegible mess of markup.
One again this doesn't even come close to the pre-css world like style tags could not do responsive breakpoints, and Tailwind got a ton of this helpers.
I see arguments constantly for putting styling logic and markup all in the same file with styled components and the like and I'm left to think of the adage about those who don't study history. There is a lot of hubris and ego out there that builds first before understanding how we got to the percieved problem to begin with.
I totally agree that styled components and all that other react css, and css in Javascript are just one huge mess! But this got noting to do with Tailwind...
What I'm describing above is basically a subset of bourbon (thoughtbot.com/blog/introducing-bo...) which predated tailwind. I could use that if I wanted something pre-written.
Wiring up post-css to allow you to to use tailwind is fine. I don't see much difference in writing a property definition in css/scss and writing the same as a shorthand css utility class referencing a library. In the end you should make your decisions based on the cost of supporting dependency management and specialized configuration to do what would come out of the box if you just wrote the rules in the codebase you control yourself.
Keep in mind that you build a site once, but it may get new features multiple times per year and with security updates, breaking changes may need to be adopted along the way. The more hands that touch an application the more training or detective work (if it was developed on contract) the team will have to do. This amounts to cost too. The closer you stick to core technologies the faster you can hire and onboard new team members and the easier it is to find and solve problems. I just don't see Tailwind as necessary enough to justify these costs.
We're all going to regret how complicated our build systems have gotten in the next 5 years. I just keep hoping that the law of diminishing returns will stop us from continuing to layer complications just to get a small gain that is outweighed or negated by what is required to support it.
Tailwind is a lot like Sass already, its utility classes with some helpers, however unlike Sass you don't have to write out everything.
And thanks to PostCSS you don't have to write that classes in the HTML you can make your own class and use the @apply line so your css file not got a ton of repeating code you can do far more on one line with Tailwind them you do with Sass.
You also not have to duplicate your selectors in your media queries blocks and many extra stuff like that you will be able to just handle more easy...
With smaller css files you can make changes faster and still got your pretty meaningful classes...
Also thanks to the JIT in the new version it's much faster then SASS overall or at least on my PC.
There is far more to Tailwind than you know, you may want to look into it before you type things like this... :D
That doesn't address any of the problems with Tailwind though
What problems is that?!
I think @gibbitz already explained some of them quite well in their comment
My comment just say how to fix all his issues with Tailwind?
First of all Bootstrap and TailwindCSS are every different like Tailwind don't come with it's own components... and the classes will not really change all that much over the years because they base on the CSS it self.
This is false thanks to TailWindsCSS JIT the files you export just got the css you need noting more, noting less... I would say it would be the same size or smaller... smaller if you disable the basic reset. This is not an issue anymore for some time now!
HTML classnames more meaningful.
Almost my complete comment is about not having to put any TailWindCSS classes in the html and that you can use it really easy in css it self with the @apply
Tailwind reminds me of the pre-css world where all styling was done with HTML attributes repeated again and again in a nearly illegible mess of markup.
One again this doesn't even come close to the pre-css world like style tags could not do responsive breakpoints, and Tailwind got a ton of this helpers.
I totally agree that styled components and all that other react css, and css in Javascript are just one huge mess! But this got noting to do with Tailwind...
What I'm describing above is basically a subset of bourbon (thoughtbot.com/blog/introducing-bo...) which predated tailwind. I could use that if I wanted something pre-written.
Wiring up post-css to allow you to to use tailwind is fine. I don't see much difference in writing a property definition in css/scss and writing the same as a shorthand css utility class referencing a library. In the end you should make your decisions based on the cost of supporting dependency management and specialized configuration to do what would come out of the box if you just wrote the rules in the codebase you control yourself.
Keep in mind that you build a site once, but it may get new features multiple times per year and with security updates, breaking changes may need to be adopted along the way. The more hands that touch an application the more training or detective work (if it was developed on contract) the team will have to do. This amounts to cost too. The closer you stick to core technologies the faster you can hire and onboard new team members and the easier it is to find and solve problems. I just don't see Tailwind as necessary enough to justify these costs.
We're all going to regret how complicated our build systems have gotten in the next 5 years. I just keep hoping that the law of diminishing returns will stop us from continuing to layer complications just to get a small gain that is outweighed or negated by what is required to support it.
Scss itself has a very steep learning curve