The world of front-end development is vast as we all know and it consists of many ways to solve different problems, one of which is styling with CSS. In my years using React predominantly for building UI components, various approaches to styling have appealed to me and in this article, I would like to make a case for two of my favorites. These two technologies solve the issue of styling components with CSS from two different points of view, my aim here is to present you with adequate information to make a sound decision as you pick your poison.
The Case For Tailwind CSS
Tailwind is a CSS framework that simplifies styling your components into declaring some already-prepared class names. These class names contain trusty, well-tested style declarations that translate well into any component you are building. You can get a breakdown of these class names in their documentation (which is excellent by the way!) here.
Here is a simple code-snippet to explain how this works:
<p class="text-lg font-medium">
“Tailwind CSS is the only framework that I've seen scale
on large teams. It’s easy to customize, adapts to any design,
and the build size is tiny.”
</p>
In the snippet above, the class names "text-lg" and "font-medium" are specifically provided by the CSS framework under the hood so you do not need to write out your own style declarations all you need do is state a class name they have already provided! For example, "text-lg" translates under the hood to:
font-size: 1.125rem; /* 18px */
line-height: 1.75rem; /* 28px */
As you can see, this approach to writing CSS simplifies things a lot in the following ways:
- It limits the amount of CSS files you need to make and removes the need for writing lengthy style declarations.
- You can see both your components and the styles without the need to go back and forth between files.
- This is much quicker to write and you can churn out components in record time once you know the docs.
If you need a project done quickly, especially if said project is concise, Tailwind would probably be my recommendation. It is lightweight, easy to use, and set up. The major drawback would be readability especially if it contains a lot of class names; you could run into some issues debugging especially if your knowledge of core CSS isn't at a great level.
The Case for Styled Components
If you have ever built large projects with lots of moving parts and CSS, I'm sure you can't stress enough the importance of separating concerns to avoid style clashes. As codebases get larger, debugging gets more difficult. In such a scenario, you'd need a CSS solution that allows you to get meticulous about keeping certain style declarations fixed only to the scope of a particular component and hidden from the global context of your styling.
This is where Styled Components comes in. It is a CSS-in-JS solution to styling that enables you to write CSS right inside your JS component.
const Button = styled.a`
background: transparent;
border-radius: 3px;
border: 1px solid var(--accent-color);
color: var(--accent-color);
display: inline-block;
margin: 0.5rem 1rem;
padding: 0.5rem 0;
transition: all 200ms ease-in-out;
width: 11rem;
&:hover {
filter: brightness(0.85);
}
In the above code block, we see a component "Button" being cast as an anchor tag from the Styled Components library. This special anchor tag and its underlying style declarations are what gets rendered wherever the </Button>
component is declared. However, what we don't see happening under the hood is that this component also has a unique class name assigned to it to enhance its specificity; in a situation where we create this exact component elsewhere, that new copy that is created will have its own unique class name created by Styled Components thus making every component we create unique. It is particularly difficult to have clashes using this approach.
The drawbacks to this method include:
- It could be slow and tedious to write.
- There is plenty of boilerplate code involved, making your project more bulky than necessary
- It is not as performant as Tailwind
In conclusion, there is no one-size-fits-all solution to writing CSS, there isn't a silver bullet either. These are my go-to approaches to solving most styling needs across all the projects I've worked on. I hope I've provided enough information for you to make a choice you like.
Cheers!
(PS: Stick around if you want to hear about why I love React and the HNG internship I'm currently enrolled in :) )
PS
I've been writing React for about 2 years now and it is undoubtedly my favorite front-end library. A lot of factors come into place to make this so; there is a large, wholesome community of developers ready to help on forums and social media; the documentation is amazing and helps you understand it quickly and easily; last, but not least, it is the choice front-end technology at HNG. This makes things easier for me as it is right within my wheelhouse and I can get straight into building things with great engineers.
HNG Internships is an awesome initiative that brings thousands of developers together to work on challenges and build software together, making for a fast-paced, fun, vibrant, and unique learning experience. I have been a part of it for a couple of years and gleaned a lot of knowledge and also added some great projects to my portfolio. I hope to become a finalist this year for the first time, hopefully, I can hang on this time as the pressure gets "werser" (lol). If you would like to know more about the amazing work done at HNG internships, you can do so here. If you need to hire freelance talents for any of your projects, HNG also has you covered and you can get more information here
Thanks so much for reading!
Top comments (0)