AstonJ
Anyone not using Tailwind in a Phoenix project?
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?
Most Liked
hauleth
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.
garrison
I’ve written about this before on here, but I don’t use Tailwind. I wrote a small library that extracts style tags from HEEx components, scopes them in the HEEx (by adding an attribute), and then scopes all of the selectors and compiles them into an output CSS file.
I wrote this code ages ago and it remains by far the most utility I have ever managed to extract from one stupid hack. It’s literally just a mediocre CSS parser/generator (which I desperately need to rewrite from scratch) and a macro/compiler that hijacks the HEEx and rewrites it with a stupid regex because I was too lazy to parse the HTML.
And yet, despite that, it’s been essentially the perfect solution. Here is what some of the components look like. I use nothing but vanilla CSS (with a shorthand $variable syntax because I am not writing var(--variable) 10,000 times). I can always use the latest CSS features and never have to worry about framework churn.
But I also inherit all of the best parts of Tailwind. Styles are co-located and scoped to their components. Dead styles are easily eliminated due to the co-location. Composability is not an issue due to scoping. There is no jumping around, and no worrying about name collisions.
The final advantage of Tailwind, perhaps the biggest, is that you get an extensible design system out of the box. So I built that too! The defaults are here, but I designed it to expand the design system recursively. Here’s my default. It even has themes! I then have app configs which in turn extend that one.
I’m used to things having tradeoffs but to be totally honest, for me, this remains the uncontested perfect solution. I have run into no meaningful problems with this approach.
I think I will clean this up and turn it into a real library (yes this is like the 10th time I’ve said this) once macro components ship as they will make it much less hacky. I’ll probably extract the CSS parser/generator to a separate library and maybe try to make it composable (like PostCSS or something, so people can minify etc if they want).
hauleth
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 }
}
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #hex









