Why we switched from Bootstrap to Tailwind

Web technologies change and improve at an alarming rate. css is up there as being one of the fastest moving with additions such as aspect-ratio, css variables, flex and grid in recent years significantly changing how we write and think about the code that styles all of our websites. With these enhancements, come new and exciting frameworks and methodologies. The end of 2022 was when we decided it was time to take a fundamental look at our styling toolkit and see if there was a better way out there for us.

Our previous setup

Previously we used a combination of bootstrap (BS) grid and utility classes, custom utility classes and custom styles using the Block Element (BEM) methodology. Starting just from the full bootstrap library, this stack was developed and added upon over the years to a point where it was a bit of a mish mash with developers leaning more on different aspects. As designs got wider and more complex with asymmetric grids as opposed to the simple 12 column layout that ships with bootstrap, we found ourselves using the BS classes less and less leaving redundant css classes in our stylesheets unnecessarily increasing the file size.

Choosing new framework

We’d been aware of Tailwind for a while but when we’d looked at it previously it seemed like it still needed time to mature. Thankfully at the time when we were looking for alternatives I listened to a podcast with Tailwind’s creator ‘Adam Wathan’ that brought it back to the forefront of my mind. We decided to see what all the Tailwind hype was about.

What is Tailwind?     

Tailwind is a utility-first class framework which advises you to stay away from stylesheets and confusing class names like ‘banner–tall__title–xs’’ and write all your styling in classes on the elements in the HTML. Each utility class that is available sets just one css attribute (in 98% of cases) and has options to apply it at different breakpoints to make responsiveness very quick. The utility classes also include ways of targeting children, pseudo elements, animations, adding hardcoded values and more.

Why did we choose Tailwind?

There are many positives to using Tailwind but the defining factors for us were:

• Better understanding of css – classes very rarely change more than one property so there’s less abstraction from css. No longer can you just rely on .row to do its magic without actually understanding css flex. You’re learning the underlying technology rather than a framework which makes devs more agile if they need to work on a project that doesn’t use Tailwind.
• Developers can maintain a consistent design language throughout their projects rather than trying to remember if we call them teasers or cards in this project.
• Make our code base more modular – not having a css file associated with a component means that it’s a lot easier to copy components between projects.
• Most used framework in the state of css 2022 report
• Only ship the css that is used in your project reducing the size of the website and increasing performance which is more important than ever with Google Core Web Vitals. 
• An active team developing it with frequent releases
• The documentation. They have the best tech documentation website I’ve ever used with a super fast search functionality for all of the available classes. Each attribute has its own page with examples and diagrams on how the class should be used. They’re also not afraid to repeat themselves with other relevant classes and rules on the same page so you don’t have to look elsewhere if you need a refresher.

How is it going?

We’ve taken a staggered approach to adopting Tailwind across the team. Feedback so far has been largely positive but there have been a few areas of doubt.

People love

• That its simplified and sped up the build process

• That you can look at someones HTML and know how its styled no matter what project
• Keep up to date on additions to css
• You can use it as much or as little as you like
• Forces you to think more about the code you’re writing being DRY

People are unsure

• HTML feels messy
• Repeating yourself with elements like buttons
• No way of grouping responsive classes together

Conclusion

Many of the reasons to choose Tailwind won’t be felt until we’ve been using it for a while. After the learning curve and teething issues have passed we’ll take another look at whether the switch to Tailwind has been a success but for now we’re definitely glad we made the switch. Thank you Tailwind.

Back to all newsBack to all news