Curious whether there’s anyone here not using Tailwind - if you’re not, what are you using instead and was there any specific reason why you decided against Tailwind?
I use it but in decoupled setup. Using Phoenix only for API.
2 Likes
I use it only by default, ie, I make sure everything that comes by default in the framework is working fine t´but then, I override it by set different levels of CSS rules that are called after Tailwind in the CSS file and also by creating specific CSS rules for each project that have precedence over Tailwind. And when defining components I place their Css inside so I create a layered approach where everything just works and if I don’t feel I need to use something different Tailwind defaults just work and when I want my own rules they work in a targeted way.
2 Likes
I don’t use it. I much prefer using SASS.
I used a similar utility library (Bass CSS) 10 years ago, and have since worked on many projects that use Tailwind, and to me it seems like a huge step backwards with its sea of CSS classes that are a pain to reason about and that always seem to result in a non-uniform UI.
It’s possible that some people are using it well, but I haven’t personally seen it and I’m happy using SASS.
2 Likes
Yes, Tailwind can impact performance negatively. As CSS is more than just utility classes, you have to consider how the browser render.
But that is usually only a problem if you’re targeting a more native feeling.
1 Like
I don’t use Tailwind, nor esbuild…
I prefer [rsbuild](https://rsbuild.rs/) instead. It’s a rust builder, so the speed is good. And it is based on webpack.
Also I don’t really have the choice for css. And I don’t like Tailwind
So I always start my project with –no-assets, and build my own assets pipeline.
One more reason is I need to customize for each client, I don’t want my html to be full of classes, I prefer to customize via css instead.
I understand the reason why it has changed. But it means to avoid using npm, and use a fixed css framework
5 Likes
We use pure CSS at work. Our design system somewhat closely follows Every Layout though we have a few utility classes. IIRC we chose to not go with Tailwind to avoid the whole “Well there is a new thing out now that has these advantages and it’s hard to hire anyone who likes Tailwind anymore” whereas vanilla CSS will never go out of style (unless the web itself is completely overhauled).
Personally, I love Tailwind and am using it in a production project for a client. I also like working with pure CSS, though, which I use on my personal site. I haven’t used anything like SASS or LESS in several years at this point.
2 Likes
I do not see the value of Tailwind. It stands against what CSS should be IMHO. I just write my CSS by hand right now.
10 Likes
I am using beercss and I like it. Its so simple and small. Looks good on desktops as well as mobiles.
2 Likes
That looks nice! If Phoenix should have any CSS framework, it should be one without a build step.
I’ve used Tailwind on several professional projects and I really dislike it.
It’s unfortunate that it’s become a default in so many Elixir projects, where most component frameworks default to use Tailwind while using regular CSS would make more sense and would make it usable in both tailwind and non-tailwind contexts.
Bunding something like pico.css or similar as the default would make more sense with Phoenix IMO, and leave Tailwind as an opt-in rather than an opt-out. (Or just use regular CSS for the components of course.)
3 Likes
I’ve been using Tailwind a lot and we’re using it in a project at work, however for LiveView I find it quite unsuitable because of all the class diffing over the wire and resulting DOM updates.
Long before Tailwind ever existed I came to the conclusion that utility classes + components are the way to go with CSS (imo obviously) and with all the new:ish niceties of CSS layers, @starting-style, light-dark(), color-mix() combined with :has, :is and :where it’s just far easier to write CSS manually with the benefit of much more optimal LiveView messages. I do include the preflight and variables from Tailwind (as stand alone files) because I think they’re sane defaults and the colors are nice.
This combined with esbuild and I feel I have a really nice way of doing web.
1 Like
Could you clarify on that, please? Do you mean that this leads to more often sending diffs from the server?
Marlus did a great talk about the topic:
4 Likes
You already got a good video referenced, but yes, since most of the time your classes are a list (variable) and LV is forced to send it as a whole.
Very common are things like
<div class=”form-element”>
<input … class={[“bg-blue-500 text-sm rounded-xl”, error && “bg-red-500”]} />
<div :if={error} class="errors">You have an error</div>
</div>
Instead you can do something like the following (CSS supporting nesting selector nowadays really help).
.form-input {
background: blue;
}
.form-element {
&:has(.errors) {
.form-input {
background: red;
}
}
}
<div class=”form-element”>
<input … class="form-input" />
<div :if={error} class="errors">You have an error</div>
</div>
Somewhat contrived maybe, but I think it shows the concept of having a few variables as possible in your LV and letting CSS do the “heavy” lifting.
2 Likes
I’ve been bundling Pico with my personal flavour of Phoenix. Works great, some of the buttons in forms are a bit wide, but it is easy to fix.
1 Like
That’s actually interesting, thanks. I’ve been doing a lot of LiveView lately and still trying to make it as fast as it can possibly be.
We do make a heavy use of Tailwind however, and replacing it is not on the table – I wonder how can we still make use of those techniques when you f.ex. change a class or two depending on state.
I’ll watch the video.
We learned a big lesson from Tailwind, especially with the release of version 4. If you own a UI library and are planning to have many components (more then 90), it’s better to write pure CSS instead of using Tailwind. Unfortunately, for the Mishka Chelekom project, there’s no turning back, we have to continue with Tailwind.
From version 2 to 3, some parts of the code changed, and now it’s been a week that we’ve been dealing with code issues caused by the changes in priority in Tailwind version 4.
All colors changed in Tailwind 4 for example 
3 Likes
Even better - do it semantically instead of classes:
<div>
<input aria-invalid={error} />
<div class="error">You have an error</div>
</div>
And in CSS:
.error { display: hidden }
input:invalid {
background: red;
& + .error, &[aria-invalid] + .error { display: block }
}
4 Likes
I was a primarily front-end-focused developer for 6 years, in my previous life. I really dislike Tailwind because everything it does, I can do better with plain CSS. I know how to write maintainable code and use the cascading styles to my advantage.
2 Likes
