LESS is more? A Starter’s Guide to LESS and CSS Preprocessing.

Matt Basile
Nov 19, 2018 · 12 min read
Image for post
Image for post

Well Lumberg, we’re going to! We just need to learn the basics first! This post will provide everything we need to know to get rolling with Less! So let’s get started 🤟

What We’ll Cover:

  1. What’s a CSS Preprocessor?
  2. How to get set up with Less on a Mac.
  3. The terminology and application of Less:
  • Nesting
  • Nested At-Rules
  • Mixins
  • Variables
  • Functions
  • Escaping
  • Namespaces & Scope
  • Imports

Definitely, a lot to cover but nothing we can’t handle.

CSS Preprocessors

What are they?: CSS Preprocessors are a more robust syntax for writing our CSS. The way it works is we write our code using a preprocessor language (Less, Sass, SCSS, Stylus), it’s then compiled via javascript(in Less that’s through Node.js) and then output into a CSS file that’s read by our HTML.

It is a tad confusing but don’t get mixed up in the semantics. Just know that we input our code into a .less file, it’s then watched by a compiler that’s using javascript to convert it into CSS. This CSS is what is interpreted by our HTML and browsers.

Why use a preprocessor?: Using a preprocessor usually is determined by the team we’re working on. But the reasons why teams use them is they’re awesome as organizational tools.

Through Mixins, Variables, Nesting, Namespaces, and Imports our CSS goes from being a maze of code to structured and easy to filter.

Before we learn more about Less we need to download it! Here’s a quick guide to doing exactly that:

Downloading Less for Mac

Step 1: Install Homebrew: Homebrew is a wonderful tool for Mac users, and frankly, I don’t even know a whole lot about it. I just know that’s it’s a wonderful package manager we’ll need for LESS.

Proceed to Homebrew and follow their docs. It should instruct you to copy this:

and paste it in your terminal.

You will be prompted to input your password so pay attention as it loads. This package will automatically install Node.js, so we’re ready to compile and roll.

Step 2: Install Yarn: Yarn is a nifty package from the fellas over at Facebook. We’re using it at school because it flows nicely with the React Stack we’re learning soon.

We’ll use our newly download Homebrew to install Yarn.

  • Run brew install yarn
  • It should be Download at its most up to date version, but if you receive a warning run brew upgrade yarn
  • Lastly test that yarn is up in your terminal with yarn --version

Step 3: Install Less: Now that we’ve got our packages installed we can finally download Less.

  • In the terminal run yarn global add less
  • If this doesn’t work restart the terminal and try once more.

Step 4: Install less-watch-compiler: Possibly the most important step of all, downloading our compiler allows us to use Less efficiently and seamlessly.

  • In the terminal run yarn global add less-watch-compiler
  • You need this so please please please download it!

Step 5: GET STARTED!: Woo, we did it! If you want to get started right away here’s how you’d do it.

  • Create your project folder (Hopefully a Github Repo!).
  • Create an index.html.
  • Create a css folder — with an index.css file inside
  • Link your HTML file to your css file.
  • Create a less folder — with an index.less file inside.
  • In the terminal cd into your project directory.
  • Run the command less-watch-compiler less css index.less.
  • In your index.less file, set your body’s background:red;. Make sure your body turns red to ensure everything is working properly 😊.

Now that we’re up a running, how do we use this thing? Let’s dive into some of the conventions and terminology to get us rolling.

Conventions & Terminology:


When we look at our HTML and CSS side by side it’s hard to decipher where things line up.

Our HTML is organized with children nested inside parents it’s easy to understand the structure of our document:

In this HTML code snippet, we can see this hierarchy at play.

But when we look at the styles we apply to this code things don’t look as clean:

As the styles add up our CSS page begins to get crowded quickly.

What if we could shorten it? What if we could condense it to not take up so much space in our IDE? That’s exactly what Less Nesting allows us to do!

To nest in Less, we simply place our child styles inside our parents. It looks like this:

See how that works? All our header children are nested inside. Since, h1 and nav are siblings, they are at the same nested level. But our a tag is a child of the nav so that is nested in the nav.

