Discussion about CSS architecture's decisions

[ItsCrisDiaz]

Keeping in mind the fact that issues #4 #34 and #45 are closely related because is convenient for all squads to keep an equal CSS architecture, I have decided to open this discussion to make a team decision about CSS architecture topics:

• Define the CSS paradigm we want to apply to this project (Functional, Semantic, a mix of both)
• Define the CSS methodology we should use for this project (Atomic Design, OOCSS, SMACSS, BEM, CUBE CSS)
• Choose what kind of tool we are going to use to write CSS (Preprocessors like Sass, LESS, Stylus, use of PostCSS or use of CSS in JS tools)

After this discussion about tools and chosen methodology, we should start discussing our first steps in the creation of styles like:

• Preprocessor installation.
• Create the global variables for CSS.
• Create global CSS styles ( buttons, inputs, h1,...)

@701i

Please let us know your opinions about this matter! 😃

[basultobdKs]

Hey guys, did you consider tailwind? It has something useful and ready to be customized.

Its documentation is terrific and will allow use to work with the same guidelines/class names, the only thing we should do is define the basic styles for the classes and we are ready to go.

Custom styles: https://tailwindcss.com/docs/adding-custom-styles
Next integration: https://tailwindcss.com/docs/guides/nextjs

[ItsCrisDiaz]

I'll be honest with you, I'm a bit biased against the use of CSS frameworks because for me they help to solve design problems, not CSS problems.

My main problem with Tailwind is the overuse of utility classes, it can make HTML hard to read and debug, and if it saves some time in the short term making it faster to code, it'd backfire in the long end with the maintenance.

With that said, I think Tailwind does have a place in this project, as long as we don't use it as the only source of truth.

Just to give an example, have you heard about CUBE CSS? I like this CSS methodology a lot because it allows you to have a semantic (use of blocks of rules to create components) and functional (use of CSS utility classes) at the same time creating a scalable style code!

If you notice, the Utility section is basically Tailwind's approach and using it for the utility's section seems a good idea to speed up the work. So my suggest to it Using Tailwind only to define necessary utility classes for this project when needed instead of using to style everything in our site.

[basultobdKs]

Please be honest, this is not a judgment, this is the reason of this discussions, this Platzi Master! 🚀 💚

My mantra with the CSS is: less css use you use better. For me the best way to do CSS in not do CSS at all.

When you do frontend you usually choose one of two options:

1. You couple HTML with the CSS
2. You couple CSS with yout HTML structure.

Let's check them in separated replies:

[basultobdKs]

HTML coupled with CSS

This is the place where tools like Tailwind are, the idea as you mentioned is having utility classes, this classes encapsulates styles and manage a language more closely to the design, because usually the design team creates Design systems that support products.

Cool 👍🏽

What is the advantage to have this approach? We think in styles and not in the structure of the elements, we dont think on containers, modifiers (per se) or elements.

Not cool 👎🏽

Disadvantages? Sure, our markup will have a lot of classes, is this a problem, from my POV, depends on how you are using it. You are working with components, your are encapsulating, soooo the components that will be biggest ones will be the views.

Alternatives

Hey but I need to reuse a lot of utility classes, ok what if you create an object like this one:

// Button.jsx

const buttonClasses = Object.Freeze({
  superButtonReusableClass: 'text-slate-50 font-thin',
})

// ...

return <button className={buttonClasses.superButtonReusableClass} />;

If tomorrow you need to change the style in some component you only need to change the class not the markup (HTML).

For big projects I think this is the better way to manage CSS, this is not only from TW, this is something that you could do with libraries like material UI, of course, this is an implementation of a Design system. I implemented strategies using material UI + Saas using these ideas.

[basultobdKs]

CSS coupled with HTML

Here is where methodologies like BEM are, what is BEM telling us? You are going to define some elements that have a context using blocks, elements and modifiers. I see the modifiers as subset of utility classes.

Cool 👍🏽

The classname that we are going to use are going to have a context based on what it represents visually or as part of the composition of the component. Nice! Our classnames will be very specific and it will tells us what need to be modified.

Our css will look like this

.navbar {}
.navbar__link {}
.navbar__link--visited {}
.navbar__link--visited:hover {}

Nice, every approach that uses the context as base will have a similar structure, this allow use to defined classes based on the markup and we could use tools like sass to boost the syntax.

Not cool 👎🏽

Well, I'm not fan of creating names for the classes, I was a huge believer of this in the past, but as much this became something that was taking me a lot of time I chose not continue with the approach.

