Total Followers 132,503
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.
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.
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:
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:
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! ).
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:
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
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
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:
@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
.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.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.
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:
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.
Get The Only Freelancer crash course you will ever need to read!
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
Friday, June 8th, 2012 08:34
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.
Sunday, June 10th, 2012 01:19
Thanx Kim … that was a valuable piece of info. Cheers
Monday, June 4th, 2012 05:33
.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?
Wednesday, June 6th, 2012 10:39
Your are right Tyropel :)
Saturday, June 2nd, 2012 15:39
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!
Sunday, June 3rd, 2012 10:52
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.
Friday, June 1st, 2012 10:33
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?
Sunday, June 3rd, 2012 10:47
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.
Get The Only Freelancer crash course you will ever need!
If not, then it's time to learn how to:
You can trust 1stWebDesigner to help you become a better web designer!
- Jacob Cass | Just Creative
Just enter your name and email below and click Get Updates!
![Basic Web Design Video Course – Complete HTML Markup & CSS Styles [Part 3]](http://www.1stwebdesigner.com/wp-content/uploads/2013/03/preview-small-webdesignvideocoursepart3.jpg "Basic Web Design Video Course – Complete HTML Markup & CSS Styles [Part 3]")
![Basic Web Design Video Course – Basic HTML Tags, Structure & CSS [Part 2]](http://www.1stwebdesigner.com/wp-content/uploads/2013/03/preview-small-basicwebdesignvideocoursepart2.jpg "Basic Web Design Video Course – Basic HTML Tags, Structure & CSS [Part 2]")
Caleb M
Friday, June 1st, 2012 10:33
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?
Ranjith Kumar
Sunday, June 3rd, 2012 10:47
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.
Tim
Saturday, June 2nd, 2012 15:39
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!
Ranjith Kumar
Sunday, June 3rd, 2012 10:52
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.
Rejeesh
Monday, June 4th, 2012 05:33
.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?
Ranjith
Wednesday, June 6th, 2012 10:39
Your are right Tyropel :)
Kim Vigsbo
Friday, June 8th, 2012 08:34
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.
Ranjith
Sunday, June 10th, 2012 01:19
Thanx Kim … that was a valuable piece of info. Cheers