4 ms·
> I don’t see how that’s an argument for CSS “being advanced enough” That's a separate argument. I hear mostly two justifications for tailwind: 1. It is (or
by rglullis 2y ago
> I don’t see how that’s an argument for CSS “being advanced enough”
That's a separate argument.
I hear mostly two justifications for tailwind:
1. It is (or used to be) hard to do things in CSS like variables, calculated properties, themes, scoped rules / namespacing. (Pre/Post) Processors are going to be required anyway, so we might as well use Tailwind
2. It gives frontend developers and designers a common language (the utility classes) which makes it easier to establish workflows.
My argument for (1) is that CSS already supports a lot of things that used to require processors, and (2) could be achieved with a simple "library" that could just be imported directly.
- jitl 2y agoI agree neither of those seem like good reasons to pick tailwind. My take is that it removes needless indirection in any codebase that already has “components” - react/vue/solid/etc, template partials, functions that return html strings, whatever. See comment here: https://news.ycombinator.com/item?id=42804831 https://news.ycombinator.com/item?id=42804831 For that reason, plus it’s concision, I find it more productive use of time compared to css-in-separate-file. If you don’t have components for separating semantics from presentation, then tailwind is less a good fit.