DEV Community

Cover image for You don't need a CSS pre-processor
David Morrow
David Morrow

Posted on

You don't need a CSS pre-processor

Native CSS has come a long way in recent months/years. In this post I am going to go over the major reasons that folks have used css pre-processors such as SASS, LESS, and Stylus, and show you how you can accomplish these same things with native CSS.

Separating files

Separating files is one main reason folks reach for a pre-processor. For quite some time now though you have been able to import another file into a CSS file. It looks like this.

@import url("./utils.css");
Enter fullscreen mode Exit fullscreen mode

You can use a relative or an absolute path, the same way you would for an href on an anchor tag, or any other resource.

The main difference between this an a pre-processor would be that while a pre-processor would combine then at compile, CSS is going to make an http request at runtime.

Nesting rules

Ok this is the main reason for using a pre-processor. At least it's my main reason for using one in the past.

But CSS now supports nesting, and it works mostly how you are used to from using pre-processors.

header {
  h1 {
    font-weight: bold;
  }

  h2 {
    font-weight: normal;
  }
}

Enter fullscreen mode Exit fullscreen mode

Pretty awesome, what a huge advantage to writing CSS like we have for decades.

header h1 {
  font-weight: bold;
}

header h2 {
  font-weight: normal;
}
Enter fullscreen mode Exit fullscreen mode

Sudo selectors

Sudo selectors work the same way in native css that you may be accustomed to from pre-processors as well.

button {
  color: blue;

  &:hover {
    color: purple;
  }
}
Enter fullscreen mode Exit fullscreen mode

You can read more about nesting at MDN.

Variables

A long time reason for pre-processors was variables. You can have all your colors, spacing ect in one file and globally update it everywhere.

Well you can do that in native CSS now, for some time. In fact in several ways it's better than the pre-processors.

Global variables

Global variables are enclosed in a :root rule. These can be referenced anywhere.

:root {
  --bg-color: #333;
}
Enter fullscreen mode Exit fullscreen mode

To use a variable, it must be referenced with the var tag

button {
  background-color: var(--bg-color);
}
Enter fullscreen mode Exit fullscreen mode

Scoped variables

You can also scope variables on selectors, for example...

header {
  --bg-color: #999;
}
Enter fullscreen mode Exit fullscreen mode

So in this case, referencing var(--bg-color); within the header selector will result in #999;

Re-assigning values at runtime

So the main advantage with css variables over a pre-processor, is that they can be overrode at runtime, where a pre-processor once its compiled, it's permanent.

So for example if you have a website that you want to support light and dark modes. This can be achieved very easily using css vars.

:root {
  --bg-color: white;
}

body {
  background-color: var(--bg-color);
}

@media (prefers-color-scheme: dark) {
  :root {
    --bg-color: black;
  }
}
Enter fullscreen mode Exit fullscreen mode

To achieve something like this with a pre-processor, you would need to toggle a class on the body using Javascript, and override all the rules with a .dark class or something of the sort.

Computation

Most pre-processors such as LESS, Stylus, or SASS let you do math on things. Like if you want to divide a variable in half ect.

You can do that in native css using the calc function.

:root {
  --spacing: 2em;
}

header {
  margin-top: calc(var(--spacing) / 2);
}
Enter fullscreen mode Exit fullscreen mode

how cool is that?

Transforming colors

So another popular feature (at least to me) is to lighten and darken colors in a css pre-processor. You can do this in native css now as well using color-mix.

header {
  background-color: color-mix(in oklab, red 50%, white);
}
Enter fullscreen mode Exit fullscreen mode

The above would be the equivalent to what you are used to doing with a lighten(red, 50%) in a preprocessor.

To darken just mix with black instead of white

header {
  background-color: color-mix(in oklab, red 50%, black);
}
Enter fullscreen mode Exit fullscreen mode

I hope next time you are choosing what tools to use on a project, you will give native css a try. It has come a long way.

Top comments (3)

Collapse
 
wizard798 profile image
Wizard • Edited

Absolutely, my main reason to learn SCSS, was nesting, separating files and variables and after I completed my SASS learning then css updated it to separating files support and nesting rules😅 ( vars were already in css when I started learning )

And also, as of my experience, as a person who dived very deep in css, Please don't give too much focus on css, as a curious person I went through it. But it's not that worthy cause when you learn any css framework ( I learnt Tailwind cause I prefer giving my own styles and gives more me independence ) it'll mostly do all your work making speedy process, and believe me, when you complete to learn React/Angular/Vue or any other frameworks, you're gonna mostly use any pre built components which are perfect and they are made in a way that you can easily configure them.

Collapse
 
robertlikescoding profile image
Robert

So what you mean is one should not try to „master“ CSS because the libraries mostly take care of it? That sounds relieving. I was just about to deep dive into SCSS in the next days but reading this article I think I’m gonna be fine with CSS and rather spend my time looking into Tailwind 🙂

Collapse
 
dperrymorrow profile image
David Morrow

Yeah I am trying to point out that the things that folks, (myself included) have been using CSS preprocessors such as Stylus, LESS, and SCSS, are now widely available in CSS itself.

In my opinion, CSS is very much worth being proficient at. I Consider HTML, CSS, and Javascript web programming fundamentals. Popular JS and CSS frameworks and libraries come and go, but investing time in mastering fundamentals will serve you for your whole career.