Understand the Power of Sass and Why You should use CSS Preprocessors

Posted in Coding, HTML & CSS, Tutorials2 years ago • Written by 8 Comments

Front end engineering has always remained a niche skill, even with the burgeoning array of techniques and technology available. Today, as we witness the launch of newer frameworks and tools for better web development, on a regular and fast track basis, this domain too has undergone its own super fast makeover! But the core skills to build a solid career in front end engineering has always been the same – passion + HTML + CSS + JS + an unrelenting desire to learn!

Lets analyze and understand the hot and happening technique in the field of front end engineering – ‘CSS preprocessors’, which offers to add mind-blowing features to the Cascading Style sheet language, and equip the modern-day front end engineer with tons of nitro and increase productivity.

What are CSS preprocessors?

A browser can only understand CSS, as the styling technique for any DOM element being rendered. CSS, as a language has its own feature set, which at times might not be enough to create a clean and reusable chunk of rules. Eg. Not being able to reuse a collection of rules in multiple selectors, unavailability of variables which may lead to ambiguous pieces of data across the stylesheet. To overcome most of these limitations, the concept of a preprocessor was born – offering an advanced way of writing CSS, which extends the basic functionalities. This advanced code is later compiled as normal CSS code using respective compilers (which depends on what preprocessor you are using), which the browser will understand.

Should You use Preprocessors?

The decision of adopting preprocessors for your next project, in my opinion, should be made after much analysis and solely depending on your expertise level and most importantly the project requirement and workflow of the team as a whole. Here are some tips that might help you come to a decision:

  • Not for beginners: If you are a beginner and starting to explore the fantastic world of CSS, I would suggest you get your hands dirty with normal CSS before moving into a framework or preprocessor of any sorts. It’s really important to understand and be able to use the core concepts of any language that you work with, and that’s true for CSS as much as any other programming language.
  • Are you a team of front end developers? As a team of front end developers, adopting preprocessors will be a great move. But only if somebody on the team really knows how to handle huge CSS files and structure them accordingly. By making use of the powerful features offered by the language, it is important to first structure the whole CSS into reusable chunks and define a strategy for CSS organization. Eg. Are you going with multiple CSS files for typography, forms, layout etc. Are you going for theme-able UI, where you might need to use variables extensively, etc.
  • Are you willing to cross the barrier? Adopting preprocessors means you are going to be implementing more programming concepts into your CSS coding approach. There will be a lot of concepts that are native to any basic programming language, which you might want to learn and implement, by using a preprocessor. This means, you will definitely need to brush-up your programming skills and might forever change the way you see a CSS code. If you are willing to cross this barrier, and feel ready to embrace the change confidently, this is for you.

Which preprocessors to use?

There are a number of preprocessors available, and deciding which one to stick to depends on a lot of factors. Each of them have their own pluses and minuses, and the final word should be taken after closely considering your project requirements, the team’s ability to adapt to quick and long-term changes in coding approaches.

Listed below are few of the available preprocessors:

  1. LESS
  2. SASS
  3. Turbine
  4. Switch CSS
  5. CSS Cacheer
  6. CSS Preprocessor
  7. DT CSS
  8. Stylus
  9. Compass (built on top of CSS SASS)

In this article, SASS is my preprocessor of choice (since I have been using it intensively for a while, and am truly in love with the technique. In fact it has increased mine and my team’s productivity! ).

How to get started?

Getting started with a preprocessor is not rocket science. As I mentioned earlier, a CSS preprocessor will have its own set of syntax, which finally gets compiled into normal CSS, which in turn, the browser will understand. So, all you need is to choose a way in which you wish the preprocessor to get converted to normal CSS, and then you are good to go!

As far as SASS is concerned, it requires Ruby to be installed in your system, because it was coded using Ruby, and most importantly install the SASS gem, by typing in the following command in your command line or terminal:

gem install sass

There are 3 ways in which a SASS file can be converted to normal CSS, like:

  1. Using command line
  2. As a standalone Ruby module (Ruby on Rails is an open source web framework, which enables millions of programmers worldwide, to create stunning web apps)
  3. As a plugin for Rack-enabled framework (newbie’s, please don’t hurt your brain trying to understand what this means.)

