Thoughts about the current way of styling stuff in the boilerplate

[mconiglio]

We have discussed this with some members of the team, and came to the conclusion that not everyone is satisfied with the current approach of styling things.

Keep in mind that this issue is not necessarily focused on finding a new solution for this, but on discussing whether we want to continue using it or not.

If we want to continue with the current approach, then great! (some people really like it actually) If not, well... yes, let's discuss possible new solutions

The current tools we are using are:

• Tailwind CSS
• CSS modules
• SASS

I think @mollerjorge mentioned that it's not a good thing to have to use classes this way md\:py-2, just because the : have to be escaped. There is a solution for that, that can be found here. So we could change : to be something like - or some other character.

Despite that, my personal opinion is that css modules and utility first css libraries don't work great together. We are using the @extend keyword to compose utility classes, and a lot of those classes have only one property inside them (like bg-white -> background-color: white). So we are not taking most of the advantages that libraries like tailwind have to offer.

Personally I really like the utility first approach, and tailwind seems to be one of the best options for that. And when I saw his creator talk about the apply/extend usage, his recommendation for it was related to the times when you are not using a component focused library, to avoid repetition and increase reusability. But, when using something like react, the reusability should be focused on the components, not on css classes (which we aren't doing either because we have separate css files for each component).

So, to sum up, I think we should go with one or the two:

First option:

• Tailwind CSS
• Files with Custom utility classes following the tailwind naming conventions example here
• Some library like classnames or clsx

Second option:

• CSS modules
• (Maybe) SASS
• (Maybe) some ui library

[eleleiva]

One thing that I want to point out, is that one of the key features I had in mind when I suggested Tailwind was the ability to had all the styles centered in the config file and how it will enable the design team to take a better view of our design system. If I recall correctly the team working on tunel web is making use of this to some extent. This feature could be replaced somehow by making a wider and least flexible use of variables. Another advantage on which I based my recommendation was the utility classes, as how I build the interfaces is basically by changing the CSS on the browser, so changing the classes is easier and more visible for me than just changing the styles on the inspector.

[donatoaguirre24]

I barely worked with the current styling stack, therefore, I do not have a valuable opinion about it. That said, during the code review, I found it a bit tricky, unreadable, and error-prone. Disclaimer: the problem may be my lack of experience using it 😅

Just to add my two cents, I'm more into reusability at the component level. I find it very comfortable to build a component library per project.

Spicy opinion, but I rather like CSS-in-JS over Tailwind + SASS + CSS modules. In my opinion, styled-components + CSS variables could be a flexible and easy way to build reusable and self encapsulated components.

This article shows some of the advantages of using CSS variables. (@mollerjorge I think you'll like it).

[eleleiva]

Although I agree with CSS variables, I don't see the point of using CSS-in-JS honestly. Which advantages do you see in it?

[donatoaguirre24]

Although I agree with CSS variables, I don't see the point of using CSS-in-JS honestly. Which advantages do you see in it?

Honestly, I find the official motivations very attractive. Mainly these points:

• Simple dynamic styling: adapting the styling of a component based on its props or a global theme is simple and intuitive without having to manually manage dozens of classes.

• Automatic critical CSS: styled-components keeps track of which components are rendered on a page and injects their styles and nothing else, fully automatically. Combined with code splitting, this means your users load the least amount of code necessary.

• No class name bugs: styled-components generates unique class names for your styles. You never have to worry about duplication, overlap or misspellings. So. we do not need CSS modules anymore.

[eleleiva]

Although I agree with CSS variables, I don't see the point of using CSS-in-JS honestly. Which advantages do you see in it?

Honestly, I find the official motivations very attractive. Mainly these points:

• Simple dynamic styling: adapting the styling of a component based on its props or a global theme is simple and intuitive without having to manually manage dozens of classes.
• Automatic critical CSS: styled-components keeps track of which components are rendered on a page and injects their styles and nothing else, fully automatically. Combined with code splitting, this means your users load the least amount of code necessary.
• No class name bugs: styled-components generates unique class names for your styles. You never have to worry about duplication, overlap or misspellings. So. we do not need CSS modules anymore.

• The first point is something to take with a pinch of salt. manage dozens of classes is an edge case.
• The second is a give or take, what I have to agree on is the fact that currently, Tailwind is loading all of its classes and being a heavy request by itself, it needs improvement.
• You can use the same point the other way around You don't need styled-components as CSS modules generate a non-conflict class name.

The fact that I was unaware of about styled-components is that it is class-based and not attribute-based, on that hand, it took the most pressing concern I had about it. It might be just me but I rather have the CSS away from the logic. All in all, on what you mention, I see the problem as being Tailwind, but not modules, and CSS-in-JS is an alternative to modules, right?

[mconiglio]

I've worked with styled components only once, but I didn't really like it. Some cons I see on it:

• Adding extra level in the hierarchy of the elements
• The backtick syntax feels odd for styles
• The approach doesn't feel natural

(Last two are just my opinion 😬 )

[donatoaguirre24]

@lucaleivaloop yep, my concern is mostly about Tailwind. I think styled-components isn't just a replacement for CSS modules, also adds extra features like accessing props within styles (useful to avoid applying classNames conditionally). I feel that styled-components could replace Tailwind + SASS + CSS modules, ending with a simpler solution.

@mconiglio I agree with the last two, but still think it pays off. I feel SASS + Tailwind way less readable than template literals, I think is a matter of taste. I didn't catch the first one, styled-components aren't HOCs they will inject CSS directly to the wrapped component just like plain CSS.

[mollerjorge]

I can give you my opinion on the usage of tailwind so far, in both the boilerplate and the clockwork redo. The disadvantages I have found:

1. It has decreased the velocity of writing styles substantially.
2. Based on how tailwind is currently configured in the boilerplate I couldn't find a way to use tailwind directives or theme function (by theme function, I mean a sass function that tailwind ships with that you can use to access variables, e.g. border: .1rem solid theme('colors.blue.500'); I assume this is because we are just importing the tailwind CSS file which only gives us access to utility classes, not directives or functions.
3. Don't like the fact that you have to eventually mix CSS with utility classes, it feels odd.

My personal preference when it comes to styling with react is styled-components with styled-theme or CSS variables.

[mconiglio]

If this is decreasing the velocity on writing styles I'd say we have to change it ASAP, especially on projects where this is happening, and if it's something possible on each case. Regarding styled-components... I'm not fan of the idea of switching to it, but if we see that it's the best (or the one that has less disadvantages) we could go for it.

We should do some research though, because, once we switch to it, it won't be easy to switch to another, like we are already seeing with the current approach

[emmaielle]

I didn't want to give my opinion because that's what it is - very biased by what I like and devoid of objective reasons. But i'll put my 2 cents here now that it seems you've reached more or less an agreement. I don't like tailwind; I think it slows things down but I've learnt to accept it, so i'm okay if it stays. At the same time, I've worked with styled components and my first reaction was that the mixed JS/CSS is off-putting. But it's highly readable and it doesn't take much time to add styles. The main problem I have with it is repetition, even if we have a theme. In any case, I mainly agree with having a solution that conceives both styled-components and a global theme, like @mollerjorge suggests.

[eleleiva]

Ok, lets recap (maybe @mconiglio can delete this comment and add something based on it on the first comment).

• CSS modules (with optional Sass) vs CSS-in-JS vs Tailwind (or some other utility classes library).
• We definitely are going to separate CSS modules from Tailwind.
• We need to define a way to create themes if we depart from Tailwind.

People are leaning on CSS-in-JS but after presenting all the opinions and facts this first point might go into a poll.

[Rminetti]

Hi team, sorry Im late to the discussion. Regardless of the fact that I've been using Tailwind on the project I still think that my opinion is not the strongest one as I'm really new to most of the technologies that we are talking about. Even so, I personally like Tailwind so far. I agree that it repeats it self a bit. I think it is a condensed css in a way since it wraps css statements on custom classes that you then mix together to get the desired styles. One huge advantage that I see to it is the way that you can customize a theme. I've used this feature to some extent (mainly to define the color palette of the TunelWeb app) and it is really helpful given that generates all those utility classes with the colors and name format that you specify. One thing to point out is that is a bit trickier to conditionally define styles using JS variables as to some CSS-in-JS options.

All in all, that is how I view the current approach, I like it, but if we decide something new is better Im also up for it!

[mconiglio]

Closing this as we decided to go for a css-in-js solution