The Rise and Fall of Bootstrap
How Tailwind became the go-to CSS framework
I Used Bootstrap 5 Recently, and It Was a Nightmare Compared to Tailwind
I recently started to create small tutorials for developers. The goal was to show junior developers how a senior developer thinks when they code. For example, how a senior developer can understand documentation or a new framework they don’t know about and how they can find out when something is going wrong. The famous “code smells.”
I found sample projects on Frontend Mentors, and I coded them with various technologies. For example, the first project was an integration of a product card component. I decided to code the solution with plain CSS (in other words, no framework) but with Tailwind and Bootstrap.
Not only was it interesting for the audience, but it was also interesting for me. I wanted to see how Tailwind and Bootstrap evolved during the last few years. To be fair, I knew that the developer experience with Tailwind would be great, but I didn’t know that working with Bootstrap 5 would be such a pain. It was so terrible it prompted me to write this article.
In this article, you’ll find history (mostly about Bootstrap), thoughts (about my developer experience), and code snippets! Let’s start with the historical facts first!
The Time When Everyone Was Using Bootstrap
Years ago, Bootstrap was everywhere. In 2016, you couldn’t open a website that didn’t run with Bootstrap. CSS Flexbox was already there, but CSS Grid wasn’t well known and well supported. I remember speaking to a developer about CSS Grid in mid-2016, and I told him about the power of Grid. His answer was shocking: he thought I was speaking about the HTML table element, and he didn’t know a thing about CSS Grid. At that time, everyone relied on Bootstrap 3, and people were still using jQuery.
Besides Bootstrap, there were other CSS frameworks. The second most famous one was Foundations. Besides email templating, I didn’t use a lot of Foundations. Maybe it was better or worse or different or the same as Bootstrap. The truth is, I don’t know.
They claimed (and according to their GitHub pages, they still are) to be “The most advanced responsive frontend framework in the world.” When looking at the official documentation and their GitHub repository, it seems to me that it’s dead. I don’t want to spend too much time on the history side, but I just want to add a couple of things before moving on.
First, Bootstrap was developed by Twitter engineers, and they did a great job. Twitter still runs with Bootstrap, as well as many websites. Most of the time, you can tell easily if a website is running with Bootstrap or not, even if you’re not a seasoned developer. From my perspective, it doesn’t always sound like good news! Because when using it, websites tend to look the same.
It can be a strength for some websites because users don’t need to relearn the patterns and how to navigate the website. For example, they know what a link or a submit button looks like. But, at some point, your website loses its identity, and it becomes a weakness to rely on it. The second strength is that the core team decided to remove jQuery with Bootstrap 5. I don’t know if it was a good or bad decision. Today, jQuery is less popular than other frontend frameworks and is less and less used by developers, so in a way, it makes sense.
However, removing it increased the amount of work the core team had to deal with, and they lost some compatibilities with older browsers. If you want to learn more about it, here is a great article to explore this subject.
The third part is a “thank you” note. With Bootstrap, especially Bootstrap 4, the core team did an outstanding work with web accessibility. They introduced many concepts related to the aria attributes, and they provided concrete examples and code samples people can use. From my point of view, Bootstrap 4 was great! Sadly, Bootstrap 5 isn’t.
Tailwind: How It Reinvented the Way We Code CSS
Like many people, I discovered the term “Utility-first CSS” with Tailwind. Before that, I was trying to rely on BEM. I don’t know about you, but I have always been a kind of lost with BEM. I get the concepts of modifiers, but I sometimes struggle when I need to use either a block or an element. If you’re unfamiliar with BEM, I suggest you look at this resource. To sum up, BEM is a way to structure your CSS code.
On paper, structuring your CSS that way seems like a reasonable idea. However, it tends to pollute the readability of your HTML and violate responsibility. Here is a great resource about these concepts.
Let’s go back to Tailwind. Why did Tailwind make a great move when developing a “Utility-first” CSS framework? If you’ve already read the last resource I shared, you should already know the answer. Instead of relying on components, like Bootstrap, which applies many styles at once, you add classes that did only one thing. In other words, you write classes that can be composed to build any design: one class for padding, another one for font size, etc.
Let’s take an example.
This is how you write a card component with Bootstrap:
And here is the result:
This is how you write a card component with Tailwind:
And here is the result:
OK, the two cards don’t look the same, but I want you to look at the code. With Bootstrap, card components can differ in terms of sizes and colors, but in the end, they more or less look the same. Remember what I told you at the beginning of this article? You can easily detect when a website is using Bootstrap.
With Tailwind, however, you can add your custom styles to almost anything. Why is that so important, you ask? First, because it allows you to design the website how you want it, this is great, especially for designers! Second because, as a developer, it helps you to be as close as possible to your mock-ups, and it does so without breaking any responsibility between your HTML markup and your CSS.
With Tailwind, you don’t need to rely on BEM anymore. For me, that’s really good news!
Developer Experience and Documentation
Tailwind: easy to set up and easy to use
It was one of my first times with Tailwind. I mean, I knew the project before and had already read the documentation, but I hadn’t had the opportunity to use it for real. For this project, I decided not to use the CLI or PostCSS.
Instead, I decided to play with Tailwind with the CDN. When reading the documentation, I knew it wasn’t the best for production websites but for playing purposes, it was okay. But, even with the CDN, I was amazed to see how simple it is to customize Tailwind by simply adding custom colors and fonts.
In comparison, the Bootstrap utilities API is a mess. None of the documentation, nor the sample code examples, are easy to pick up, especially when you don’t know version 5.
Here’s how I customize Tailwind in my project:
In the code sample above, I added new colors and new font families inside the object literal tailwind.config .
And then, this is how I use it inside my code:
Look at easy it is! I don’t need to write custom CSS or Sass code. I just need to call the right classes to be able to use it. It’s really, really simple and yet powerful!
Tailwind: what great documentation!
This leads us to the second aspect of Tailwind's strength: its documentation. I’m a developer (and I think you are too). Most of the time, when we are in a rush on a project, we don’t have the time to read the whole documentation. We want simple but concrete examples that we can use and reuse.
We want to see if this is the right tool, and we want to see it pretty quickly. During the last few years, I became increasingly interested in Developer Experience, DX for short. Here is a definition I found on the internet:
Developer experience is every interaction related to your API or dev tool. —
source: https://everydeveloper.com/developer-experience/
When thinking about the interactions, don’t only think about code comments, great variable names, or following conventions.
Think also about documentation and how easy it is to work with a library or a framework.
For example, I think the developer experience with Symfony and Angular is great. They provide a tutorial, great documentation, and code samples. But there is also something more! When you start to use them, you also learn other concepts. For example, Symfony documentation explains the concepts of Entity and Repository Pattern. Angular teaches about Promises and Observables.
On the contrary, React documentation isn’t great. They didn’t explain how to write efficient tests for a long time. Even with Hooks, I don’t think they give enough information. Most of the time, when I speak to developers about React Hooks, they don’t understand how they work. In short, DX is important. More important than you imagine. It can make a project successful, or it can make it fail. With Tailwind, I could finish the project in just an afternoon. The documentation is easy to read and use, and so is the framework. So, what about Bootstrap 5?
Bootstrap: a mix of components and utilities
When I wrote this article, I wasn’t sure if I wanted to speak about the utilities API first or the mix between components and utilities.
Taking a step back, I think these two problems are related, but starting with components and utilities makes more sense.
Since its start, Bootstrap has been all about components. There are components for forms, carousels (even though you shouldn’t use a carousel), breadcrumbs, modals, etc. It is (or was?) Bootstrap's biggest strength.
What if I want a title? I’ll have a look at the Typography page inside the Content section, and I’ll find information about heading , display , and lead classes.
Great! But what about the Text page inside the Utilities section, especially the Font sizes subsection? Oh, it’s another way to change the font sizes. But which ones should I use? Can I combine both of them? What does the framework want me to do? These are the kind of questions I ask myself when I code.
My impression is that Bootstrap is between two chairs at the moment, and they don’t know which one to sit on. On one hand, they want you to stick with Bootstrap and its components library.
This is where the core team put so much time and effort. On the other hand, they introduced the utilities and their APIs. But again, the documentation doesn’t give many examples.
Bootstrap utilities API: it took a while to understand it
A few days ago, I was coding the Bootstrap solution for the product component challenge and creating new classes that didn’t use Bootstrap utilities.
I wanted to add a width of 90% to an element. I looked at the documentation, and found the Sizing page inside the Utilities section. The default widths were 25, 50, 75, and 100%. I first created a custom I called w-90 which represents 90%, but I knew something was going wrong.
Again the famous code smells! I looked at the Utility API page, read it quickly (as my developers do), and thought I got it. I had to install Sass and Bootstrap on my project to use this API with npm.
Fair enough! I installed them. I then went to the Sass page inside the Customize sections, and here I had a choice: either import everything and be unable to modify the utilities or import everything by hand.
I then modified the utilities (I’ll show you how to do it below) and compiled my Sass to CSS. At first glance, it seemed it worked, but I quickly discovered that my buttons no longer have style. Why do you ask? Because I forgot to import some Bootstrap parts. Look at lines 19 to 26.
It says, “Optionally include any other parts as needed,” but I’m starting with Bootstrap 5. I don’t know which parts are needed and which aren’t. Remember what I told you about DX? For me, this is bad DX! Because even when copying and pasting, you don’t have an example that works. It’s frustrating and doesn’t give a good impression.
Here is what I’d add to do to make it work:
I added all the parts, even the ones I don’t need (yet!), then I put a commit to let myself (my future self) know that I don’t need them.
I wished I had a concrete example. Then, I was finally able to add new utilities. Yep, a bit tedious. In the two last sections below, you’ll have examples of how to import and use a custom font with Bootstrap and Tailwind and how to add a new width. I think some people will be happy to have concrete examples!
How To Import a Custom Font
With Tailwind
First, import your fonts. I use Google Fonts.
Then, import Tailwind with the CDN and update the tailwind config object. I add fallback fonts and also add new colors.
Finally, use it!
Easy, right?
With Bootstrap
Install Sass with Npm:
Add Bootstrap via Sass and import all bootstrap parts.
Then you’ll be able to remove the parts you don’t want.
Between lines 9 and 10, I defined my Sass variables. I update my font-family utilities between lines 102 and 113.
Then, I use it inside my HTML file, as shown below:
How To Add a Letter-Spacing Property
With Tailwind
Import Tailwind with this code:
Use a custom tailwind class. Look at tracking-[.5em] .
Yep, is that easy!
With Bootstrap
Same as above. I install Bootstrap and Sass via Npm.
Then I update my utilities by adding a new one. Look at line 34. I create a new utility; it uses the class lt and has three values.
Finally, I use it:
Phew, it was a long article! Longer than I expected when I started writing it. I just want to tell you a few things about Bootstrap before leaving you. Bootstrap 5 is not great. Bootstrap 3 and 4 were better. Especially in terms of documentation and developer experience.
My impression is that Bootstrap is declining. It’s not dying yet, but it seems that the core team lost their vision and doesn’t know where they’re going. Maybe I’m wrong, but Bootstrap was made before the React and full SPA areas.
It tended and still tends to work well with full-stack frameworks but not with React. Or at least from my point of view. We don’t know. Maybe in a few years, we’ll go back to it, but today, it seems hard for me to recommend Bootstrap to junior or senior developers.
Here’s the full code of the challenge with Bootstrap and Tailwind: https://github.com/brocode-tuts/product-preview-card-component
