Ew this is basically inline styles!
When I first ran across TailwindCSS, I admittedly had an instant guttural dislike. I've been designing and building websites since 1996 — when CSS was just a baby and html tables were the defacto way to lay out sites. …Yes to all you dev newbies, I'm that old. I've had to reboot my skills and best practices several times over the past 25 years.
I've honestly never much liked any CSS framework. I can see a Bootstrap site from a mile away. I know how CSS works, I've been using CSS for styling and layout since early CSS Zen Garden days. It's often easier for me just code the css myself rather than fight to override the styles the framework provides.
I've also long been a big proponent of semantic css and the separation of style and markup. That best practice has been engrained in my so long it's become nearly an ethical philosophy. So you can see why I had an instant dislike of Tailwind. It is the complete opposite of those ideals. It's basically a codified inline style system.
Questioning my own Best Practices
One thing I've learned however in several times I've had to reboot my web dev skills is that you need to keep an open mind. It pays to learn about the new shiny thing and sometimes you even need to throw out everything you thought you knew.
I give credit to my inner punk for giving me this perspective – question authority even, and especially, your own inner authority.
The best practice of semantic CSS and separating style from markup honestly served me well for a long time. I learned how to redesign the look of a site just using css. This paid off a lot over the years in situations where the CMS template engine that spit out the html was a pain to update. I've updated lots of old sites to polished mobile ready sites just by changing the CSS. Give me a good BEM structured html page and I can make it look however you want. Though I've also restyled a lot of sites with shit css naming.
CSS Styling Today's Web
Today's web is a different place. Everything is component in which css is usually scoped by default. BEM isn't necessary. Hell a lot of the time you can just ignore class names at all. Svelte and Vue have single file components mean that you can plop the style on the div. And the myriad of CSS-in-JS approaches in React attach the styles directly to the element.
Building a site or app with scoped using components is great! No longer do I have to worry about naming conflicts or the CSS cascade.
How I came around to TailwindCSS
When I first worked with React, I used CSS Modules for my styling. It was how I was used to working with a separate css file — CSS-in-JS felt wrong. Then I tried Svelte. Svelte's single file components are great and simple to work in. The CSS is just there right alongside the markup. I never realized how much context switching between the markup file and the css file slowed me down until then. After working with Svelte I began using CSS-in-JS in my React projects for the same reason. It reduced the context switching.
Still even though I had adapted there I didn't see the point of Tailwind. I mean I know CSS. Tailwind felt like just a syntax to learn. I read Adam Wathan's long involved post on CSS Utility Classes and "Separation of Concerns", which made me begin to rethink the issue.
To get it off my mind I decided it was time to question my own biases. I installed Tailwind Intellisense for VS Code and started up a test project with a starter that included Tailwind (actually it uses Windi, which is a Tailwind compiler). I then started making a basic site, forcing myself to use the utility classes for (most) all of the styling.
It took a while to get over the learning curve of the Tailwind syntax. Intellisense helped a lot with this but also the syntax is pretty intuitive once I got to using it. After a while, I discovered it was faster using Tailwind classes than writing the css out.
I realized two things…
- Using a utility css framework pretty much completely gets rid of the issue of context switching. No more looking at another document or even down to the style area of the page like with Svelte. I can see how the element is styled and make changes just on the element itself!
- Another great aspect is that it makes it easier to change from say Svelte to React or 11ty to Gatsby or whatever. Since the styling is embedded with the html I can just copy paste wherever I want. I just need to make sure that Tailwind is integrated and I'm good to go.
The first advantage is great but the second is what really won me over. I have a couple projects that I'm working on right now that I'm not settled on how I want to build it. But now with Tailwind I don't really care. I can design all the components just with plain html or a simple Svelte app. Then I can easily bring both the html and styling components to Gatsby or Next once I get going with building out the functionality.
My new CSS Best Practice
Tailwind is great as you can use as much or as little of it as you want. Tailwind's base css has everything normalized so nothing has any styling. I personally like start with a classless css file for at least some basic typography and form elements. So here's my current best practice:
- Set styles for all html elements in a global CSS file using either my own or any of the number of classless css frameworks. I personally like to use fluid responsive type sizes here which I set at :root and make sure that all padding/margins/sizes use rem or em.
- Use Tailwind or Windi for styling of layout and components.
- Use component scoped or CSS-in-JS for more complicated styling or where styles change based on functionality. (NOTE: Twind aka Tailwind in JS is potentially useful).
Of course, there are times too where Tailwind is not the best fit — namely if I'm working with a CMS that I don't fully control the templating. My fallback here is a good base classless css framework along with using css custom properties style variables to set up my design system. Level Up Tutorials has a good Modern CSS Design Systems course that touches on this approach.
This is how I'm approaching things now at least. It might very well change once some new better way of working comes along.
This post turned out to be longer than expected but then as I said I've been at this web game for a long time. I had a lot of thoughts to process and it was good to get them out. Hopefully this helps you on your journey to find your Best Practice!
Top comments (0)