We now have colocated JS so I see no issue with colocated CSS. Guess it’s upcoming with the new Macro components.
BartOtten
thomasbrus
I think it depends on what you’re actually trying to solve and for me it comes down to the following:
- a way to manage design tokens, with sensible defaults and naming conventions
- utility classes for layouts/positioning and one-off visual changes
- a maintainable & readable way to manage CSS for reusable components
So then you naturally arrive at something like this: stylesheets just for components (using some naming convention such as BEM, CSS Modules, etc.) in combination with PostCSS/Tailwind.
Via theme or @apply you can reference design tokens from Tailwind.
.heading { font-size: theme('fontSize.xl') }
.card { padding: theme('spacing.4') }
The beautify of this is that you can now combine these components with utility classes:
<h1 class="heading flex gap-2">Heading <svg ... /></h1>
<div class="card mt-4"></h1>
Since the composition of components differs page it makes a lot of sense to use utility classes instead of writing additional CSS for each situation.
On top of that you can even make one-off visual changes to components, until it makes sense to introduce a new component property:
<h1 class="heading border-b">Heading with border bottom</h1>
There are a lot of things that Tailwind does that you would otherwise end up doing yourself, just with more code to maintain and probably less well thought out.
It’s a bit unfortunate that Tailwind has become a bit of a religion and there isn’t always a ton of discussion about what styling problems we’re actually trying to solve 
(not talking about this thread, just in general).
So I’m not married to a specific framework, it’s just that I found that this is sensible way to go about things.
3
AstonJ
For those suggesting using @apply, isn’t it against the Tailwind way?
Edit: From google’s AI mode:
Why Wathan regrets @apply
Encourages bad practices: Wathan says that
@applytempts developers away from Tailwind’s core utility-first philosophy. Instead of reusing utility classes directly in the HTML, developers are led to create their own custom classes that contain a bundle of utilities, which is exactly the practice Tailwind was designed to avoid.A “bait and switch” : In 2020, Wathan confessed on X (formerly Twitter) that
@applywas originally added to “trick people who are put off by long lists of classes into trying the framework”. However, he emphasized that developers “should almost never use it”.Outrageously complicated behavior: According to Wathan, the underlying behavior of
@applyis very complex, which makes it difficult for developers to build a proper mental model of how it works. This complexity makes it easy to misuse and leads to confusing results.Poor CSS architecture: By hiding utility classes behind custom class names,
@applycan lead to less readable and maintainable code over time. It can also cause unexpected side effects that go against the framework’s predictable nature.The Tailwind philosophy
The core principle of Tailwind CSS is to use single-purpose utility classes directly in your HTML. For example, instead of defining a custom
.btn-primaryclass in your CSS file, you would apply thebg-blue-500,text-white, andfont-boldutility classes directly to your button element.This approach, known as “utility-first,” offers several benefits:
- You don’t need to leave your HTML file to style your components.
- You avoid accumulating custom CSS that is rarely reused.
- You can easily make design changes by adding or removing classes in the HTML.
The verdict on @apply
Wathan has stated that if he were to create Tailwind CSS from scratch,
@applywould not be included. His stance is a clear signal that for most use cases, developers should stick to Tailwind’s core utility-first principle rather than relying on@applyto mimic traditional CSS preprocessors.
3
thomasbrus
Oh yes good point!
Perhaps I should have left that out, I tend to use theme() (in v4 that’s replaced with just CSS vars I believe). I agree that there isn’t really a use case for @apply, except laziness/convenience 
.
The
applyfeature in Tailwind basically only exists to trick people who are put off by long lists of classes into trying the framework.
The irony of this statement is that @apply puts your long list of utility classes in your CSS file 
.
I get the point about that you don’t technically “need” BEM, since you can reuse utility classes via partials or components as well.
But I find that it gets pretty unreadable pretty quickly. It is a bit unfortunate that this leads people to disregard Tailwind entirely.
Especially for components with many different states, it is (imho) just more readable to use a stylesheet and some naming convention such as BEM (or whatever you prefer).
It just helps a ton if your button has a .button--primary class on it instead of a long list of utility classes.
2
BartOtten
Tailwind is crafted for use with components, so component name would replace CSS class name.
.button-primary → <.button color=“primary”>
.heading → <.heading>
As a result your templates are not riddled with classes, as most “look how bad” examples show.
That being said: if you do “cleanup” the code by using components, you end up shimming all HTML elements. Hence native HTML elements such as h1 etc don’t have styling in Tailwind (without plugin Typography)! You are supposed to (inside) ‘component’ them 
So no <div classes=“a thousand classes for this container containing the main content”> but <.main_content>
Wait, did we just shift from “ow no a central CSS file and having to come up with class names” to “a zillion components at no default places and having to come up with components names”?
Update:
In this thread my opinions (multiple!) while reading the book.
I see I agree with myself from the past:
For React 3, components are created (in the book) : Header, SubHeader and SubSubHeader. The next example uses a plain JS function named
titleto return a list of ultility classes. Let’s apply those to H6: SubSubSubSubSubHeader and subSubSubSubSubTitle()! Guess we are back at “naming things is hard”.
and
What I’ve learned so far:
- The solution to prevent duplication requires you to come up with names.
- Creating components/partials can cause code with weird syntax AND you still need to come up with those names.
- When all gets ugly, you can use
@apply…just know you will have to…come up with some names.I feel like we are going in circles, just so Tailwind can get away with “duplication is not an issue” and “with Tailwind you don’t have to come up with names for your shared CSS properties.
Glad those names are not CSS names cause those were really hard to come up with according to Tailwind
and
But can anyone explain me why it is
font-boldanditalicinstead offont-italic? I understand from a CSS mapping point of view but I rather would stay within the ‘namespace’ so the guessing would be easier. [..] So padding is done withp{side}-{size}and border withborder-{side}-{size}. Mind the dash. Why Tailwind?
Not using Tailwind daily, I still fail to pick the proper prefix text- or font- or none at all, and have to learn all the new ‘naming conventions’ (read: is there consistency at all?)
That being said: I use it in all my lib demo apps.
7
BartOtten
1. But CSS files tend to blow up with unused classes!
Well, build something to find used ones diffing it with the class names in the CSS file to drop unu…wait..there must have been a point in time the Tailwind compiler did just that!
2. Who can remembers all existing class names?
The same people who remember all Tailwind oddities?
3. But you can’t see how the component looks from source code
But you can see all other things; which get’s harder if you add 20 class names on each element.
4. But you can hide those in editor
True, but now 3… and this is a solution for a problem we did not have.
5. But you can’t do :hover in style attribute
Using style attribute is not mandatory.
To me it seems all issues Tailwind ‘solves’ could and should have been solved by a formatter to remove unused classnames (on request) and ‘LSP for CSS’: “Jump to class definition”, “Show class references” in all editors. Proof me wrong
4
derek-zhou
I disagree, because I view components as encapsulation of functions, not encapsulation of styles. The same component can be instantiated several times, each with a very different style. In your example you only hide the dirty laundry at a lower level. My pet peeve with Tailwind is exactly that: it kinds of force you to deeply couple function concerns with style concerns.
5
BartOtten
So we agree I demonstrated the ‘blessed’ Tailwind way and linked to all my objections against it.
4
thomasbrus
I think the argument regarding the utility class soup is also about:
- what the markup looks like in the browser / inspect element
- that when you open your component file, it is now littered with utility classes
It was like this in an earlier version of petal components but they switched to proper class names (I think also to make theming easier): petal_components/lib/petal_components/button.ex at v0.19.7 · petalframework/petal_components · GitHub
1
pepicrft
If you need a component kit native to Phoenix LiveView you can check out our build system Noora: Open sourcing Noora for the web
You can also see it live in our project at https://tuist.dev/tuist/tuist
@cschmatzler did and amazing job putting it together, and we are actively maintaining it and bringing new components regularly.
4