Using command line

This is the most comfortable and easiest way of using CSS SASS. Once Ruby and  the SASS Gem are installed, you need to let the program know which SASS file needs to be converted to CSS, and here is the command for that:

sass input.scss output.css

This command, converts the file input.scss (by the way, .scss is the extension of your SASS based file, which stands for SASSy CSS), to output.css, which is normal stylesheet with good old CSS syntax. But, as a front end engineer, you might not want to execute this command every time you make a change to your SCSS file, as it can become a cumbersome job to do. In that case, you can keep a watch on the SCSS file, and convert the same to normal CSS automatically, whenever there is a change to it, and here is the command for that:

sass –watch input.scss:output.css

As a standalone Ruby module and As a plugin for Rack-enabled framework

I would like to concentrate on the first method of using SASS and am not moving into the other 2 , as the scope of this article is not only confined to setting up SASS. You could refer to http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html, for an in-depth understanding of setting up SASS, and more

With great power comes great responsibilities – the power of SASS

Now that we have decided to go with SASS, and have set it up, its time to spend some time coming up with a strategy and doing some ground work to make sure we are structuring scalable and maintainable CSS. With the powerful features that SASS has to offer, and with a sound knowledge and experience in coding large-scale CSS, we are good to go.

Here are some key features of SASS and concepts, which can get you to a flying start:

  1. @import and modularize
    The first thing to do while starting to code CSS is to finalize the strategy in modularizing the CSS, for example you can decide if you are going to create separate stylesheets for each basic element of the UI, like typography, forms, iconography, buttons, layout, reset etc. Though it is recommended that you use multiple files for the sake of maintainability, it is always a front end engineers call, depending on the ability to smartly group the rules in a single file. SCSS files can be included within another, the same way as you do for CSS, with the following piece of code
    “import style”, where style is the SCSS file to be included
  2. Variables for maintainability
    Variables is one of the revolutionary features that SASS CSS brings to a front-end engineers armory. This feature can add a lot of value to your code, in terms of maintainability, and in cases where you are required to make app wide changes in a single go. Here is how you declare a variable using SASS: “$primary-color:#ccc;”
    Here ‘primary-color’ is the variable name and #ccc, is the color value that is stored in it. You can assign numbers, strings of text, colors, boolean and list of values separated by commas, to a variable.
    It’s important to identify exactly what needs to be converted to variables, for a maintainable SASS file. One can declare all the color values, images and font-family in variables, put all those variables in a single SCSS file, and include it in the main SCSS file. This will bring much more control over the theming of the UI, where we can quickly change the color values, iconography and other parameters which define the general look and feel of the UI.
  3. Mixins improves reusability
    One of the core attributes of a good CSS code is reusability. Identifying reusable patterns across the UI, and creating smart chunks of reusable rules is a skill that every CSS coder should possess. SASS supports this in a big way, through ‘mixins’. Mixins are reusable sets of styles which can be used throughout the stylesheet. Correct usage of mixins can reduce the usage of non-semantic stray classes like ‘border-red’, ‘no-padding’ etc. Here is an example SCSS code:

     @mixin notification {
     padding:10px;
     border-radius:5px;
     font-size:1em;
     }
     .error{
     @include notification;
     background:red;
     color:white;
     }</code>Resulting CSS code:
     <code>
     .error{
     padding:10px;
     border-radius:5px;
     font-size:1em;
     background:red;
     color:white;
     }</code></li>
    <li><span style="font-family: monospace;">

    Here, the first section of code, declares a mixin named ‘notification’, which has a set of 3 rules defined inside. In the second section of code, the selector ‘.error’ reuses the mixin, along-with its own rules. ‘@include’ includes the mixin rules within a selector’s rule sets

  4. @extend reduces redundant rules
    Extend is one of the most beautiful and interesting feature of SASS. This is similar to mixin, but brings a ton of other goodies with it as compared to mixin. Using ‘@extend’ enables a selector to inherit the rules of another selector. Wondering how it is different from a mixin? Watch the following example closely:.error{
    border:solid 1px red;
    background:#fdd;
    }
    .seriousError{
    @extend .error;
    border-width:3px;
    }
    above code will be rendered as CSS, in the following form:.error, .seriousError{
    border:solid 1px red;
    background:#fdd;
    }
    .seriousError{
    border-width:3px;
    }
    effective use of ‘extend’ can bring scalability and flexibility to the code, to a great extend.
  5. More advanced features
    SASS comes loaded with much more features like if, for loops, @debug, @warn, @while etc, which adds a lot of value and productivity to the team, as a whole and makes the stylesheet file modular, scalable and maintainable. I am planning to spend some time for a more detailed article on a step by step tutorial on building a SASS based style-sheet, and will hopefully cover all these features in detail.

