I'm a professional PHP, Python and Javascript developer from the UK. I've worked with Django, Laravel, and React, among others. I also maintain a legacy Zend 1 application.
No, it isn't, any more than an approach like BEM is. You're still using classes for styling, but the scope of those classes is generally reduced a little. It's definitely not a one-to-one relationship between Tailwind classes and single CSS rules in every case. And, by using the @apply directive you can easily extract the styles used to a stylesheet.
Fundamentally Tailwind is an abstraction over CSS that provides the following benefits:
Limits you to a predefined palette of colours, proportions and so on. You can change this palette if it restricts you, but by limiting the scope of what classes are available for styling, it helps to ensure a greater consistency in your application - for instance, you won't end up with Alice using 3px for padding, Bob using 4px and Chris using 2px
Provides consistent modifiers for things like media queries (including dark mode) and state such as focus or hover. Inline styles can't do that
Makes it much less likely CSS rules will grow out of control. By encouraging use of the predefined Tailwind classes and discouraging making your own, it makes it easy for tools like PurgeCSS to strip out unwanted styles, resulting in typically smaller CSS bundles in the production application.
It's a particularly good fit for component-based JS libraries like React or Vue where you're actively encouraged to extract common UI sections to their own component. In that context it tends to be extremely quick to style it using Tailwind once you get up to speed, making it extremely useful for prototyping. Further into your project, once you have some styles established, then if you want to reuse them in ways that template partials or separate UI components don't facilitate, then it's easy to use the @apply directive to extract common styles and create your own more conventional classes, without losing the advantages of consistency mentioned above.
Honestly, I thought the same at first and it took a while for it to click, but I'd never go back. I maintain a big legacy project with a huge pile of messy CSS that I inherited and is very difficult to strip out. That would be virtually impossible for that to happen with Tailwind.
It's definitely not a one-to-one relationship between Tailwind classes and single CSS rules in every case.
That's not the important part though. Whether you're using classes or inline styles, even if one lets you do more things with less typing, the fundamental difference is that you are inlining the actual styling into your HTML.
There may be a CSS document somewhere that defines some more powerful tools in the form of classes, but those aren't styling "rules" in the same sense as with normal CSS; they end up being more similar to CSS properties, in that they just toggle atomic design elements like a colour or the text alignment.
The actual styling is still in your HTML though, so no, it is just plainly wrong to claim utility classes are somehow fundamentally different than inlining CSS using the style attribute. They may be more powerful and convenient, and that might for many be the deciding factor as to why this approach is okay to use while inline CSS is evil; but some sort of defense has to be made. One cannot simply claim that "they're different things" and dismiss all criticism of inlining styles into HTML.
There's a separate discussion to be had about whether enough of the problems with inline CSS aren't present, or whether the most relevant ones still remain, and that discussion can be a lot more nuanced and ultimately up to personal preference and picking the right tool for the job.
I'm a professional PHP, Python and Javascript developer from the UK. I've worked with Django, Laravel, and React, among others. I also maintain a legacy Zend 1 application.
The @apply directive renders much of that moot, though, since once you've settled on a style that works you can easily use that to extract common patterns into reusable classes. It depends on the context you're using it in, and for using component libraries like React it often makes less sense, but certainly if you're using Tailwind in something like Blade or Twig templates then using @apply is more commonplace.
I'm a professional PHP, Python and Javascript developer from the UK. I've worked with Django, Laravel, and React, among others. I also maintain a legacy Zend 1 application.
No, because Tailwind still works as an abstraction layer. And you can combine the two approaches however you see fit - it doesn't have to be either everything using the utility classes direct or everything using the apply directive.
It's like JSX in that it sounds arse-backwards when you first hear about it, but if you try it then once you get over the hump it starts to make a lot more sense.
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.
No, it isn't, any more than an approach like BEM is. You're still using classes for styling, but the scope of those classes is generally reduced a little. It's definitely not a one-to-one relationship between Tailwind classes and single CSS rules in every case. And, by using the
@applydirective you can easily extract the styles used to a stylesheet.Fundamentally Tailwind is an abstraction over CSS that provides the following benefits:
It's a particularly good fit for component-based JS libraries like React or Vue where you're actively encouraged to extract common UI sections to their own component. In that context it tends to be extremely quick to style it using Tailwind once you get up to speed, making it extremely useful for prototyping. Further into your project, once you have some styles established, then if you want to reuse them in ways that template partials or separate UI components don't facilitate, then it's easy to use the
@applydirective to extract common styles and create your own more conventional classes, without losing the advantages of consistency mentioned above.Honestly, I thought the same at first and it took a while for it to click, but I'd never go back. I maintain a big legacy project with a huge pile of messy CSS that I inherited and is very difficult to strip out. That would be virtually impossible for that to happen with Tailwind.
That's not the important part though. Whether you're using classes or inline styles, even if one lets you do more things with less typing, the fundamental difference is that you are inlining the actual styling into your HTML.
There may be a CSS document somewhere that defines some more powerful tools in the form of classes, but those aren't styling "rules" in the same sense as with normal CSS; they end up being more similar to CSS properties, in that they just toggle atomic design elements like a colour or the text alignment.
The actual styling is still in your HTML though, so no, it is just plainly wrong to claim utility classes are somehow fundamentally different than inlining CSS using the
styleattribute. They may be more powerful and convenient, and that might for many be the deciding factor as to why this approach is okay to use while inline CSS is evil; but some sort of defense has to be made. One cannot simply claim that "they're different things" and dismiss all criticism of inlining styles into HTML.There's a separate discussion to be had about whether enough of the problems with inline CSS aren't present, or whether the most relevant ones still remain, and that discussion can be a lot more nuanced and ultimately up to personal preference and picking the right tool for the job.
The
@applydirective renders much of that moot, though, since once you've settled on a style that works you can easily use that to extract common patterns into reusable classes. It depends on the context you're using it in, and for using component libraries like React it often makes less sense, but certainly if you're using Tailwind in something like Blade or Twig templates then using@applyis more commonplace.At that point, haven't you just gone full circle and basically achieved nothing other than introducing two new dependencies?
No, because Tailwind still works as an abstraction layer. And you can combine the two approaches however you see fit - it doesn't have to be either everything using the utility classes direct or everything using the apply directive.
It's like JSX in that it sounds arse-backwards when you first hear about it, but if you try it then once you get over the hump it starts to make a lot more sense.