Lately, I've seen Tailwind CSS appearing in job ads for high-level front-end developers. They're needed for big, ongoing business projects that involve teamwork. I also used Tailwind CSS in a contract job, but I didn't enjoy it.
I'm not against any CSS framework. I like seeing new technologies and tools. But I've also felt the problems that come with picking the wrong tools. Some of them cause more problems than they solve and waste time and money.
Having worked in software development for 25 years, I want to explain why Tailwind CSS isn't a good choice for these types of projects. I hope this can help companies make better tech decisions.
HTML Bloating (Verbosity and Readability)
One of the main concerns with Tailwind CSS in large projects is the verbosity it can introduce into your HTML code. As you add more utility classes to manage your styling directly within your HTML, your markup can become increasingly cluttered, reducing readability and maintainability. This goes against the "Code Quality" paradigm, which emphasizes the importance of readability and understandability in code. It's crucial for a codebase to be self-explanatory and easily comprehensible to not only maintain productivity but also to ensure that new team members can quickly familiarize themselves with the code. Additionally, the "Separation of Concerns" principle encourages maintaining a clear distinction between the structure of a page (HTML) and its presentation (CSS). By using utility classes extensively within HTML, Tailwind CSS tends to blur this line, potentially violating the SoC principle.
Memorization Over Understanding (Learning Curve)
Tailwind CSS introduces its own set of utility classes and conventions, which could initially slow down development as team members need to familiarize themselves with these new terms. This learning curve is especially pronounced in Tailwind due to its heavy reliance on utility classes, essentially requiring developers to memorize a large number of class names to use the framework effectively. Memorization goes against the principles of good software development, as it increases cognitive load and can lead to mistakes and decreased productivity. Instead, best practices suggest code and APIs should be intuitive and self-explanatory, aligning with the "Convention over Configuration" paradigm. This principle suggests that software systems should work out of the box without requiring users to make lots of decisions and learn many new conventions.
Limited Customizability
This point aligns wit the "Flexibility" principle. SASS is inherently more flexible than Tailwind CSS as it supports more complex logic, such as custom functions and mixins. Flexibility allows for code to be easily adaptable and extendable to accommodate changing requirements in large, continuously evolving projects.
Handling Complex Logic
Tailwind CSS, being utility-first, can struggle with complex styling logic. Applying conditional class names or dynamically adjusting styles based on application state can lead to verbose and cluttered markup. This makes the code harder to read and maintain, especially for larger projects with intricate, dynamic styles.
Refactoring Difficulty
The DRY (Don't Repeat Yourself) principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system". With utility classes spread across many files, a change can potentially require modifications in numerous places, violating the DRY principle and making the refactoring process harder.
Recommended by LinkedIn
Increased Bundle Size
Tailwind CSS operates by generating a large number of utility classes, which can lead to increased CSS bundle size. While Tailwind provides a purging mechanism to remove unused classes and reduce the final CSS file size, this needs to be set up and configured correctly. If not, you might end up with a significantly larger CSS bundle than necessary.
For instance, consider a hypothetical case where Tailwind is not correctly purged and results in a final CSS file of 500KB. If you were using SASS and writing only the styles you needed, your final CSS file might only be 100KB.
Inconsistent Design and Difficult Updates
Tailwind CSS's utility-first approach can lead to design inconsistencies if not used carefully. Team members might apply different margins or paddings (like m-4 or m-3) based on their individual preferences, breaking the design's uniformity over time. Furthermore, updating a recurring style, such as a specific margin or padding, can become a daunting task. Instead of adjusting it in one place (as you would in a traditional CSS or SASS file), you'd need to go through all the HTML files and change the utility classes individually. This can be time-consuming and error-prone, particularly in large projects with numerous HTML files.
Hiring Process and Industry Standards
While Tailwind CSS has grown in popularity, traditional CSS and pre-processors like SASS/SCSS remain deeply entrenched in the industry and are often considered fundamental skills for front-end developers. Therefore, introducing Tailwind CSS into your project could potentially narrow your hiring pool, as you might prefer candidates who are familiar with Tailwind. Additionally, new hires who haven't used Tailwind before would face a steeper learning curve, potentially slowing their onboarding process. Conversely, sticking to traditional CSS or SASS/SCSS aligns more closely with industry standards, which could simplify hiring and onboarding.
Conclusion
In conclusion, while Tailwind CSS can be a potent tool for rapidly prototyping small projects or components, it shows several potential downsides when used in large, continuously developing, and growing projects. From HTML verbosity and difficulty in handling complex logic to potential hurdles in the hiring process, Tailwind CSS might introduce challenges that could impact the maintainability, scalability, and long-term evolution of a project.
Given these potential pitfalls, it's crucial to choose tools that best suit your project's scale and complexity, as well as the skill set of your development team. In the context of large projects that require a robust and maintainable CSS architecture, more traditional approaches such as SASS/SCSS, along with well-established methodologies like BEM, may provide more value.
These tools and methodologies offer the right balance of flexibility, maintainability, and scalability, making them suitable for projects of any size. SASS/SCSS offers advanced features such as variables, mixins, and nested rules that make your CSS easier to maintain and extend. BEM, on the other hand, provides a naming convention that can greatly improve project structure and team collaboration.
Remember, the goal is to build projects that not only look good and work well, but that are also maintainable, scalable, and efficient over time. So, choose your tools wisely.