Not only is it easier to parse, but it can be collapsed in our IDE. So instead of having large chunks of CSS sitting around we can just pinpoint right to our header and know the children will all be there.

Nesting At-Rules:

Another part of nesting is At-Rules. These are primarily used for media queries but they are awesome.

Similar to the reasons we love nesting in the first place, nesting our media queries provide a cohesive structure. Having our tablet and mobile styles below our base styles gives us clarity and organization that CSS lacks. Here’s an example:

See how easy that is? Our styles for every device right in front of us!

Also, now would be a good time to mention, since we’re using Node.js to compile our Less file, we can use Javascript’s comments (// ) instead of CSS’s (/**/). Another bonus!

At the end of the day nesting and nesting at-rules are organizational and specificity tools. In order to maximize Less, we need to introduce variables and mixins.


Variables are great because they let us store values to be reused later. This might sound trivial but picture this:

We’ve been working on a project for weeks setting the styles, spacing, and colors it’s a beautiful site… we are rockstars 🤘!

We’re so Awesome!

But the day before launch the Boss comes in and says, “Team, we all the love the site it’s fantastic. But corporate wants us to change our colors to hot pink and teal. Can we get this done by lunch? Thanks, guys!”

What did you just say?

Are you kidding me? How are we suppose to go back and change every single color style in just a few hours??

Well, what if we had a variable?!? What if we had multiple variables? That stored all our sites colors and if we changed their values it updated our whole site?!?

Folks, this is the beauty and power of variables. Take a look at how we’d write one.

Things to note about this code chunk:

  • If we ever want to change the values for our who page, we just need to change the hex color associated with our variable.
  • Although our variables are at the top of our page, they are lazy loaded. Meaning they can be placed anywhere on our page and specificity doesn’t matter. However, it’s nice for the next developer and you to place them all in one spot, usually at the top of your file.
  • See how easy it is to call it throughout our code? As long as the property accepts our variable it will work throughout our code!
  • Notice the &:hover, this is the syntax we use to evoke element selectors! To use it, we need to nest it within the element we want to be selected. But once we do that we’re ready to roll.

That’s the skinny on variables. Some other common uses are font stacks, font-size, colors, images/logos, but variables are flexible so use them to solve as many problems as needed.

Mixins: Mixins are even better than variables. They allow us to store a list of styles into one selector: a mixin.

Mixins are great for condensing a group of styles we apply to multiple elements and for creating unique components. Here’s an example of both using mixin syntax:

A few things about the mixins above:

  • Our first mixin is a parametric mixin. Meaning we pass parameters through it. In this example our @j-content and @a-items are the parameters we then pass into justify-content and align-items. Later when we call the mixin, we input space-between and center to assign those values. Pretty cool! Now every time we need to flex an item, we can assign the justify-content and align-items properties like nothing!
  • The syntax we use to call a mixin is dangerously close to calling a class. But the () are our saviors. Adding our parentheses tell our compiler to not convert this into CSS, so make sure you don’t forget it.

One more use case that wasn’t portrayed above is condensing our browser compatibility styles into one mixin. Remember in CSS when we had to declare, -webkit-box-shadow, -moz-box-shadow, box-shadow just to be safe?

Well now we can make one mixin named .boxshadow(); and include each of those in it! What a breeze! For more inspiration check out this article by Chris Coyier on useful Less mixins.

Once we get rolling with mixins our code starts to become so dynamic! Again think of the flexibility we have if the Boss comes down to adjust something we’ve styled through a mixin. Well, we just find our mixin and adjust the necessary properties!

Nesting, variables, and mixins are the Less conventions we use the most on a daily basis. However, there are a few more terms we should review so that we’re ready for anything.


Many preprocessors come preloaded with functions that can help our CSS become more dynamic. Less has a whole library dedicated to the types of functions they offer.

It’s incredible what they’ve put together, however, as rookie web devs, we probably won’t need to get too crazy. While there are definitely people out there using these functions to solve their design problems, I probably won’t be one of them till later down the line.

However, the color functions available to us are something we can utilize! Some examples are:

  • ligthen — pass a color and percentage to “lighten” it up. color: lighten(#ff0000, 20%);
  • darken — same as lighten, but it darkens the color instead. color: darken(#ff0000, 20%);

These color functions are great to apply with our &:hover selector:

Changing the background color subtly on hover adds a nice level of interaction to our page.

Functions can be useful as we’ve seen, and if you’re interested in learning more, I encourage you to dig through the docs!


Escaping is very similar to variables. We end up storing a value inside another value, but the syntax is different. With variables, we can store almost everything in there, but we can’t introduce unique characters like a semicolon.

That’s where escaping comes in handy. They can read these unique characters and not throw an error. This is especially great for using media queries.

We can store our query breakpoints in escapes so whenever we reference a media query we don’t need to type in @media (max-width: 800px);. Instead, we can store the chunk, (max-width:800px), into an escape variable!

Look at how nice that is! Some strange syntax but it’s a fantastic way of storing our media queries and implementing them.

I haven’t come across another use case yet, but when if/when I do I’ll be updating this post right here.

Namespaces & Scope:

I think of Namespaces as being a nice bonus to all the great tools we’ve acquired in Less. Essentially it acts as an organization tool we can use to store our mixins.

As we begin to fill out our styles, our pages can get a bit crowded. Namespaces clean them up by storing our mixins in one labeled area. Let’s see an example and it will become clearer.

Our two mixins,.layout(); and .border();, are now stored in our #navigation namespace! Woo that’s awesome, but how do we access them?

Scope in Less is a lot like CSS in that if a variable or mixin is not found locally it will be inherited from the parent scope.

So in order to call our mixins stored in our namespaces, we need to use a certain syntax to target them. That syntax looks like this:

It’s not too tricky! We call the namespace using the # selector and then target the desired mixin inside our namespace with a . followed by the rest of our mixin syntax.

Remember if we store a mixin in a namespace, we’ll need to take scope into account so we can target it properly.


Imports are the “bomb diggity dawg” of Less. They allow us to separate our code into sperate Less files. WHAATT?!?!?

I know it’s awesome! What we gain from this is more clarity. We can now organize all our styles separately, import them to our index.less file and finally compile it to our CSS.

The setup is intuitive, another reason why imports rock. To start, we would make as many Less files as we deem necessary. Some popular Less files are:

Specific items you’ll use on every page:

  • navigation.less
  • footer.less
  • header.less
  • global.less (for our global styles)

Specific page styles:

  • home.less
  • about.less
  • contact.less

Less tools we want to separate:

  • mixins.less
  • variables.less
  • functions.less

Essentially, if we want anything to have its own page we can make it. Now, this is great, but we need all these pages to point to our index.less so they can be compiled. To do this, we’ll start with nothing in our index.less file and then use the syntax @import "filename"; for each of our unique Less files.

How easy is that? Here’s what a full page might look like:

Look at that! All our styles being imported while remaining separated.

The great thing about the import is it allows code from other files to access each other. For example, styles in our mixins.less can be shared in our home.less and about.less.

It’s important to note, files we want to access on other pages most go on top. The same cascading principles of CSS apply here so our global styles need to go on top to have an impact.

Wrap Up

There we have it! A nice starter’s guide to the word of Less and preprocessing. I hope this helps you in your pursuit of Frontend Prowess and speeds up your dev time as it has for me!

Again, if you any question find me on twitter! I’m always happy to discuss the topics I’m writing about so don’t hesitate to reach out! Questions, comments, or smart remarks, all are welcome!

And if I don’t get another post out before Thanksgiving have an awesome Turkey Day!

Matt’s Lambda Minutes

A compilation of blog posts reflecting the topics I’m…

Matt Basile

Written by

Full Stack Developer sharing updates of his journey through Lambda School’s course. Check-in for a recap of core concepts and how-to guides.

Matt’s Lambda Minutes

A compilation of blog posts reflecting the topics I’m learning during my experience at Lambda School.

Matt Basile

Written by

Full Stack Developer sharing updates of his journey through Lambda School’s course. Check-in for a recap of core concepts and how-to guides.

Matt’s Lambda Minutes

A compilation of blog posts reflecting the topics I’m learning during my experience at Lambda School.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store