Some disadvantages of CSS SASS and other Preprocessors

As with any other technology, to be able to start using a preprocessor, the first thing that one might need is just one thing – PASSION! Everything else follows. But there always is a first step … and here are some hurdles that a designer might face before embracing CSS preprocessing.

  • The terminal / command-line hurdle: since SASS requires quite a little bit of command-line / terminal knowledge, designers might find it difficult to cross this barrier for the first time. But persistence always pays off. With Google and a good internet connection, it’ll be a breeze to overcome it. In this article – Musings on preprocessing, Chris Coyier has covered some tools which are of immense use for designers, to start using SASS, without the hassle of terminal and command-line
  • Since most of the concepts/features are borrowed from programming languages, coding SASS will be a difficult business for designers without much programming exposure. Though it will give some starting blues, it’s not so hard to overcome.

In addition to the hurdles mentioned above, there are quite a few negatives which might affect the performance of the page. I have tried to jote down a few of them below:

  • SASS generates an insanely deep grouping of selectors, if not used wisely, this can put more pressure on the browser rendering engine to try to target the tag, as per the selector mentioned. So, it’s really important to smartly organize and arrange the selectors, so that there is no deep grouping (eg. SASS can generate selectors like .header .subheader .nav.primary .listitem .active .dropdown{color:red; font-size:2em;})
  • The syntax can become a little confusing for a beginner, as SASS uses a nested brace approach to segregate rules, which is much different from the normal CSS syntax (eg. .header{ .subheader{ color:red;}})
  • Due to complex and deep grouping of selectors, specificity nightmares can keep you up at night if not handled sensibly.

The verdict: To SASS or not?

If you are still wondering about saying yes or no to SASS, here are some tips. Get your hands dirty …. and start coding it out, and explore the possibilities. Evaluate the pluses and minuses with your requirements and make sure the team is comfortable embracing it. The transition can be slow, but I believe it’s worth it. In my experience as a team of front end engineers, our hard-work, in ramping up and spending countless hours getting comfortable with this new way of coding CSS, has started paying off, in the form of increased productivity and more maintainable and scalable SCSS files, which will be good for years to come and can easily transition hands seamlessly.

12 Written ArticlesWebsite

A User Experience designer with specialized experience in front-end engineering, i have over time developed a strong passion in being associated with product-based teams. The unified goal and challenges that a product's life cycle offers is simply unbeatable! For me, proficiency in tools takes the back seat when it comes to User Experience Design, and i believe one has to be passionate and equally agile to be a key part of the team. I bring to the table the diverse hands-on experience on various facets of experience design, and have played key roles in the team bridging the gap between design, dev and biz groups within product teams. My vision is to be the key hand behind the UX design of a world-class product in a team of passionate and uber-smart techies and designers! Specialties: Information Architecture, Wireframing, Heuristic Evaluation, Web standards, Interaction design, Semantic markup, OO CSS, Usability Review