Also, as the CSS is coupled and following the HTML context, every change that you do in your markup that modify the component composition and change the name will require a change in the CSS too. Why the changes in the markup need to be affected with styles? They shouldn't depend on the styles.

Alternatives

If the guidelines on the naming are clear and we want to prioritize the components composition context, let's go with this. I was reading about CUBE CSS and it has ideas from both approaches, so I think we can go with it if you agree.

Using sass could help us a lot with the css modules importing the styles directly in the component that you are working.

[basultobdKs]

Happy to know your opinion masters, just consider if the solution could scale and it will be easy to learn for the rest of the squads, your call 😆

[taberoajorge]

I would like that we work with styled-components

[basultobdKs]

Ok ok, in that case I have some questions:

1. Which is the main reason to do it? It's related with the components creation?
2. Which will be the guidelines that every team should follow with the strategy?
3. Adapting SC strategy will be easier to use something that is ready to use?
4. Are we considering that we will need to write CSS? How are we going to control the availability of some styles on some browsers?

These questions not only apply for SC, but how many time we can save teaching a strategy that involve write CSS? Could we save some time only redirecting people to the documentation on how to use the class in TW?

[ItsCrisDiaz]

Could you elaborate a bit about why do you think Styled Components would be the best approach, please?

I personally don't like CSS in JS that much just because I like to have styles and components layout/functionality in different files (just for organization, because we can use global styles in an easier way and tbh, just a personal preference) but I'd like to see your opinion about that matter 😄

[ItsCrisDiaz]

I'll quote something from a message @gh0stl1m said in Slack that I think it's mind

What you need to be in mind for this is that you are going to create libraries that later you will import inside the nextJS app and make use of the components that you export. You can take a look at this monorepo example

Additionally, we need to keep in mind we'll have to use Storybook for our component library so any toolkit we decide to use has to be compatible with it.

@basultobdKs mentioned very interesting points about the use of Tailwind, showing different advantages of using Functional CSS (Using small, immutable, and explicitly named utility classes to construct components) and a Semantical CSS (a more "traditional" component-based CSS approach where we create blocks of rules to apply to components) mentioning some advantages and disadvantages of both of them.

I think both CSS approaches are great, but they'll work better if we use them in tandem to create reusable CSS. My proposal is we should use CSS to have utility classes for styles we see often (like the use of colors, spaces, margins, types of display, etc) and after that, use a semantic CSS approach to tackle components. With those utility classes, the additions we need to make to those components should be simpler. A good CSS methodology that mixes both approaches is CUBE CSS and if we decide use both CSS paradigms, we should keep it in mind.

@taberoajorge mentioned the use of Style Components, I don't oppose the idea, but I'd like to see some discussion about how it'll help us for this project. In this point, I'm also including all CSS-in-JS options we have.

Additionally, I want to bring some discussion about those topics:

• Use of pre-processors: Should we use them? Which should be the one we choose? Let's remember this has to be compatible with Storybook.
• Use of PostCSS: What value could bring PostCSS to our project?
• Should we use CSS modules?: If we decide not to use pre-processors, we should still find a way to keep our CSS easy to maintain, and CSS modules could help us with that.

We'd like to hear your opinions about those topics!

[glrodasz]

I know about CUBE CSS, and I don't recommend it since it's just a hype-tech and there is no planned roadmap. I opened this issue last year and I haven't received any answer, even when I talked with the author personally via Twitter.

CSS-in-JS is quite inevitable when you work with React.

All of you have really good points, and I will share a bullet-proof formula for this kind of project and architecture:

• Use plain CSS with Custom Properties if you need variables
• Use the built-in CSS Modules that come with Next.js
• If you need a SASS feature, create a specific SASS file, but don't force yourself to use SASS in everything, Next.js supports a SASS loader out of the box.
• Focus on creating insolate components and use any hierarchical approach like Atomic Design, in that sense you don't need more, no BEM, no SMACSS, anything else. (Those were made for solving different problems that we aren't having today, I wrote more about it here)
• Use Storybook but the host project (the consumer) will be responsible to transpile the components.

If you need inspiration, you can watch this workshop https://www.notion.so/platziteam/Mature-Component-Library-179c1198d5884adfb9b89d0da9bfe0c7

and take a look to these projects as well:

• https://github.com/glrodasz/cero-components
• https://github.com/glrodasz/cero-web

[glrodasz]

I almost forget: Tailwind CSS will definitely work, but let's be honest... Tailwind will disappear as other tools/frameworks in history. What you REALLY want is to work with long-term solutions and methodologies.