You shouldn't write CSS anymore

If you are writing too much CSS, the design system is wrong, or you are doing something wrong, or both.

Any time you write a new rule to your CSS class or anything else, you add more noise to your code, more entropy. The next time you debug something on that code, you will need to deal with that entropy added.

Think of a team with too many developers, each developer writing your custom CSS; what could be the final result? I don't know, but the only thing I know is that the next time that someone debugs it will spend too much time on useless things trying to understand what everything does inside it.

CSS is a powerful tool for styling things in web development. You can do many things just with simple rules. In recent years, features like CSS variables, CSS at-rules like: @import and @layer, and other things have improved the edges of what you can do with this DSL.

But, as Uncle Ben said:

With great power comes great responsibility.

For a side, a thing that allows you to do the impossible inside a browser: turn simple boxes into beautiful ways to represent the limits of human creativity, it's a powerful tool. On another side, you still have a powerful tool. You need to limit what things you will do and how you will do them.

Things like BEM or OOCSS to create methodologies and patterns about how naming things, frameworks like Bootstrap or TailwindCSS, all of these things are solutions to limit what you can do based on some standards.

CSS as a piece of a puzzle

Think about your site as an enormous puzzle. Every piece is there to compound a final result: a beautiful view of your business. Everyone should talk about the same thing and follow the same patterns.

Typography elements should follow the same aspect: font size, font families, font-weight, and other related things. Color palettes should be the same on each part of your application, following a theme. You will handle spacing, like margin and padding, being the same too.

Following this philosophy, the next time you need to add any new feature to your application, you will spend too little time writing CSS because everything had done.

Furthermore, your styles should be converged into a single source of truth. If you have three places where you declare how your button works, each with its rules when you need to fix some bug in the color rule, how could you replicate it throughout your entire application? How much time will you spend trying to find what places are wrong after fixing the bug?

When you have a single source of truth, you have a win/win situation. You will spend much less time trying to find where things are; you already know it. You will ensure that everything follows what you expect while talking about your product brand.

Design systems to the rescue

A design system is just a way to structure and say what and how you can do something inside your application. It will fill some expectations like colors, typography, spacing, and other elements in general. Each of these parts, taken together, creates your application brand. And the consistency behind this matter to the final user. They will know how things work and will assimilate those things into your product.

Here, at Woovi, we follow this philosophy. Using Material UI, we ensure that every piece of our software is reusable. We focus on creating simple building blocks that can fit any place. We know that we won't need to write useless CSS.

Another helpful tool we are using here is Storybook. Every reusable component from our codebases comes from a package called UI. Inside that package, we had a .stories.tsx file that displays the respective component with its props, some examples, and other useful documentation.

If you are curious about how we manage our design system, turns it more consistent and would like to know how you could do it, we are hiring!

We are a startup that enables shoppers to pay as they like. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.