Anyone not using Tailwind in a Phoenix project?

Phoenix Forum Chat / Discussions
,
81

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.

4 Likes
82

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.

5 Likes
83

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.

3 Likes
84

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 :slight_smile:

I agree about keeping HTML readable btw :grinning_face_with_smiling_eyes:

85

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

86

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.

1 Like
87

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.

88
  • 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 :smiley:

5 Likes