SCSS is an excellent tool for styling interfaces, as it functions as an extension of pure CSS, which is what you can find out when first entering their website:
“CSS with superpowers”.
So, what is so cool about using SCSS and not yet another CSS Library?
I will use Bootstrap as a reference, as that’s one of my personal Nemesises
Introduction
Let me start by telling you about a situation you have undoubtedly encountered:
You have just installed your new and shiny Bootstrap package, or you just added the CDN to your basic website.
What’s next?
Well, you tell me after looking up every class you need to customize your components properly.
Not only that but good luck trying to get over the default !important rule that Bootstrap often likes to use.
Sure, I might be exaggerating here, and don’t get me wrong, I believe that CSS Frameworks can be beneficial to getting your styling done decently fast.
With all of that, however, I don’t enjoy the idea of using them.
Below I’ll also make my points about my preference for using SCSS over any CSS Library / Framework.
Why Don’t I Like Working With CSS Libraries?
Memorizing Classes
The first reason I don’t enjoy working with UI Frameworks is that getting used to how they do their thing, how they use classes, etc., is highly time-consuming.
It’s going to take tens of hours, during which you will have to constantly come back and check what classes do what, which is something I find pretty annoying.
And listen, I get it, it’s not that bad, and I’m not saying it is, but coupled with other things in this article, you’ll get my point.
In contrast, we have SCSS, where we won’t have to learn the classes specific to any library. Still, instead, we can make a “library” of ours, which would be far easier to adapt to our naming conventions, and style however we want, whenever we want, and do that indefinitely without any limit imposed by libraries specificity.
Specificity Constraints
This is something I mentioned at the beginning of the article as well.
Most of the time, when trying to override any styles, you would have to win a couple of battles with the Library itself by encountering something that resembles this:
#id.class.class.class {
property: x!important;
}
And after redesigning that component over 15 times because something isn’t right, this is the last thing you’d like to run into.
And after creating yet another class to override this thing, you would enjoy your bit of freedom until you run again into another conflict with the constraints imposed by the Library.
And I get it; you can create your own components instead of using theirs, which would ruin the purpose of using it in the first place.
What I Like About SCSS
Simplicity
The feeling when you start a new project and are just enjoying the peace of creating your variables, classes, ids, etc., and there’s no library to disturb you has to be one of both the best and scariest.
You get to decide what the structure is, how to keep everything clean, what methodologies to follow, etc.
And maybe you don’t even need a library for this very reason; why invoke a whole library when all you need to do is style three headers and two divs?
After all, one of the reasons I see you might need to use one, as stated earlier, would be when you are on a tight schedule or are working on a massive app, where styling of individual things would be a headache.
Practicability & Power
Once again, as mentioned on their website, SCSS is CSS with superpowers, which really is so.
One of its most powerful superpowers is that you can nest rulesets, which means you won’t need to create 100 classes for nested rulesets.
As a side note, we can also nest BEM elements & modifiers within rulesets by using the
&__and&--prefixes.
And not only this, but you can nest different attributes. This means that instead of opening a new tag to change the hovering effect of a button, for example, instead of doing it like this:
We can do something like this with scss:
This might not seem like much, but believe me, I saw examples of code being reduced by almost 50% by using SCSS’s features instead of pure CSS.
Versatility
A project I took part in required us to write our own component library, and this left me wondering, wouldn’t this thing actually remove the con of using SCSS?
That is the fact that we have a longer development cycle when working with SCSS instead of a CSS Library.
So if you took your time on a couple of weekends, you could create your own highly configurable and highly-stylable components that you could use in all your projects instead of the classic libraries-specific components.
I know you might be thinking:
— “But Vlad, isn’t this us writing a whole library instead of using one? How is this simpler to use?”.
Well, I agree, it’s more work than actually using a library, but hear me out; it’s a library that you wrote, and not anyone else’s, which means you know everything that’s there inside-out, which I do consider to be a pro.
Since you wrote your very own highly-configurable component library, you will be able to change anything depending on the business or personal needs, which won’t be that hard since you are the one who wrote that thing.
Conclusion
At last, I hope you enjoyed this article, and it made you consider using SCSS in favor of standard UI libraries, at least when using a UI library isn’t necessary, as stated in the previously-mentioned scenarios.
And once again, I don’t want to bring hate to any CSS library, as they all have their purpose; it’s just that I believe they are not as useful as much as they are used. But I will leave that decision up to you.
Cheers!