Tailwind has gone viral in the frontend world over the last couple of years reaching almost 100% awareness in an already crowded space. It has come a long way from the original article by it’s creator in 2017.
Tailwind is based upon “functional CSS” as opposed to “semantic CSS”. To many developers this meant a paradigm shift away from the semantic style they were used too in the more popular frameowrks (at the time) like Bootstrap.
Tailwind ruptures away from ideas such as Zengarden. CSS is not seen as something completely decoupled from HTML. On a higher level it favours Locality of Behaviour over Separation of Concerns. A broader current trend in the software industry.
To some this is going too far. They have strived their whole career learning BEM, SASS or other methodologies and tools that are not needed anymore in Tailwind. They tried to have perfectly decoupled and structured CSS without ever really achieving or even needing it.
I have never ever seen a site seriously change it’s look and feel only by rerewriting the CSS and leaving the HTML alone. But that is maybe just my subjective experience.
From an individual contributor’s point of view I understand them. Use the tools you love and learned over your career. Go ahead and make nice compact CSS classes that can be reused and don’t pollute your HTML. Don’t just change to change. Don’t just follow the hype.
But what I often miss in hate/love discussions about Tailwind is the team perspective. Not that suprising if you factor in our industry is growing at a rapid pace and thus a huge percentage of it (and online discussions) is still relatively inexperienced in team dynamics.
Sure as a sole dev you might perfectly grasp what your “panel” class is and does. You might even have the working memory to remember it 1 year later when revisiting your code. You might have your CSS structure and naming completely figured out. You might have set up your IDE to autocomplete, open the CSS details in a different pane with one keystroke, etc. You are breezing through your one-class HTML elements and loving life.
But do you have all this on the team level? Are you sure you want to be pedantically explaining people to use your “panel” class when you see a “card” class appear in a PR which does the same thing? Are you sure you want to be walking every new onboard through all your CSS conventions, folders and files? Do you want to be missing out on tooling and documentation (or spending company dime to create your own)? Does having back and forths about how to name a new CSS class excite you? From my experience all long-lived codebases managed by many rotating people over multiple years using semantic CSS eventually turn into trash cans.
Tailwind is a well understood, well documented and tool-rich framework which still gives devs and designers all the freedom they need. It is not a big suprise it has been embraced and promoted by the Phoenix community, Laravel community and the Rails community.
If you don’t have the budget or customer need for a more custom design, frameworks such as Bootstrap and MaterialUI might still get you up and running quicker. The cost is looking like a Bootstrap/Google site. There are also component frameworks which build on top of Tailwind such as TailwindUI or DaisyUI. But it’s hard to argue they are as feature rich and mature. Even though given the Tailwind hype that might change over the coming years.
If you have a quasi unlimited budget to develop, coordinate and train teams then your own CSS framework might give you certain advantages. Looking at e.g. stylex.
Your website provides customer value by allowing your clients to style it (heavily) with their own CSS on top of your HTML. Then Zengarden philosophy and thus semantic CSS might actually have a realworld use case. Maintaining a Zengarden is expensive so be sure you are willing to pay the cost. But why not expose an API and let customers build their own frontend if the customisations are so heavy? For simple tweaks just extend Tailwind with some classes linked to CSS variables you save and expose per client on page load.
If your site doesn’t use any system of HTML/frontend components (a aka no React, no Vue, no ViewComponents, no partials) and just duplicates HTML left and right copying over and syncing all Tailwind classes might get tiring real quick. Then some semantic CSS components might be usefull. But why not introduce HTML components instead?
If you are working on a project by yourself and you like writing CSS. Do whatever you like the most. If it’s a hobby project intended to learn frontend skills I would even recommend using vanilla CSS to master the basics first.
You subscribe to No Build. Though there is still a lot of value in just sticking to and defining Tailwind classes yourself in a CSS file without using the library avoiding the build step.