Utility-First CSS is trending in 2022. If you hate it, you will feel annoyed seeing people promoting it. If you love it, you’ll question why people hate it. If you’re still skeptical then there’s a high chance you’ve already read all following articles:
You can’t ignore it anymore when it’s gaining so much attention and potentially becomes something big that you and your team don’t want to miss. Same thing happens to Svelte. It’s moving in an unpopular direction, it pushes you to make decision at this point — ignore it, embrace it, or question your current direction:
If you still couldn’t pick a side, then I’m here to help you. This post focuses on the decision of embracing utility-first CSS in general and Tailwind in more specific.
All CSS technologies like CSS frameworks, CSS methodologies, or CSS-in-JS libraries try to fix problems of CSS at scale one way or another. Following are major deciding factors before picking a CSS solution:
Different years of experience and project sizes have different expectations on above factors like beginners care more about learning investment and big projects care more about optimization chances.
The main idea behind utility-first CSS movement is to style everything based on predefined utility classes — developed by yourself or frameworks.
People love it because it promotes rapid prototyping by reusing tons of useful ready-to-use CSS classes at a very strict manner. People hate it because it produces ugly HTML markup with long string of classes.
Tailwind comes prepacked with a lot of options and styles for users to choose from, and it packs all these variations to reduce the tendency to write your own CSS.
Majority of time you don’t do that much of customization as you expected, there is a chance that you’ll never create any custom CSS in small projects, that’s why Tailwind has been gaining so much momentum.
I have a background on mobile development where I always styled components programmatically. When I moved to web development, component-based CSS-in-JS seemed so obvious and future-proof. The transition was right and pleasant in the beginning.
I already experienced utmost dynamic component-based architecture when writing styles, layouts, and logics in one file using general-purpose programming languages. I resist all technologies go against my principles, I may try them, but not going to embrace any of them!
.sveltefiles and ugly template APIs.
styled-componentswhen it translates very well to mobile apps and desktop apps, I prefer reusable fully-functional components than reusable CSS or HTML alone.
You see the point here, it’s not about right or wrong decision. It’s all about define principles in your developer career and technologies will fall into the right bucket for you and only you.