41–50 of 179 posts
Cute idea, but it is pretty clear the author doesn't consider practical consequences, so why should I trust their judgement about Tailwind?
Centrally the problem is this: large CSS requires a lot of active effort to prevent it becoming spaghetti code.
Writing your own CSS can work in solo projects or small projects but Tailwind was designed for large projects, teams and developers with an irrational fear of CSS.
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.…
And just a shared color definition file.
It didn't work in practice, because people want to structure their document based on how they expect it to be presented.
My understanding is thay HTML5 was built on the understanding that language purity just went in the way of productive compromise.
I've used a lot of tailwind professionally over the last few years and I agree with this article - it is spot on. I never even use tailwind in my own stuff, even though I think that small devoper-led side-projects are where it is a good fit (and the reason for it's popularity).
To be clear, I like css and I find the cascade a great tool, but I also have first hand experienced the pain of too many chefs in the frontend styling kitchen and the havoc that seemingly innocent tweaks here or there can wreak on a site and I prefer tailwind for that reason.
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.…
I feel like scoped css and component libraries fixed this issue. I don’t have a .button, I just have a that has all its css self contained. And just a shared color definition file.
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.…
So you end up wrapping the components (if you’re using react or something similar) so that you can centralise the styles and use a set of consistent components instead. And at that point it really doesn’t matter if you use tailwind, custom classes, per component css modules, style attributes, css-in-js, or what have you. At this point I prefer to drop the extra dependency and use per-component css files with css module imports. (Or when I do less custom styled UI’s, I prefer to use Mantine and use its attributes for layout and styling)
While I don’t really have a strong opinion on Tailwind CSS, I do have a strong negative reaction to websites who advertise to everyone how many people are on the page, especially when that’s shoved in our faces and people can send malware links and spam to everyone else (as is happening in droves).
Quickly, I realized Tailwind is documented on top on CSS, no way around. This makes you keep in mind both.
No idea why is Tailwind even a thing.
.button {
@apply py-2 px-4 bg-indigo-500 text-white font-semibold rounded-lg hover:bg-indigo-700 focus:bg-indigo-700;
}
.button {
@apply
py-2
px-4
bg-indigo-500
text-white
font-semibold
rounded-lg
hover:bg-indigo-700
focus:bg-indigo-700
;
}