This is the second part of a three posts series that discuss our switch from Bootstrap to Tailwind CSS.
This post in particular reflects on what problems Tailwind has solved for us. Throughout the first post, a little story was provided as background to our project.
Naming is hard
We all know that there are only two hard things in Computer Science: cache invalidation and naming things. Naming is especially hard in CSS.
You start with a narrow scope class name i.e. .page-header only then to realize that you can use the same CSS properties for .panel-title. You start with a wide scope class name and after a while you start thinking that you need to narrow down the scope or combine it with other utility classes.
There are of course solutions to this problem like BEM, a naming convention standard for CSS class names. I always found BEM a bit too verbose for my taste.
Tailwind takes the naming away in most of the cases, especially when you combine it with a component based solution.
Let's say you are building a new card component and you want to style the card header. You could introduce a new class i.e. .card__header, then define the CSS properties and maybe do same for the child components.
While the above works, the chances are that you are not going to use the same class anywhere else. With tailwind approach you will be ending doing something like <div class="text-xl text-gray-500 mx-5"> and you are done.
Looking back, this reason alone might was enough to reconsider Tailwind CSS.
Code reviews
One of the problems when reviewing front-end code is how the code spans across different locations. For example, a new class is added to a particular element and then you have to check how the corresponding class was defined in another place.
This over-complicates reviewing. Especially when there are changes on existing styles and you are not sure how this could affect the entire application.
Code review is much easier to go through, when using utility classes along with HTML in one place. You can tell from the classes used what has been changed, without moving to the CSS. Also, you don't have to worry that the change had a negative affect somewhere else.
The above benefit was not initially clear. It slowly became obvious as we proceeded with the implementation and adoption of Tailwind CSS.
Built for components
Tailwind CSS is ideal when working with any component based library or framework like Angular and Vue. It helps you to improve how you approach re-usability.
Usually in such cases you have two ways to approach re-usability: via CSS classes and components.
Tailwind CSS, being a utility-first CSS framework, gives a great emphasis on re-usability via CSS classes. The scope of each CSS class is very narrow, which means that it can be re-used very easily. So this part of re-usability is pretty much well covered.
With the above in mind, the mindset is shifted towards component based re-usability. So instead of creating new classes that can be shared across components, we started thinking more about how we could solve this by introducing a new component.
Less rules to follow and one less layer of abstraction.
Conclusion
Throughout this post I analyzed the main three reasons why we eventually went with Tailwind CSS. There are other reasons of course, but these are the main ones.
As part of the next and final post of this series, we will be looking at some challenges and myths around Taiwlind CSS.
Make sure to follow me on dev.to, Medium or Twitter to read more about Angular, Tailwind and other dev topics.
Photo by Ross Findon on Unsplash
Top comments (0)