Anyone not using Tailwind in a Phoenix project?

[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 Overview · tuist/tuist · Tuist

@cschmatzler did and amazing job putting it together, and we are actively maintaining it and bringing new components regularly.

[theoldguy]

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.

[matt-savvy]

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.

[thomasbrus]

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

[Schultzer]

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

[eahanson]

@thomasbrus

• how do you set up your token system (colors, font sizes, spacing)?

SASS/SCSS variables

@thomasbrus

• hand picked colors?

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

@thomasbrus

• do you call a light gray $light-gray, $color-light-gray, or $color-gray-400. And so on.

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.

@thomasbrus

• CSS naming conventions for class names? BEM?

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.

@thomasbrus

• what about one-off styles, for example .text-right, max-sm:hidden? Do you have a utilities.sass file?

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

@thomasbrus

• maintenance cost and changing your mind later

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

@thomasbrus

• how do you document all these choices?

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.

[egeersoz]

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.

[woylie]

• 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

[theoldguy]

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.