The coming week will be about shedding some light on Tailwind CSS1. It’s a very controversial topic, and I believe it’s even more polarizing than Microservices vs. Monoliths or ORM vs. SQL.
Why is that that that tech people tend to love or hate it? Why aren’t there some shades of gray in between?
This is one of the questions I will tackle during the week. Another question will be, of course, what Tailwind is and is not. To answer these questions accurately, you must have used Tailwind CSS for a while and possess a solid grounding in Cascading Style Sheets (CSS) 2. It’s not simply done by trying to understand a utility-first CSS framework. 3
Do I use Tailwind CSS?
Several years ago, we adopted Tailwind for a React/NextJS project. It wasn’t me who made me step forward to look at it. In fact, I was really annoyed when I saw this cluster of classes attached to the class attributes. In short, as a Senior Engineer and CTO, I was against it.
But I was already aware of my shortcomings when it came to being open-minded the decades before, so I agreed to adopt it as a successor of Styled Components (Emotion).
Today, we have a 50-50 CSS/Tailwind usage code base, but we never mix approaches.
At that time, I wasn’t aware of the following aspects:
What Tailwind is about
How Tailwind really works.
How Tailwind changes the way of structuring things.
The Shift in Design Mentality
Impact on Debugging and Maintenance
Enhanced Team Collaboration and Onboarding
Improved Consistency and Scalability
🍪 Before I get into this Tailwind-Week of snackableCTOs content, I want to write down my current context and learnings about Tailwind and the approach behind it, which is what really fascinates me as a Media & Frontend Engineer who has gone through a lot of changes in the last 25 years.
Simplicity in Design – Upper Ceiling Of Complexity
Tailwind's utility-first approach leads to more secure and resilient outcomes. It reduces complexity, which helps humans (the people who create software) to transparently understand what is happening, even after months. The upper ceiling of complexity in HTML/CSS isn’t that high, and if it is, your requirements might be set high. Aiming for a solid standard, which is
A: Easy to understand for low to mid-level Engineer
B: Easy to maintain, valuable, and reasonable.
🍪 When implementing something like Tailwind, you must learn to adapt. Tailwind, for me, is a form of framework. For example, in combination with React, it influences how you work. To prevent extremely long class names, you need to aggregate utility classes to prevent extremely long class attributes.
🍪 Another important aspect is that CSS and Design are often overdone. The upper ceiling of how to style a single element should be limited, as we limit a lot in software development. Component-driven approaches help us reduce what we need to create applications that generate value. If, on the other hand, your goal is to create super-fancy CSS masterworks, you should stay with the pure CSS approach.
Image from: https://pdx.su/blog/2023-07-26-tailwind-and-the-death-of-craftsmanship/
Revised DRY Perspective
While DRY is a concern, Tailwind shows that it applies to CSS in a practical, component-focused way. When your context and scope are components, DRY no longer applies. If you see the entire app as context, then yes, DRY is a concern. It’s important here to understand that the traditional approach with CSS isn’t what Tailwind is trying to substitute.
Modern Ideas on Old Platforms
Tailwind introduces modern design thinking into older CSS specifications, being intrusive yet beneficial. This is often the source of heated discussions.
Does Tailwind harm someone?
And if yes, who gets harmed and why?
Does Tailwind degrade the quality of Developers in Frontend?
I want to get these questions answered this week.
Aligning with Web Standards
We should not mismatch web specifications with project requirements and qualities 4. As software engineers, we must find a solid long-term solution that meets all requirements and qualities.
Web specifications are no requirements or qualities for our product to create. Those are made to define the Open Web Stack.
Resilience, Ability to onboard quickly, scalability, performance, code quality assurance, and ease of delivery are requirements and NFRs to consider. At first glance, Tailwind doesn’t harm those examples.
If you decide to implement Core Web Specifications as requirements, you add little to no value with high effort to implement and maintain. 👉 No one is asking for it.
Let’s find out more about this topic this week.
Component Lifecycle Management
Tailwind advocates a component-driven life cycle. You have a global configuration, but it’s not hard-wired to the actual implementation. This makes Tailwind a valid choice for pure component-driven approaches in Non-Web-Component scenarios like React.
I need to find out if it’s a good choice for Web Component (Custom Elements) in isolation. Please let me know about your experience.
Avoiding Replication Pitfalls
The issue of developers replicating traditional CSS architecture in Tailwind leads to lengthy utility chains. That’s the wrong approach. Tailwind works differently. We will compare this live on Wednesdays, Our Tech Journey Stream.
Experience Beyond Documentation
Emphasizes that understanding Tailwind’s benefits requires hands-on experience, not just theoretical knowledge. It’s key to understand that Tailwind is not a default substitution for good CSS practices or SCSS; it’s specific tooling for specific scenarios. We need to understand first before we can make effective decisions.
Development and Maintenance
Tailwind has contributed to making developers more proficient and has shown to be effective for maintenance. We will discuss and practice this a lot in the coming week; looking forward to it.
Avoiding Over-Complexity
Suggests that Tailwind helps maintain an upper ceiling of complexity, preventing design failures due to over-complication.
👉 About Tailwind vs CSS in terms of complexity
Tailwind reduces Mental Distance & Physical Distance.
Tailwind follows the concept of locality. By this, it greatly improves the connascence of position and meaning. It’s a form of healthy cohesion in the context of component-driven development.
👉 We should ask ourselves why we want to decouple HTML and CSS into separate files (Distance) and why we should try to add another complexity layer into another file so our brain needs to process the files? For Web Standards? And who is really doing CSS file swapping anymore, especially in the component context? I never did with success :)
Especially in WebApps and component-driven contexts, closely related aspects like Markup and Styles should be questioned if we benefit from separating them. Component-driven means a scope of 1 to several files (Components) at most per “Molecule”; the less, the better.
I am not a fan of accepting things as given. “That's how we've always done it” doesn’t apply to the Software Engineering space. Solid engineering needs to go hand-in-hand with innovation.
👉 Feel free to discuss this topic with us this week. Are you thinking I am wrong? Please tell me why. I will read and think about it.
The Philosophy of Simplicity in System Design
"Simple systems lead to more secure and resilient outcomes." This principle holds particularly true in the realm of web and cloud development. Adopting approaches that ensure security and resilience is paramount in the evolving front-end development landscape.
🍪 Simplicity leads to a better, faster, and less expensive understanding of the current context we see in front of us.
Trying Tailwind: A Call to Action
For those yet to experience Tailwind, it's more than just a new tool; it's a new way of thinking about CSS. It minimizes mental overhead and encourages a more streamlined approach to styling. The complexity with Tailwind has an upper ceiling, preventing design failures due to overcomplication.
Conclusion - Senior Mastercrafts should rethink.
Yes, fellow Senior Frontend Engineers complain that you should learn CSS well instead of using just Tailwind. I did that as well. There is some truth to it; I will come to it in a second.
Why do newer developers, especially, prefer Tailwind, then? The reason is not because it’s trendy; Engineers should not fall into this low-level thinking. The answer is simply because it’s easier to understand and focuses on the subset of CSS that matters. Developers can focus without the need to learn.
🍪 When I was a young developer more than two decades ago, we had a lot of time to work ourselves into the game of HTML/CSS. Years. The amount of things to learn was clear. HTML/CSS was mainly still a document-driven approach. Wiki-like websites, some easy layouts, and overall acceptance criteria were quite low.
So is it okay to simply say: “As a Developer, you must have mastered your craft before you are allowed to create something?” – I disagree totally and fully.
Tailwind, React, ORMs, etc., are patterns of simplifying complexity to a good standard. Complexity was common and accepted back in the day. But its need has become contextual these days; it’s not per se anymore.
We need to learn CSS, JavaScript, and SQL to master our craft. But in reality, we need to learn it to the point and degree that we can apply it to meet the requirements and qualities.
Does this lead to a natural weakening of deep Open Web Stack Knowledge? Yes, it does. It is happening everywhere and in every craft. Much of what we have learned in the past isn’t necessary anymore for an average front-end developer. Is someone still asking for float-left-clear? Unnecessary to know about today.
Do we still use lead letters to print? Do you know the deep mastery necessary to create a newspaper with those? I know; I learned it. I even did it sometimes. And is it necessary to understand modern CSS typography? No. 99,99% of the people I know don’t know anything about the original craft of typography but call themselves CSS master crafts. That’s totally fine!
We need to accept that the world is moving forward. Is Tailwind the answer to current problems? It’s a widely adopted approach, but it’s not THE new way.
Tailwind is viable and working and will stay current for the application life cycle of applications that start in 2024.
I can only recommend staying open-minded and trying to understand what’s happening. Being a Mastercraft in Frontend doesn’t mean understanding what is to come. Mastercraft means we have understood in the past.
Now I will tell you my experience and point of view. Let me know yours here, on LinkedIn, and during our streams.
Let me see what I think next Sunday :)
Have a great day,
Adrian
https://tailwindcss.com/
https://en.wikipedia.org/wiki/CSS
https://tailwindcss.com/docs/utility-first