What is Sass and SCSS?
Recently I made a blog post outlining the benefits of using a preprocessing tool for CSS such as Sass which you can read using the following link. One thing I didn't discuss as I felt it deserved its own post was the dilemma of deciding what coding syntax to use when coding Sass. For you see there are 2 options and each hold their own pros and cons, these 2 options are Sass syntax and SCSS syntax.
The main differences between .Sass and .SCSS are the inclusion or exclusion of semi colons, the use of an ! or $ for variable declaration, the use of a colon or equals sign to assign values and finally the use and focus on indentation and how it affects the CSS code compiled.
[codepen_embed height=300 theme_id=1 slug_hash='InFfd' user='Geedmo' default_tab='css' animations='run']
Some of you may not know that Sass syntax was originally part of another preprocessor called Haml which is a preprocessor for the HTML language. Haml and Sass syntax follow similar formats in the sense of removing what they believed to be unnecessary code syntax and overall speeding up users workflow.
This may seem like the obvious choice of the 2 preprocessor syntax, however for developers who have come to favour the current CSS syntax conventions and have used the syntax for years it can be challenging to transition.
I had around 2 or 3 years CSS experience when making the transition and found it tricky to begin with. I found that I spent longer making simple code snippets and my overall workflow was hindered. This was short lived as with many coding languages, once I had adopted the syntax and could recall some of the powerful mixins available, my workflow improved significantly.
I however do not use Sass anymore and I will explain my reason soon.
[codepen_embed height=300 theme_id=1 slug_hash='Huqyg' user='Marcin' default_tab='css' animations='run']
SCSS, the bridge between 2 drastically different syntax. SCSS is a more favourable option to experienced developers as it offers all of the powerful capabilities of the SASS language, whilst maintaining a CSS syntax format which resonates with existing knowledge.
SCSS includes most of the syntax formatting from CSS, such as using quotes, semi colons and colons to name a few. It does not heavily rely on the indentation of the code (although you should still practice indenting code). As well as maintaining the existing CSS structure, it includes the new mixins and variable conventions, allowing you to take full control of the powerful options SASS presents to you.
Making the transition from CSS to SCSS is that of a much easier process in comparison of CSS to Sass. So if you are a long time CSS developer and you want to make the switch, it might be worth investing some time in to SCSS before you start charging ahead with the use of Sass.
Pros and Cons
|Pros||Sass allows for clean concise code to be written, by removing CSS code syntax. This speeds up workflow and minimises the code required.||Familiar coding syntax to CSS and new code mixins and variables remain available.|
|Cons||Steep learning curve, due to a very different coding syntax in comparison to CSS3.||Not as clean as .Sass syntax.|
Before I Conclude
Before I conclude this post, I would like to briefly mention statistics behind use of each syntax. Unfortunately there is no statistic that I can pull in to display the usage of one file type over the other. However I did do a quick parameter search on google and found that when performing a search for .sass files and .scss files, the results were 92,300 for .sass and 945,000 for .scss.
There is no right or wrong choice when it comes to a choice between syntax. It all comes down to what you are comfortable with and the same goes for any coding language.
I would personally challenge you to create a simple form layout using CSS3, Sass and then SCSS. See which of the languages you prefer after creating the same layout, using each syntax.
I personally find Sass to be a cleaner layout. However at my current workplace we use SCSS as it is more common and allows those who know CSS to feel comfortable in using a preproccessor.