There was a time when I was absolutely against every type of CSS library. The thought of using pre-defined class names gave me the shivers. Now, after working with them for some time, here are some of the thoughts on the matter.
Bootstrap & Tailwind seem to be all the craze.
Most of the time when using a framework and library, I usually worked with Bootstrap or at least some variant of it. Even after working with a library for many years, I still believe that beautiful code, written from scratch, is more pleasing, exciting and can give your project that extra bit of “oomph” (I’ll get back to that). The second most popular one seems to be Tailwind, which differentiates itself by being more “utility based”.
Both of these libraries seem to have their ups and downs, and most importantly: they learn from each other. Bootstrap is gaining more utility classes and new “tailwind component websites” are fired into webspace every week or so.
But let’s not forget, even though these are popular libraries, it doesn’t mean they are here to stay. A lot of frameworks and libraries seem to fade over time, but because of the popularity of these two, I’m pretty sure we’re good for a while. Material-UI is also one of the bigger ones but it doesn’t seem to get the big “hype” and usage as the other popular ones.
What’s good about CSS libraries in general?
No matter how you look at it, one thing both of these have in common is a decent documentation. If you start a job in a company that uses one of these libraries, you could be a billable developer in no-time. From an economic point of view they are great because they’re easy to learn, fast and let’s be honest, clients really don’t care if you use a library or framework.
These libraries have updates and some of them take too long (yes, I’m talking about Bootstrap 5). But the good thing about it is that many people work on these, whether it’s just giving feedback or active development. They are tested and they work when they get a major release.
Another thing that works their magic are utility classes. I’ll be honest, I love these kinds of things as long as they’re not over-used. They make it easy to show a quick change inside the browser or to make a quick prototype.
As a final thought I’d like to add that many good methods for writing CSS were created for them. Some of the styling ideas they have are just plain clever.
Let’s talk about the bad things.
First of all, when you’re building a website using Bootstrap or Tailwind, you’re not actually writing CSS. Some people don’t have a clue what they’re doing, it just works and they’re happy. Yes, you will mostly add a bit of custom CSS to make the website a bit more unique but that’s still not the same as truly taking matters into your own hands. The libraries do get a bit outdated over time and if you like to use those awesome new CSS features, you’ll have to write them yourself anyway. In the end, you’re getting a bit lazy when using them all the time.
One major issue I had when the first Bootstrap release was that I could see that something was made with that particular library without even inspecting the code. But thankfully that isn’t the case anymore. But from time to time, you still see a lot of websites that make you think: “yep, that’s Bootstrap”.
Libraries include way too much CSS in your project. There are ways to counter that, for example, you could use PurgeCss for production releases. In a world where performance matters, you should see every kb stripped from your files as a win no matter how hard you’re caching.
Bootstrap specific.
Bootstrap has a lot of components and utilities, you are almost certain to never use even half of them. Even when you load the Sass files and start commenting out the component specific imports, it will still be too much. When you’re making use of the built-in components you’re probably making things too complicated as well. A very basic example is the following. Imagine, you just want a simple card with some text in it:
In bootstrap, you might write something like this:
<div class="card">
<div class="card-body">
This is a simple card, i don't need a header or footer in it, but when using
a framework, i'm using way too much css for the simple thing i want to
create...
</div>
</div>
Which gives you the following output in your css:
.card {
position: relative;
display: -webkit-box;
display: -ms-flexbox;
display: flex;
-webkit-box-orient: vertical;
-webkit-box-direction: normal;
-ms-flex-direction: column;
flex-direction: column;
min-width: 0;
word-wrap: break-word;
background-color: #fff;
background-clip: border-box;
border: 1px solid rgba(0, 0, 0, 0.125);
border-radius: 0.25rem;
}
.card-body {
-webkit-box-flex: 1;
-ms-flex: 1 1 auto;
flex: 1 1 auto;
padding: 1.25rem;
}
This is a lot of CSS for such a little bit of layout. Of course it is handy when you want to add a header later on, or an image, or a footer. It has a multi-purpose. But if you just need something like the example above. you can just write the following and it will save you a lot of output:
<div class="card">
This is a simple card, i don't need a header or footer in it, but when using a
framework, i'm using way too much css for the simple thing i want to create...
</div>
.card {
padding: 1.25rem;
background-color: #fff;
background-clip: border-box;
border: 1px solid rgba(0, 0, 0, 0.125);
border-radius: 0.25rem;
}
You might be thinking that this doesn’t change all that much. Well, this little difference just removed 372 bytes from your CSS file-size (unminified for both). Not bad for a simple card, imagine how much more you could save.
Tailwind specific.
Tailwind is utility-based and personally, I like the idea of it. The problem is that many people just write HTML with so many utility class names that it becomes unreadable and hard to maintain. Tailwind suggests that if you have something repeatable that you write it in CSS instead but a lot of people seem to ignore that. Here is an example of a bad situation:
<button
class="h-12 px-6 m-2 text-lg text-indigo-100 transition-colors duration-150 bg-indigo-700 rounded-lg focus:shadow-outline hover:bg-indigo-800"
>
Large
</button>
Seriously, this is just an overkill. Just write a general “.btn” class for your buttons so you can maintain them well in the future.
The future of CSS.
Let’s not forget that CSS specs are updated all the time. Frameworks and libraries have given us a lot to work with. Now, we can use variables in CSS, easy grids with the grid system, nesting CSS is starting to become a thing as is layering. It’s becoming such a strong language that can even handle masonry layouts while in the past we had to use JavaScript. We have so much to choose from, we can make a battle plan for every type of layout we want to tackle and talk about our choices in a beautiful discussion. It’s great, you can’t do that when working with a library.
There are so many things we can do now that aren’t available in the libraries. We have to make a fallback from time to time, but maybe we should ask the question: Is it better to “hack a library”, or to add a fallback and be future proof?
So, am I saying CSS frameworks and libraries are bad?
When comparing this, I always picture a colouring book versus a sketch book. When working with a library, you’re actually just colouring a predefined drawing and maybe adding a little picture of a flower in it. While working from scratch, you’re making little pieces of art in your sketchbook, let’s call it, “working from sketch” from now on?
I believe in libraries… As a corporate developer for many years, I know they work their magic. They can set up a project in no-time. Budgets get a bit lower because we’re colouring between the lines and you get told you did a great job using someone else’s code. We can be faster when using them and browser issues are less bound to happen. In the end, when working for a company, money and time are the big factors. When you’re from Belgium, you learn that good front-end development is a hard sell. It’s a shame but a simple truth.
Even working on side projects makes me want to use a library from time to time. I have a kid, hobbies and friends. Choices in time have to be made for all of us.
The biggest problem is that they provide too much comfort. Remember when you started out using CSS and how happy you were that something magically worked? You just knew you did something special and you loved it! You would go home with a smile on your face. Those feelings are much harder to find when you’re just using the library.
So, use your libraries within your favourite framework but remember to try something different from time to time. Whether it’s a little codepen or a little project on the side. Because between all these libraries, frameworks and pre-defined sets there is a little thing that made us want to do this for a living, and it’s called CSS.
