Anyone not using Tailwind in a Phoenix project?

There are two main approaches when working with styles. The first is designing directly in HTML, which is primarily used for quick prototyping. This involves using the style=“” attribute. Tailwind CSS is an extension of this approach.

The second approach is “design-first.” Using Sass (or a similar preprocessor) is very helpful here. You begin by writing a _variables.scss file, typically between 50-100 lines. It is best to define colors, etc semantically, such as $color-primary, rather than literally, like $color-gray. This allows you to change your entire color palette with minimal effort.

You will also create a _main.scss file for global styles and can start with something like _detail-page.scss for page-specific styling. When following a mobile-first methodology, you write the desktop styles directly within the same class, using media queries.

Ultimately, you’ll have around 10–20 style files, each approximately 50–100 lines. By using a tool like a monorepo alongside a development server such as Vite—which is perfect for this—you can design and test several sites with live reloading, all sharing a central design system.

Your template will then be robust and maintainable for 5–10 years with only minor updates. For each component, you’ll typically work with no more than 10 classes to consider. In projects with multiple developers, this approach makes it extremely straightforward to identify and correct any inconsistencies in design implementation.

• tokens defined with Style Dictionary, exported to any needed format
• map SASS variables (or mixins/functions depending on the use case) to CSS custom properties (allows you to spot the use of undefined custom properties at build time)
• tokens use CTI naming
• for colors, differentiate between base tokens (color-gray-400), semantic tokens (color-background-secondary; reference base tokens) and component tokens (color-button-background-primary-hover); see also Token naming section of the Design Token Color module
• base color palettes can be generated or handpicked, but that’s up to the designer; I might do either for side projects
• also check the Design Token Format module
• utility classes generated from tokens
• CSS classes
  • component classes: just the component name (e.g. `.box`)
  • component sub classes: always prefixed with the component name (e.g. `.box-body`)
  • modifier classes: `is-something`, `has-something`; CSS selectors must include component class (e.g. `.box.is-something {}` instead of just `.is-something {}`)
  • utility classes: {attribute}-{value} (e.g. `weight-medium`, `.bg-primary-normal`; value normally based on token names)
  • in practice, every component gets its own file, and everything is nested within the component class (`.box { > .box-header { &.is-cute {} }}`); stylelint ensures that certain attributes must be set via variables or functions (e.g. no hex colors, only color tokens)
• maintenance cost and changing your mind later: all good, not sure what to say; SCSS is stable; in the end, you still write CSS with some niceties, so it would be trivial to refactor; the class conventions above are enough to prevent component styles from bleeding
• technical side documented in the corresponding SCSS modules
• token/color overview generated from Style Dictionary JSON output, rendered in Phoenix Storybook page

Tailwind does a lot of things that have already been figured out elsewhere, true

AI is really good at these types of refactors because it can knock out the tedious and repetitive parts quite reliably. We just did a complete front end redesign (150k lines of Vue.js) using Opus 4.5. What would otherwise have taken us weeks took just three days, and that was mostly watching the AI work and then verifying the results.

SASS/SCSS variables

Usually I find a palette that I like. For no-nonsense apps I usually take the colors from Tabler.

My “public” variables are semantic, like: $control-color--contents--fg , $control-color--contents--bg etc., but they are defined using some “private” variables like $-blue, $-blue-lt, $-blue-dk etc.

I separate words with -- and prefix some classes with one-character prefixes like c for component and p for page. So c-control--button--xl for an extra-large button. My button component (in Web.Components.Control.button) has a size attr and the component sets the class like <a class={"c-control--button--#{@size}"}>. I could theoretically automatically generate the class names based on the component and function name, but I haven’t found the need to do that yet.

I never use utility classes. (Unless I’m using Tailwind or its predecessors, which I personally prefer not to do.)

I personally find it easier to edit SASS/SCSS than to edit a long list of utility class names.

I create a styleguide (which I think other people call a “storybook”?) that contains each component and its docs, as well as various examples. When I want to make a change to a component, I often view the changes in the styleguide so that I don’t forget to create examples of the various features of a component (kind of like test-driven development for components, except that there’s no automated feedback). The styleguide is just a single LiveView that has some navigation links to jump between components.

Here is a good resource https://moderncss.dev/

plain CSS and Sass

When I read this I always wonder…

• how do you set up your token system (colors, font sizes, spacing)?
• hand picked colors?
• do you call a light gray $light-gray, $color-light-gray, or $color-gray-400. And so on.
• CSS naming conventions for class names? BEM?
• what about one-off styles, for example .text-right, max-sm:hidden? Do you have a utilities.sass file?
• maintenance cost and changing your mind later
• how do you document all these choices?

It feels to me you would end up doing a lot of the same things that Tailwind has already figured out. Or am I missing something, do tell let me know of course

I agree about keeping HTML readable btw

The good news is that you don’t need to use Tailwind with Phoenix! Let’s not throw the baby out with the bathwater here.

My own comfort zone is with plain CSS and Sass. I find their logic simple and the separation of concerns keeps my HTML tags shining and readable.

The component-focused paradigm just clicks for me. This preference is actually why I haven’t picked up Phoenix Framework in years, as its Tailwind integration doesn’t align with my style.

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.

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