A little while ago, I asked the Internet its thoughts about how best to work with CSS when following the BEM methodology. And in the following months, I’ve come across some ideas worth sharing.
A little background
When I was working on the website that inspired the question, I realized that I was creating a lot of components that were only slightly different. One example would be the listing of “stories” and “events”. Their templates and style were very similar, but because they were different, they had a .paginated-story and .event-listing base class. I then created a %listed-item Sass placeholder for both of them to inherit from.
I mentioned a few things in the article about why I liked this approach, but the truth is that it had a bit of a code smell. It was nice to be explicit about where the styles inherited from, but it was a lot of code to write and maintain.
The wind of change
In the interim, I looked around for other ideas and came across the CSS frameworks that focus on “utility classes”. These are short classes that are generally named after the one CSS rule they represent. So instead of having one class for each element, you end up having a string of terse classes like d:i-b f-w:700 p-x:3 ttu mt1 that style your element instead.
I decided to try the Tailwind CSS framework, even though I had a few concerns.
First, I wasn’t excited about adding a lot of class names to my markup. I really appreciated the cleanliness of BEM’s classes, where one class name is almost always what you need.
Second, I wasn’t looking forward to memorizing abbreviations for each of the CSS properties I was going to use.
And lastly, I honestly didn’t think it would stick since I didn’t enjoy the other utility class frameworks I tried.
I mist say, right from the start, I really appreciated the thought that the team has put into creating this framework. The documentation helped me to hook Tailwind into my existing project startup template with hardly any down time.
This startup template I speak of is a git repo of mostly Sass files that my teammate and I built up to use in each project we worked on. It contains a CSS reset, grid implementation, reusable functions, and a place to set up variables for responsive breakpoints, colors, transitions, and the like.
Within the first hour of using Tailwind, I realized that I could literally throw most of my starter files away. Tailwind has a great ability to be customized for any project, and it comes with enough stuff to get the majority of design work done in one pass. I actually had more problems using my old stuff and getting rid of it than issues with Tailwind.
What do I like?
The main reason why I am trying to adopt Tailwind is the ease with which I can build up a web page, all from the HTML. It’s really nice to build a scaffold of what I need and modify classes to get the design at least 80% of the way there—while just working in my HTML file.
I also really appreciate that Tailwind has the flexibility to create your own classes and components, so if you find that you’re using a lot of the same classes, you can create a new Tailwind component with those properties.
Wanna give it a try?
If you’re interested in trying it out, here are a couple of things I suggest:
- You can still use BEM classes, but lean on the utility classes.
When I first started using Tailwind, I was using my BEM classes and using Tailwind’s@applyfunction to use its classes in my Sass code. It was a nice tool to use as I was getting used to the framework, but as I started coming back to refine the design, I didn’t like having to go back to my SASS files to edit the things I could edit with the utility classes. I’ve since gone back and pulled out most, if not all, of the tailwind classes out of my Sass code.
But I do find that having BEM classes still help for finding my way through the HTML code and for the occasional styling that Tailwind doesn’t cover. - Customize the configuration to your site.
As nice as it is to have 73 colors, you really don’t need them. While you’re in there, change some of the padding or margin numbers. And add higher ones. Make it your own.
What could be better?
While I am enjoying Tailwind so far, there are a couple of things I’m wish were better.
Removing a battery
It feels like Tailwind creates a lot of CSS. You can mitigate that by turning things off in the customization, but it isn’t the best user experience. By the time I want to start reducing the size of the CSS file, I can’t be confident what I can safely turn off.
I’ve heard many people in the community suggest adding another project, called PurgeCSS, into their production process. It will look through your code, keep track of the classes you use, and remove the CSS rules you don’t need. I’m glad to hear such great feedback about the tool, but I haven’t tried using it yet.
All the names
I think the Tailwind team did a great job of coming up with the names of the classes they used. I like that the most common use cases have very short names and the lesser cases have more descriptive names. That said, I’m having a hard time remembering many of them.
To mitigate that, I’ve added the Tailwind CSS Docs plugin for Sublime Text, which helps me to quickly navigate to the related documentation page. That definitely helps, but I’d like a better option.
After three months working with it, I’m honestly still getting used to having these extra class names, but I think Tailwind is making a spot for itself in my workflow.