Why use a framework/library where regular CSS will do?
Tags: css, webdev, design, productivity
Published: 2021-10-26 23:31:39

Hi everyone!

So this post wasn't what I was expecting to write today, but I think it's important to tackle, since frameworks and libraries are the hottest thing in CSS right now and everyone's either using them or writing them. Myself included, of course.

There's a lot of talk about which framework or library is the best, and which one you should use for what project. All useful in its own right, but not where I'd like to take this article. Instead, I'd like to tackle what is probably the biggest question underlying all of it: **Why?**

***Why should you use a framework or a library where regular CSS will do?***

## 1. Consistency

![Consistency Image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l81k9ptexn1mucchs9xk.png)

We would all like to think that we're really great with keeping things intact and consistent between different projects. I know I do.

And sure, all of us have certain common practices which we develop over time. There are also certain best practices and guidelines which many of us follow **(ex: BEM).**

However, one of the beautiful things about being human, is that we have the capacity to change. Unfortunately, this capacity to change, also comes with a capacity to fail. Like it or not, we forget things.

We forget naming schemes, we forget coding styles, we forget best practices, we forget accessibility guidelines, and so much more. This is where a framework or library can take some pain out of our process.

Frameworks and libraries not only provide reusable styles, but keep certain underlying choices consistent, even if we are producing vastly different designs each time. This has benefits both for you, the designer, and users.

## 2. Identity

![Identity Image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lcxwxncox1hapokbpxlb.png)

One of the most important aspects of design is also one of the most subtle. It's that highly controversial word, identity. But no, I'm not being political here, haha!

Rather, by identity, I'm referring to the presence of consistent, notable, recognizable markers that exist across multiple designs. Each designer has a design identity, and it is different from a "brand", though it is usually visible within your individual branding.

By using (a) framework(s)/library(s) to maintain consistency, you also gain the benefit of a notable *identity*, within your designs. It's worth mentioning here that you **do not** need to rely on a third party for this, either. You can build your own, in-house CSS and reuse it across products in the same manner. This is in fact how many frameworks and libraries are born.

## 3. Streamlining

![Streamlining Image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zo63s94hzr2cf4korx9h.png)

This is probably #1 reason why many designers and teams choose to use popular CSS frameworks and libraries in their development process. It just makes the whole deal so much easier!

Rather than having a patchwork of different solutions from different authors with different ideas and different approaches to solve different problems (dang, that's exhausting)...

...you get a pre-defined, ***reusable*** set of tools, or building-blocks, to put it differently. See what I did there, by the way? I used "different" like a class. Okay, you have to admit that was at least slightly funny.

On a serious note, a poorly optimized development process can cost you both time and money, even if the areas where you lack optimization are not immediately obvious. Design, and specifically the implementation of design through CSS, is one of those critical areas. Both designers and non-designers alike, sometimes have a tendency to underestimate not only the importance, but the weight behind CSS. It can be tricky to get it right, and even if not done wrong, it can take up a significant portion of your time.

Frameworks and libraries can alleviate some of the challenges involved with CSS development/design, especially when carefully chosen to suit the project at hand. In fact, even a poorly written framework/library can expose some of the previously hidden or difficult-to-determine gaps in your design process.

## 4. Ease of 'onboarding'

![Onboarding Image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c8dyc3c4fyazl0aqiff5.png)

Another important benefit to using frameworks and libraries is not always to be found within those tools themselves. Call it a meta-benefit, if you will.

Every time we approach something new, there's a period of time within which we must get to learn it before we can use it. Sometimes, this time period is *super short,* so much so, that we don't even notice it! You might hear someone say:

> "Oh, I got it *right away*!"

Reality is, they didn't — not if that something was new to them. However, the time period required for learning its means of operation, was shortened, likely because that 'something,' or some aspect of that 'something,' was already familiar to them.

We usually refer to the effort expended between discovery and 'operable mastery' as ["The Learning Curve](https://en.wikipedia.org/wiki/Learning_curve)".

With most frameworks and libraries, this 'learning curve' is both shortened and flattened by the existence of good (adequate) documentation. When working with a new project from scratch, you're not only responsible for implementing whatever design(s) you may have in mind, but for determining — as much as it depends on you — the experience others will have when working with your code or design.

In a team, this become especially important. More often than not, no one has the time to invest in asking or answering questions about how stuff works, and every new question requires some degree of sacrifice. This can especially cut into the experience new team members have when 'onboarding' — ie: getting to know their way around the team's workflow and codebase.

By using (a) library/framework to handle your CSS code, you can reduce the friction of this process, provided that you're working with something well documented, internally consistent, and of course - 'battle tested'. Those things matter too.

## 5. Learning

![Learning Image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/n8lp724r8agb22hsqic0.png)

For my final reason, I'm going to touch a little on *learning,* especially seeing as this was my experience when I was first learning CSS in depth. Although I'd done web design for years (mostly using WYSIWYG editors) and touched CSS here and there, my real deep dive into CSS came when I started building websites with Bootstrap 3. Having somewhat limited understanding (at the time) of the inner workings of CSS, I spent most of my time wrangling (and getting frustrated) with the provided classes.

In time, this led me to dig deeper, to start looking "under the hood" and figuring out why certain classes behaved in the way they did. I spent a lot of time in the inspector, or digging through the source code, and it led to me writing an extensive (even if misled) file called "fixes.css". I'd end up reusing this in multiple projects, until I eventually repurposed it and realized that it had become its own framework!

I share all that to say this: using someone else's work can be the means to learning how to create your own, even if it is through frustration with the quirks in theirs!

Even without encountering quirks and frustrations, you can learn quite a bit from using and exploring various frameworks and libraries. Ultimately, you'll find yourself becoming far more agile and comfortable, and you'll be better at writing from scratch in those times that you need, or simply choose to.

## In conclusion:

These are just a few of the many reasons why you might choose to use a CSS framework or library over writing your own code from scratch, but I'm sure there are many other reasons you can identify on your own.

You can look out for a follow-up post from me some time in the future, looking at some reasons why you may *not* want to use a library or framework, but rather build on your own. Should be fun!

### In the meantime:

- What are your favourite libraries and frameworks?
- What reasons do you have for/against using them?
- Have you written any yourself?

I'd love to hear from you, so don't be afraid to reply!

*See you next time!*