On Decision of Embracing Utility-First CSS

Utility-First CSS is trending. 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:

• CSS Utility Classes and “Separation of Concerns”
• In Defense of Utility-First CSS
• Let’s Define Exactly What Atomic CSS is
• CSS and Scalability
• Kiss My Classname

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:

• Is it worth the learning?
• Is it considered harmful in long term?
• Will it scale well in my team or company?
• Does it have same abstraction as web frameworks (React, Vue, Angular)?

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.

What you really care about

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:

• Naming classnames: Short, scoped, and collision-free.
• Output bundle sizes: The smaller the better, even better if modular
• Optimization chances: Removing unused styles, caching extracted CSS files.
• Developer experience: Fast development, easy refactoring, linting.
• Learning investment: fast to learn, works well between tech stacks.

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.

Be aware of learning something backwards, modern developers often stumbled into trending CSS-like, JavaScript-like, HTML-like and find themselves never actually learn vanilla HTML, CSS, JavaScript which considered harmful picking up new web technologies.

The ideas behind utility-first CSS

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.

The decision on utility-first CSS

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!

• I don’t like Angular because it uses HTML templates.
• I don’t like Vue because it uses template structures in .vue files.
• I don’t like Svelte because it uses template structures in .svelte files and ugly template APIs.
• I don’t like utility-first CSS because it promotes heavy uses of predefined classes instead of well-known CSS properties, and obviously ugly classnames in HTML.
• I like React and styled-components when 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.