In the world of development, the term full-stack can spark some debate. We take a closer look at what being a Full-stack developer entails, and the skills you need to become one.
I Hate CSS
Perhaps that’s a little unfair to say. I absolutely love what I can create using CSS. But actually writing CSS, well, that’s a different story. At first the two important concepts of CSS, cascade and specificity, seem cool when starting to learn the language. However, the fact that CSS lacks scopes like that of a programming language becomes painfully apparent real quick. As your stylesheet grows, it becomes extremely difficult to expect the outcome of each and every line of code you write.
DRYing up CSS by creating reusable classes leads to elements with numerous classes, which leads to conflicting CSS definitions, which must be managed somehow using specificity, which means now your styles are dependent on DOM structure. When you find yourself using # or !important in your CSS, you should realize you dun goofed. /rant
Introduction to Sass
Sass is a CSS preprocessor, which means it takes code written in its own syntax and compiles it into CSS. So to write with sass, we need to install compilers, or better yet, use it within frameworks (e.g., Ruby on Rails) or with task runners/bundlers (e.g., Grunt).
One thing that confused me when first learning Sass was the file extensions. You can either use .scss or .sass, and the only difference lies in syntax. What happens under the hood is the same. SCSS let’s you use vanilla CSS syntax, so that’s what we will use.
Introducing the basics of using Sass is well documented in its official homepage, it almost feels impossible to try to do a better job at it. So instead, let’s just review a few of the topics that are relevant to this post:
Variables and Functions
It’s easy to see how powerful Sass is. However, with great power comes great responsibility. Misuse your power a tiny bit and now your button no longer has proper border-radius! No, but seriously, Sass makes it easier to write CSS, which means it’s easy to abuse and write bad CSS. If the first thing that came to your mind was “writing nested selectors will be so much easier!,” then you’re on that boat. You need some BEM in your life.
Block Element Modifier
Did I mention it’s easy to abuse CSS inheritance? Again, inheritance cancreate a lot of headaches. So how can BEM help? BEM is methodology, not a piece of technology. You don’t download and install anything, you just study it and apply it to your code.
BEM stands for Block-Element-Modifier. It describes how CSS classes should be named. According to BEM, they should look like this:
What are we trying to accomplish by doing this? What is the philosophy behind it?
- Composition over Inheritance
HTML elements are to contain other styles by choice, rather thaninheriting such styles automatically. In other words, we’re trying to force our elements to behave in a more predictable manner by making the styles it receives more explicit. An aspect of this is to apply the single responsibility principle to CSS, by creating classes do one thing well and have elements have multiple classes. However, BEM focuses more on,
- Avoiding Inheritance with unique classes per elementSo composition happens more in the stylesheet than in the HTML document (Sass helps to achieve this with @extend). This also means,
- Lowest Specificity to Minimize Conflicts
As elements will receive styles from unique classes, there is no need to use nested selectors.
For example, instead of,
We might do,
But wait, the second code looks bloated and messy. It’s repeating itself!
Regarding the first argument, all I can say is it’s worth the ugliness and you’ll eventually get used to the long-ass class names. Repeated code, however, is a valid concern. Luckily, we have Sass to help us with that. The CSS above can be written in Sass as,