Important: The information in this article is over 12 months old, and may be out of date or no longer relevant.
But hey, you're here anyway, so give it a read see if it still applies to you.
LESS has been such a handy way to work with CSS - especially when paired with CodeKit. When looking at which preprocessor to use, it was between LESS and SASS. And LESS won hands down for its so-close-to-CSS syntax. Basically CSS with variables and helpers.
But more and more was seeing modern frameworks use SCSS, especially when starting to look at Laravel's base setup.
So I took a look at what SCSS had to offer.
Like LESS, the syntax is like reading CSS - it's CSS with variables and helpers.
I know this is such a small thing, but I really prefer SCSS's variables. LESS started with an @, where as SCSS starts with a $. Given my experience with PHP development, the $ just felt so much more natural.
SCSS also uses the idea of @mixin to define helper "functions" - which makes so much more sense than in LESS where it just looks like a class that accepts variables.
Here's an example of a helper function in LESS and SCSS to apply the translateX for a given amount and position. SCSS just reads more like a function - keeps me happy. Oh, and remember, using CodeKit allows me to use Autoprefixer to output the final CSS with vendor-specific prefixes.
In Less:
1.translateX(@amount: 50%, @pos: relative) {2 position: @pos;3 left: @amount;4 transform: translateX(-@amount);5}In SCSS:
1@mixin translateX($amount: 50%, $pos: relative) {2 position: $pos;3 left: $amount;4 transform: translateX(-$amount);5}It's just the little differences, but I am really happy with the way SCSS is working, and starting the process of migrating the development workflow at Mity Digital to use SCSS.
There is one thing I do miss about the LESS world though (when using CodeKit).
With LESS I could use the @import in my main LESS file and either include the imported file's contents, or even just use it as a reference (i.e. pick up its variables for use in other files).
1@import (reference) "variables.less";If I had a project with multiple LESS files that need compiling, this would allow me to have common helpers and variables included, but nothing else in that file processed (think maybe reset CSS for example).
But in SCSS, all you can do is import. Period. The parser itself will do one of two things:
If the file is SCSS (or SASS), it will process it and include its output in the calling file
If the file is anything else, it will spit it out as an @import statement again
The (reference) call was so handy to use.
A workaround is to approach my structure a little differently. I'll now have:
a reset style sheet (and the usual defaults that I tend to use)
a generic "helper" SCSS file (with mixins, but no direct output)
a project-specific "helper" SCSS file (with variables and project-specific mixins)
a main site SCSS (for above the fold, including all of the above plus additional external SCSS files)
additional SCSS (if below the fold loading is needed, a dedicated print sheet, etc, including the generic and project-specific helpers)
This means that I can still use the same concept as LESS's "reference", but just need to have more files to do this.
But besides this, I have embraced the switch to SCSS, and even written some really cool helper functions for a project that needed to repeat styles based on an array of colours. Neat!