8 Comments Best Comments First
  • Tim

    Saturday, June 2nd, 2012 15:39

    2

    If your CSS file is structured properly, there is really no need to use a preprocessor like this. It’s kind of like saying the word blog or weblog. It takes a fraction of a second less time to say blog. Does it really help you talk faster? No. It’s just an extra step and if you use an editor like Espresso/CSSEdit there is even less of a reason to use it.
    I’m sure a ton of developers will love it.
    I also don’t like combining selectors in regular CSS code either, though. WordPress is a perfect example of why I don’t. They have selectors for something as simple as a font strewn throughout 6 different selectors in their code. I want 1 font per 1 selector because 9 times out of 10 I want to change that font in the future with affecting anything else in my CSS. I separate EVERYTHING!

    0
    • Ranjith Kumar

      Sunday, June 3rd, 2012 10:52

      4

      Hi Tim, according to me, implementation of a pre-processor like SASS, should be well thought of, and should purely be based on the requirement. The powerful features that this approach offers, definitely will make the code more organized and flexible, but yeah, using pure CSS also has its own advantages, when it comes to smart grouping of selectors and so on. But If we are making use of the features correctly, this approach clearly has a gr8 advantage over CSS.

      0
  • Caleb M

    Friday, June 1st, 2012 10:33

    1

    Great article. I agree that SASS is a very useful tool for web developers to use to help speed up the development and usability of their websites / code.

    However, there is one problem with using SASS that needs to be overcome very soon. When you are using SASS you have no way to be instantly connected to the changes you are making in the code with a visual editor. Coding with something like Espresso http://macrabbit.com/espresso/ makes web development so much easier. It can turns hours of fiddling around into 2 minutes of quick work. The only way I can get around this problem right now is to test out new code in Firebug and then retype it into my web editor .scss file.

    What are your thoughts on how this problem can be overcome?

    0
    • Ranjith Kumar

      Sunday, June 3rd, 2012 10:47

      3

      Thnx Caleb. One of the initial concern, during our early adoption stages of SASS was debugging the SCSS code. But gradually this was a breeze to be addressed. Actually once we are in full flow in adopting SASS, getting hold of the line numbers while debugging wont be much of a hindrance.
      As far as instant change update, like the one offered by firebug, there should be smarter tools and techniques available, and i hope the time is not far, when this issue is also been addressed well.

      0
  • Rejeesh

    Monday, June 4th, 2012 05:33

    5

    .error{
    border:solid 1px red;
    background:#fdd;
    }
    .seriousError{
    @extend .error;
    border-width:3px;
    }above code will be rendered as CSS, in the following form:.error, .seriousError{
    border:solid 1px red;
    background:#fdd;
    }
    .seriousError{
    border-width:3px;
    }

    In this example, what i understand is:

    .error{
    border:solid 1px red;
    background:#fdd;
    }

    and

    .seriousError{
    @extend .error;
    border-width:3px;
    }

    got the common rules as follows:

    border:solid 1px red;
    background:#fdd;

    which will be rendered to normal css as:

    .error, .seriousError{
    border:solid 1px red;
    background:#fdd;
    }
    .seriousError{
    border-width:3px;
    }

    Is that right brother?

    0
    • Ranjith

      Wednesday, June 6th, 2012 10:39

      6

      Your are right Tyropel :)

      +1
  • Kim Vigsbo

    Friday, June 8th, 2012 08:34

    7

    To make your already great article even better and to ensure you will include people with no knowledge of command-line or Ruby, you should mention (and link to) the growing number of stand-alone applications for both PC and Mac that will compile your Sass (and Less and Stylus) for you without you having to include javascript files or make changes to your build process.

    I have been using Codekit (incident57.com/codekit/) on my Mac for a while and I just started using Compass (compass.handlino.com/) on both my PC and Mac. There are several applications available today for both Mac and PC offering various options.

    To me, having a stand-alone application monitor and automatically (and instantaneous) build my CSS (locally) have made me even more productive. This is especially important to me, since I specialize in mobile-friendly websites (Responsive Design) and each project has its own specific CSS needs.

    0
    • Ranjith

      Sunday, June 10th, 2012 01:19

      8

      Thanx Kim … that was a valuable piece of info. Cheers

      0
  • Kim Vigsbo

    Friday, June 8th, 2012 08:34

    7

    To make your already great article even better and to ensure you will include people with no knowledge of command-line or Ruby, you should mention (and link to) the growing number of stand-alone applications for both PC and Mac that will compile your Sass (and Less and Stylus) for you without you having to include javascript files or make changes to your build process.

    I have been using Codekit (incident57.com/codekit/) on my Mac for a while and I just started using Compass (compass.handlino.com/) on both my PC and Mac. There are several applications available today for both Mac and PC offering various options.

    To me, having a stand-alone application monitor and automatically (and instantaneous) build my CSS (locally) have made me even more productive. This is especially important to me, since I specialize in mobile-friendly websites (Responsive Design) and each project has its own specific CSS needs.

    0
    • Ranjith

      Sunday, June 10th, 2012 01:19

      8

      Thanx Kim … that was a valuable piece of info. Cheers

      0
  • Rejeesh

    Monday, June 4th, 2012 05:33

    5

    .error{
    border:solid 1px red;
    background:#fdd;
    }
    .seriousError{
    @extend .error;
    border-width:3px;
    }above code will be rendered as CSS, in the following form:.error, .seriousError{
    border:solid 1px red;
    background:#fdd;
    }
    .seriousError{
    border-width:3px;
    }

    In this example, what i understand is:

    .error{
    border:solid 1px red;
    background:#fdd;
    }

    and

    .seriousError{
    @extend .error;
    border-width:3px;
    }

    got the common rules as follows:

    border:solid 1px red;
    background:#fdd;

    which will be rendered to normal css as:

    .error, .seriousError{
    border:solid 1px red;
    background:#fdd;
    }
    .seriousError{
    border-width:3px;
    }

    Is that right brother?

    0
    • Ranjith

      Wednesday, June 6th, 2012 10:39

      6

      Your are right Tyropel :)

      +1
  • Tim

    Saturday, June 2nd, 2012 15:39

    2

    If your CSS file is structured properly, there is really no need to use a preprocessor like this. It’s kind of like saying the word blog or weblog. It takes a fraction of a second less time to say blog. Does it really help you talk faster? No. It’s just an extra step and if you use an editor like Espresso/CSSEdit there is even less of a reason to use it.
    I’m sure a ton of developers will love it.
    I also don’t like combining selectors in regular CSS code either, though. WordPress is a perfect example of why I don’t. They have selectors for something as simple as a font strewn throughout 6 different selectors in their code. I want 1 font per 1 selector because 9 times out of 10 I want to change that font in the future with affecting anything else in my CSS. I separate EVERYTHING!

    0
    • Ranjith Kumar

      Sunday, June 3rd, 2012 10:52

      4

      Hi Tim, according to me, implementation of a pre-processor like SASS, should be well thought of, and should purely be based on the requirement. The powerful features that this approach offers, definitely will make the code more organized and flexible, but yeah, using pure CSS also has its own advantages, when it comes to smart grouping of selectors and so on. But If we are making use of the features correctly, this approach clearly has a gr8 advantage over CSS.

      0
  • Caleb M

    Friday, June 1st, 2012 10:33

    1

    Great article. I agree that SASS is a very useful tool for web developers to use to help speed up the development and usability of their websites / code.

    However, there is one problem with using SASS that needs to be overcome very soon. When you are using SASS you have no way to be instantly connected to the changes you are making in the code with a visual editor. Coding with something like Espresso http://macrabbit.com/espresso/ makes web development so much easier. It can turns hours of fiddling around into 2 minutes of quick work. The only way I can get around this problem right now is to test out new code in Firebug and then retype it into my web editor .scss file.

    What are your thoughts on how this problem can be overcome?

    0
    • Ranjith Kumar

      Sunday, June 3rd, 2012 10:47

      3

      Thnx Caleb. One of the initial concern, during our early adoption stages of SASS was debugging the SCSS code. But gradually this was a breeze to be addressed. Actually once we are in full flow in adopting SASS, getting hold of the line numbers while debugging wont be much of a hindrance.
      As far as instant change update, like the one offered by firebug, there should be smarter tools and techniques available, and i hope the time is not far, when this issue is also been addressed well.

      0

Comments are closed.

107.20.121.254 - unknown - unknown - US