Writing the style sheets for a website is an art. With all of the different ways you can manipulate HTML elements, its important to keep your code as clean as you can to avoid those weird style issues. That's where LESS and SASS come in.
Differences between CSS and LESS & SASS
It's important to know the basic difference between CSS and LESS and SASS. LESS and SASS are pre-processors for CSS code. They let you use variables and some logic in your style sheets. Since you can write actual code inside of your style sheet, your sheets become dynamic which is incredibly useful for responsive design.
With CSS alone, you have to write out the styles you want exactly where you want them. Your CSS files will not update once they are loaded. What you write is what you get. If you want hard code your styles that’s fine. Pre-processors just make it easier to do that.
About pre-processors
A pre-processor is just a program that writes CSS for you based on the code you write. By using a pre-processor, you're able to do things like use inheritance selectors and mix-ins. Those aren't options with regular CSS.
Pre-processors make it easier to read through your style sheets and figure out how everything is linked together. That makes it easier to maintain and update you styles without doing a lot of digging to find out why that image is three extra pixels to the right.
LESS
LESS stands for Leaner Style Sheets. It's typically the choice for projects when you want to use JavaScript with your style sheets. Using LESS isn't much different from writing regular CSS either. There are a few little add-ons that make it easier to handle you CSS, but they're fairly easy to pick up.
It's simple to reuse bits of CSS within your LESS files by using variables and mix-ins and even calculations. If you get really deep into the styles of an application you have the option to edit the JavaScript file that controls LESS. Normally you won't want to touch the JavaScript file but it doesn't hurt to look around.
SASS
SASS is basically the same as LESS except it's used in Rails applications. It stands for Synatactically Awesome Style Sheets. You can install it with these things called gems and I'll let a Ruby/Rails developer tell you all the specifics. The main thing is that it's another CSS pre-processor that makes it easier for you to write CSS.
You still have your mix-ins and variables and all the fancy nesting stuff. Like LESS, SASS is also completely backwards compatible with regular CSS files. It shouldn't take you long to get up and running with either of these pre-processors.
CSS
One thing you can't neglect, regardless of with pre-processor you use, is knowing how to write real CSS. When you start looking at pre-processors you should have a certain level of mastery over CSS. You should be able to get your web app looking like the design without using a pre-processor.
You should also know how to architect a CSS file. That'll help you keep you LESS or SASS files easy to read so you aren't jumping through trees like crazy. Nothing is more important than knowing the basics and CSS is about as basic as you get.
Hopefully that made sense of the CSS vs. LESS vs. SASS thing. They're really all doing the same thing. They just do them a little differently. Then there's SCSS which is a spin off thingy from SASS. I've used it in a non-Ruby project before but to be fair it wasn't the greatest project. Anybody else use SCSS outside of Ruby/Rails?
Hey! You should follow me on Twitter because reasons: https://twitter.com/FlippedCoding
Top comments (5)
I've used SCSS for years and never once in the context of Ruby. I think it is phenomenal and the organizational benefits alone make it worth using.
You definitely have to be careful with its nesting feature though -- it is easy to nest too much and end up with generated CSS that has such high specificity that you make everything more complicated.
Generally I stick to 1 level of nesting, 2 if I really think there's a benefit. But rarely more than that lest I create a monster.
One of the biggest benefits of the organization SCSS allows for is being able to nest media queries together with the elements that query is affecting. Love it.
I'm a big fan of combining BEM with the ampersand operator to let me use nesting in LESS or SASS while maintaining flat CSS selectors:
SCSS/LESS:
Output CSS:
I like it. BEM has some issues too in getting hyper-specific and tripping over its own verbosity.
Just like I don't nest more than once or twice in SCSS, you can create a nightmare with BEM once you start getting into grandchild selectors and the like.
Like for your example I probably wouldn't nest employer and position, but instead have them on the first level.
Of course I know your example isn't trying to teach BEM or be a shining example, just a quick example. But for those interested in BEM, definitely keep an eye out for traps:
smashingmagazine.com/2016/06/battl...
Personally I've tried sticking to BEM on a few projects but feel I drift away pretty fast from it. That's my own personal bugaboo and not for any technical reason. I just .. drift. Haha.
Yeah absolutely, I'd flatten it if possible, I was just trying to intentionally demonstrate multiple levels of nesting. But I have also found plenty of real-life cases where I needed to nest values like that for layout and/or semantic reasons. With the advent of CSS Grid it's becoming a lot less necessary to nest for layout's sake, but I still find it can be useful semantically, just to better organize the markup for reading, and in some cases for a11y purposes as well.
I personally haven't had much trouble with even pretty deeply nested BEM, as long as you're careful to refactor commonly repeated styles and component patterns out into reusable utility classes where it makes sense. But of course, as with any technique, you can take BEM too far.
Thanks for the comment! It's good to know that the level of nesting (5th level or higher) in that crap project was unusual.