What are CSS preprocessors, why do we use a CSS preprocessors, how to use a CSS preprocessor and which CSS preprocessors are being used by front-end development experts?
- CSS preprocessors introduction;
- What are CSS preprocessors;
- The 5 best CSS preprocessors (according to 61 experts);
- Why use a CSS preprocessor? (advantages and disadvantages);
- How to use CSS preprocessors;
- CSS preprocessors used by 61 front-end development experts.
1. Where it all began
The history of HTML
At the start of the Internet there was only text (HTML 1.0). Some years later HTML 2.0 signified the introduction of images. At that stage designing a website was still very restricted to basic features and adding columns for example was even almost impossible. The introduction of HTML 3.0 (an HTML version which has never been officially released) meant a world of difference because tables were introduced for the first time. The objective of tables was to present data in a clear and ordered way.
Soon developers noticed creating a table in a table and again in another table (and so on), a website could be developed by means of various sections providing the developers a website lay-out control. It laid the true foundation of website development. The true web designer was born after the introduction of HTML 3.2 because it became possible to add and use different backgrounds, colors, various font sizes and several styles to your website which for the first time prioritized the actual website’s presentation.
The large number of different CSS properties opens a new world of CSS opportunities. Besides the website’s layout, various HTML elements can be styled separately. Therefore CSS documents consist and consisted often of thousands lines of coding, whereby major part of the coding is overlapping. The well-known DRY principle (Don’t repeat yourself) isn’t really applicable to CSS. To ease, fasten and clarify the CSS development and to ensure developers don’t have to rewrite the same CSS twice, CSS preprocessors were developed. A CSS preprocessor should be considered a layer in between the different style sheets which are managed and the CSS files which are served to the browser.
In order to allow you to present and share this article in an easy, clear and proper way we have also created an infographic, a powerpoint presentation and a .PDF file. Click below on the item(s) you want to view or download and use it on your website, blog, college, course, et cetera. All 3 items are free to use.
2. What are CSS preprocessors?
CSS preprocessors are also referred to as being ‘dynamic style sheet languages’. They have been developed to add a programming functionality to the editing of Cascading Style Sheets. CSS Preprocessors convert code into a true CSS by taking the same written code from a simple preprocessed language (CSS with added extensions). Besides CSS preprocessors are used to add extensions which aren’t used in CSS yet like: functions, mixins, nested rules, variables, operations and inheritance.
Variables allow you to store strings which will be reused various times. They form a reference in your stylesheet to the specific string. Although named variables it would make more sense to refer to them as being constants. The value of variables namely is expected to be a constant value which doesn’t change over the course of your stylesheets. Variables are mainly used to store aspects like width, colors, font size and so on.
We do not only like variables but we also highly appreciate the use and existence of preprocessor nesting. Taking into account the DRY principle (Don’t repeat yourself) nesting is highly advisable to be used with preprocessors. Although its main objective isn’t saving you time, nesting is still used because it gives you a clean code. Code is often spoilt because developers add new rules when developing a CSS. Nesting makes sure your code is tidy and neat at all times.
Mixins are often defined as being CSS declarations which have been added to reusable sets and which often contain parameters. These sets can then be used to be included in or mixed into other rules. Mixins are preferably used with huge parts of vendor prefix styling. Mixins are reusable sets of CSS declarations that you can include or "mix in" to other rules. Mixins are good for large chunks of vendor prefix styling. In practice a mixin is called from within a CSS selector after which, when the mixin is recognized, the styles which are defined within the mixin will be applied to the selector.
To add, multiply, subtract and divide specific values and colors, operations are used. As well LESS ad Sass can perform these mathematical commands. We prefer Sass though because it acts in a smarter way by excluding incompatible functionalities like % and px from the mathematical calculation. When confronted with these units a syntax error is displayed.
Integrated programming functions form a vital part of several CSS Preprocessors. Functions that often occur are amongst others: math functions, unit conversion, string functions and list functions.
3. Common CSS preprocessors
Many websites can be found which contain lists of available CSS preprocessors. These lists might seem handy but honestly they aren’t at all because when looking for a suitable CSS preprocessor you would still have to test the CSS preprocessors one by one which is a very time-consuming exercise. To tackle this issue we have asked various front-end developers to inform us about their preferred CSS preprocessor and we have asked them to justify their CSS preprocessor choice.
What is the best CSS preprocessor?
To find out which CSS preprocessors are a must have, we asked 61 developers the following question::
Do you use a CSS preprocessor(s)? E.g. Less, Sass, Scss, Stylus, etc. Can you please motivate your answer?
The 5 best CSS preprocessors
According to 61 front-end development experts
Would you like to know why our experts have opted for the above CSS preprocessors? Click here or scroll down to read the arguments of the front-end development experts.
4. Why use a CSS preprocessor?
More and more front-end developers get acknowledged with CSS preprocessors. Using CSS preprocessors has many advantages but also some disadvantages. According to the specific project we will opt for plain core vanilla CSS or for a CSS preprocessor.
CSS preprocessor advantages
One of the main advantages of CSS Preprocessors is the fact they enhance CSS use and make it more flexible by using programming abstraction and logic. CSS preprocessors make sure your CSS contains all items which should be in there and they feel very strongly about the DRY (Don’t repeat yourself) principle whereby code is only written once and the same code is reused whenever required. This avoids the time-consuming task to rewrite the same code time after time and it will also increase the logic and clarity of your CSS by making it clean and tidy. Let’s say you would for example like to change a font size… you would only have to change it in one location instead of browsing through your whole CSS project to make the changes where required.
Two other advantages are the fact CSS preprocessors can be written and set-up quite easily (Probably easier than the word sounds) and the fact you always maintain a well-structured and organized CSS.
CSS preprocessor disadvantages
It might not sound as a true disadvantage but nevertheless it is. Because CSS preprocessors are easy to use one tends to copy code or even to drop code and to use the same format in the whole CSS project. Duplication therefore is almost unavoidable. Nevertheless we would like to discourage duplication when using CSS preprocessors.
CSS preprocessors might form an issue when not everyone is informed of their use at the start of a project. If a designer with which wasn’t part of the project at the start decides to change the CSS the whole system might fall down. Therefore proper version control is of crucial importance when using CSS preprocessors.
People which are used to work in a live environment will have to change their way of working because when using CSS preprocessors the intent is to start working locally and to deploy the project to a live environment at a later stage.
The file size might sometimes be deceiving. People often forget the high-level style language they are writing is smaller than the CSS that will be generated. Therefore they also tend to forget that the final CSS might have a much bigger file size. It’s not always an issue but it could be. There are several tricks though, like removing an image, to tackle this file size issue.
5. How to use CSS preprocessors
Many people prefer setting it up on their personal computer because this way a CSS file is created which is ready to be uploaded next to the SCSS file. It is important to take into account when working locally both the SCSS file and the corresponding CSS are kept together at all times. If you delete the CSS, you have to delete the SCSS file. The same goes for uploading or downloading them. Never perform an action for one file without performing the same action for the other file. (Besides when you would use git, don’t forget to add the CSS files to .gitignore.)
For some technical workplaces a preprocessor is already installed on the server. If that’s the case it means your conversion will take place after uploading your files, not before uploading them. It might be useful to check this before using CSS preprocessors.
Use your text editor
When working in a local environment your SCSS file should be watched at all times and you should use a tool to make sure that when you save your file, the SCSS is also turned into the corresponding CSS.
Doesn’t your text editor support CSS preprocessors?
Tools like Dreamweaver, BBEdit or some other text editors don’t have a so-called SCSS plugin or add-on. This shouldn’t be too big an issue though because one could consider using a command line or one could opt for an app which watches your SCSS files at all times. Various applications are available to perform this task for you. The most popular and most commonly used ones are undeniably Koala (free), CodeKit ($29) and LiveReload ($9.99).
6. CSS preprocessors used by 61 front-end development experts
Many websites can be found which contain lists of available CSS preprocessors. These lists might seem handy but honestly they aren’t at all because when looking for a suitable CSS preprocessor they won’t be of real use because you would still have to test them one by one which is a time-consuming exercise. To tackle this issue we have asked various front-end developers to inform us about their preferred CSS preprocessor and we have asked them to justify their CSS preprocessor choice. We asked 61 developers the following question:
Do you use a CSS preprocessor(s)? E.g. Less, Sass, Scss, Stylus, etc. Can you please motivate your answer?
We hope our research might ease your quest for an appropriate CSS preprocessor and you will be able to use your CSS preprocessor soon to avoid time-consuming tasks and efforts.
The 61 developers
Please find below an alphabetically ordered list of all developers who have been part of our research with regards to the CSS preprocessors. Clicking on a name will automatically direct you to the final choice and the justification of that particular person. We would recommend you to click several names and to read all justifications before making your final choice.
The 61 developers and their choice and arguments
Please find below a list of the different CSS preprocessors which are used by the various front-end development experts and their corresponding arguments. The developers’ feedback has been ordered chronologically:
Sometimes I use Sass. It's a useful tool for writing CSS. It's particular handy to be able to work on multiple separate files that are then concatenated. Variables and mixins are quite useful too.
But it's important to realise that pre-processors are a means to an end. And that end is writing good CSS.
We use SCSS. It’s the default preprocessor in Rails. Just enough sugar on top of CSS without straying too far.
A very simple answer for me. Only Sass, using the SCSS syntax :-) And that's it. It's just "CSS but better" for me and that's all I need.
I use Sass as my preprocessor. That choice was mostly dictated by the tech stack of the company that I work at but seeing it turn into the industry leader, it’d likely be the one I’d choose now even on my own projects.
Using Sass (scss) for preprocessing css is like having developer super powers. One of the best things for someone using Sass for the first time is that you don't need to learn or do anything different. It will work perfectly with regular old css. The big advantage with using it, however, is that it can help speed up your workflow, minimize your css payload and help to better organize your output.
The primary advantages I find with using Sass are global variables, mixins, extends, css organization, and nesting (done correctly).
Global css variables are amazing. For example, you can set your color, font, padding variables in a 'variables' file. From there, you can declare these variables throughout your stylesheets. That way, should you decide to change your primary color, for example, you only need to do so in one place and it automatically cascades throughout your project.
Mixins are another super useful component of using Sass. You can think of mixins as kind of like css functions. As Sass compiles, wherever these functions are declared they run, ouputting your desired css. Whenever looking for Sass resources, I recommend seeking the writings of the Sass master Hugo Giraudel. On mixins, he has written a nice article to get you started: http://www.sitepoint.com/sass-mixins-kickstart-project/.
Extends are base classes you can use throughout your project. The can be very useful (used correctly). For example, you can have an extend '%btn-primary' and use those styles on classes throughout your project by using @extend %btn-primary. This can be particularly useful with classes you don't want to populate your css file, but want to have access to when you need them - like grid styles.
CSS organization is huge. There a few different philosophies on how to do it exactly, but having the ability to group your css into bite-sized files makes maintenance and organization a snap. Instead of styling one huge css file, you now have small files based on structure, components, layout, whatever where you can easily find and modify. When you compile, Sass will pull all these files into a single css file and, depending on the tool you use to compile, output a minified version. Again, here is a link from Hugo: http://www.sitepoint.com/architecture-sass-project/.
Finally, there is nesting. Withs Sass, you can nest classes within a primary class. This can help keep your css organized and limit the need to use parent and/or repeating selectors. Limit nesting, however. Limit it to three levels as Chris Coyier points out in his Sass style guide: http://css-tricks.com/sass-style-guide/. One of the best uses I've found for nesting has been made available in the latest Sass release that better enambles BEM organization.
There are a few other notes when using Sass. First, you will need a tool to compile. I use Grunt, but there are others such as CodeKit and Gulp. Also, there are helper frameworks that have built in mixins and other resources that can help make your Sass expereince a little easier. The most popular are Compass and Burbon. I don't recommend using these tools to do your vendor prefixing, however. If you use something like Grunt, I recommend using autoprefixer for that.
If you aren't already using Sass, start using it today! You will be glad you did.
To recall why I started using a preprocessor I need to go back at least 3 years (which in web development time is equivalent to an era). Back then web perf was starting to gain major attention. I had just learnt that in order to avoid lots of HTTP requests it was better to keep CSS in one file and in order to reduce the size of the stylesheet it was preferable to minify its contents. But while I was trying to optimise the performance of my web sites I was also keen to optimise my workflow. That's where using a preprocessor came in. Initially I was tempted by LESS, which took a similar approach to the sorts of solutions I had been concocting using PHP, but after a thorough analysis of the options I settled on Sass for its strong community and deeper set of features.
As I've grown as a web developer I've found countless more uses for Sass beyond those that initially drew me to it. In particular, Sass has opened up new ways for sharing code - something that other programming communities have long flourished from but has never been possible with CSS (there really are very few snippets of CSS that can be used across aesthetically different projects). I've loved being able to create configurable plugins (like Tractile) and package up library or framework like projects as Ruby Gems, which other developers can then easily install (such as Chameleon and Variant).
But ultimately preprocessors do one thing: they generate CSS. Too often developers are caught learning how to use a preprocessor but failing to give consideration to the code it is producing. This approach is worse than using no preprocessor at all! The most important decision a developer can make then is not their choice of preprocessor but to gain a better understanding of CSS.
I have to work with multiple preprocessors like Less or Sass, depending on the project and client.
However, I like to use Sass for my own. Sass is fantastic, apart from its great preprocessor features, its frequently updated, clean and has a massive community behind it.
I do indeed use a CSS processor. I use SCSS and a small front-end base project that I created (https://github.com/4ndeh/base-front-end-project).
I've been using CSS preprocessors for a while and I'm in love! I published a sample start project pure Sass, where I put some functions, mixins, colors and a responsive grid system.
I use SCSS in all my projects, no matter they’re big or small. From all the tools and languages we use as fronted practitioners on a daily basis, it is fair to say that CSS is the one that less attention and evolution had featured over the past decade. While CSS3 supposed a remarkable leap compared to CSS2 and turned into an unparalleled window of opportunity to do things in a different way, browser support has always been a big issue when styling documents and we frontenders ended up more focused on cross-browser compatibility rather than creating decent workflows and reusable functionality blocks on top of the styling tool, this is CSS. Yeah, we had all those grid systems and reset stylesheets here and there, but all of them just served to patch the problem and eventually turned into adding more boilerplate than providing an actual aid in order to make the styling process smoother and, let’s say, more agile.
Then it came LESS and SASS and everything changed: Now we can not only focus on beautifying our HTML documents, but on setting up workflows that other colleagues can share and improve, we can reuse code paying more attention to functionality rather than the final outcome of it, modularizing code has become easier than ever and the use of mixins, variables and functions make code refactoring a breeze. Off course the dev will want to pay attention to good practices and leveraging these tools won’t reduce the risk of producing bad code, but at least mitigates the need to replicate it or maintain the code base in the future.
One of the things that got me sold was the extreme easiness of supporting CSS preprocessors on any project, both big and small. Either by leveraging the CLI or by implementing any of the plugins out there in our automation script (I mostly use Gulp) or IDE, compiling the build code or distributing applications was even easier than ever, and the fact of harnessing the power of SASS or SCSS does not add any overhead to the project. Indeed, I use it even for my smaller 1-page projects as well. Ultimately for me the workflow is the only thing that matters in order to get the job done and CSS preprocessors have lots to say in regards of this.
I actually do use Sass. It makes me more productive, which is never a bad thing. My favorite features are probably nesting and variables. In bigger projects I tend to use plain CSS, because sometimes it gets little bloated and harder to manage with Sass.
I started using a preprocessor (LESS) years ago just to deal with vendor prefixes. Now its kind of the opposite.
I moved to Sass and Compass, but it was really the partials and breaking up your styles into 20 pieces that has the most benefit. Mixins are super useful, variables are great, but partials the best—incredible for organization and sanity. Just imagining those massive 2000+ line style files from the 00's makes me sick.
Most recently, I moved to Autoprefixer postprocessing to handle prefixes. I almost never nest rules because I follow a BEMish ideology. I actually use very few of the features of preprocessors (except in my grid generator) —mostly a breakpoint mixin, partials, and a handful of variables. But I could never go back to old CSS.
Yes, I use CSS preprocessors. Mostly I use sass because of its bunch of features. I love to create my own mixins per project, to DRY my code and to control whole projects with variables. Also it's pretty neat to split up you own CSS into modules, so that everything's structured and easy to edit. It's important that other frontend devs can read my code and structure.
Some years ago I started with Less, which was pretty cool and new to me when I started to read and learn more about preprocessors.
I use any CSS preprocessor in combination with gulp/Grunt.
If you asked me that, two or three years ago, I think I would have answer you: No! And I would have add, I’d rather die than using a CSS prepros :) I’m kidding, but at that time I was not convinced by them. The main reason, except the fact that changing habits is always hard for a human being, was the lack of explanations of the real benefits.
Until the day I had to work on a large scale project… On that long project, I had to work with a dev team, and asked to use sass as a preprocessor. That, combined with smacss naming conventions and architecture. If a bit painful in the beginning, coding my css with sass became a pleasure as time goes by.
The possibility of using variables, avoiding repetitions via mixins, etc was a real concrete addition and simplification in my job. Which included working on complex and multiple pages (it was an ecommerce website). To that, I would add that I started using sass when you could write it like Stylus today (with no brackets, semi-colon, etc). And THAT was cool. Cool, because the code was more readable like this, and you had a better view on indentation/deepness, etc. Moreover, that was a great gain of time. You can still write it like that today, but the sass documentation is more .scss oriented.
Nonetheless, it's still possible to survive without css prepros. The whole thing is useful, but I don't use it ALL the time. For small sites for example, I still use "vanilla" css, and it works perfectly :) Sometimes, create two files (.html, and .css) is quicker than setting a whole architecture with separated files and a bunch of tools.
The whole preprocessors thing is, in my opinion, also a matter of hype. And something that is sometimes used as a miraculous solution. BUT, the fact is that without the basics and the logic, it's easy to make worth than good.
In the end, all is a matter of personal choices and reflection. Use the tool with whom you feel more comfortable and that fits your needs, and most of all know when to use it.
Started with less because of bootstrap. Moved to Sass with bourbon when I left bootstrap. Now using stylus because of a new job.
I use Sass, and although I only use a very small and specific subset of its features—simplicity is always paramount, and removing the number of moving parts in a system is a good way of keeping that in check—I would never choose to work without it.
I frequently get asked by clients and workshop- and conference-attendees why I chose Sass over LESS. The simple answer is down to Sass’ first-to-market advantage: Sass appeared first, so spent a lot of time being more fully-featured and advanced. When it came down to me choosing which preprocessor to use, there was no question; Sass was clearly just a lot, lot better than the competitors at the time.
To add to that, in the time competitors spent catching up, Sass grew a much, much greater community. There are more tutorials, articles, and conferences about Sass than any other preprocessors.
To compound things even further, Sass now has plenty of ports into different languages, so you can use it in almost any stack. It seems to have spent a lot of its time being ahead of the curve.
I'm not using a preprocessor, simple reasons are:
- Usually my personal or our team's projects ( I work both freelance and in a company ) don't scale that much to actually benefit from the use of a preprocessor.
- We are a team of 4 developers, some are more back-end oriented and some more front-end ( like me ). But many times more than one person have to involve in a single project, or even provide support after the finish, and they don't all have the same skills. So using a preprocessor would make things more "difficult" for some.
Personally I've been tempted many times to use one, I've tested them but not in a production site. If I would, that would be Sass, and of course for the simple benefits of color variables, vendor prefixes etc. But overall I haven't had a problem writing maintainable css even for large websites.
I am using Sass (Scss syntax) with Compass for vendors prefixes.
Why a Preprocessor?
- Because variables: First reason, no need a huge search & replace to change colors;
- Because nesting: No need to repeat yourself;
- Because automatisation: loop, mixins;
- Because multiple files: CSS file can be very long so @import components/buttons.
- Because it is CSS;
- No need to learn an another language: just features;
- You can easily convert CSS files by just changing the extention '.scss';
- You can @import css file and @extend classes (for example adding bootstrap.css file and @extend .btn class).
- Because the community is huge and the project is maintain (not the case for less I heard);
- Because it is well documented.
I use Scss in all my project with Gulp.
I’m currently working with Grunt and Less. I think it allows you to access to a more advanced CSS than the basic one. It’s really cool on huge projects and it makes you save a lot of time.
Grunt also allows you to create some other tasks to help your CSS be more efficient and optimised, you could for example use a minifier task.
Yes, I'm using Sass. I used to use Less, but noticed that it's less develop from Sass. Also I like the integration between Sass and other products and plugins such as Webstorm, Grunt, Sublime, and more.
Sass/Scss is my preprocessor of choice! I refuse to start a project without it now.
Aspects like Mixins make starting from scratch so much easier, no need to write out lots of browser prefixes for things like border-radius etc. Another thing I love about Sass is variables, before I started to use Sass I always thought the idea of variables in CSS was outrageous but now, I don’t think I have a project without them, so useful for defining brand colours and fonts etc.
The most obvious reason why I use a preprocessor is the ability to nest selectors, so so useful. Being able to nest child selectors within their parents is really handy, saves you from having to write really long lines of code. Whenever I do end up having to work on CSS files without nesting it just looks so messy.
I use SCSS. The beauty of it is at the core, it's just normal CSS and scales to become as complicated or simplistic as you want.
I often use the placeholder functionality to roll little utility nuggets like negating user selection, text rendering optimizations, etc. You also have the option of writing custom helper functions in Ruby that enable very interesting scenarios like analyzing a background color and providing an appropriate text compliment.
I use Sass for all of my projects. In addition, I like to use Bourbon to speed up my workflow.
I started using Sass (scss format) about 3 years ago. Chris Coyier (@chriscoyier) had a lot of great things to say about it so I decided to "kick the tires." I started experimenting on a personal project and then dived in full force on work project. Sass is a great tool that helps me to organize my stylesheets and make development faster.
Here are some of the things I really like about it:
- Variables - one of the best features is that I can define a variables elements and then use that "shorthand" as I am writing my stylesheets. I use variables to define colors, font stacks, and breakpoints;
- Nested Media Queries - I like being able to nest media queries on different elements. It helps me to keep everything organized and to be able to see the changes to an element across the different breakpoints;
- Modular architecture - I use placeholders and mixins to define elements for a modular approach to my CSS. Instead of adding classes to HTML, I like defining things in Sass. It leads to easier maintenance of my HTML and keeps the workflow for styles in the stylesheets.
Less, because it is intuitive and also is the engine inside Twitter Bootstrap. So if you want to edit Bootstrap CSS you edit using Less.
I'm used to work with scss with grunt (watch) as task runner. It's awesome, fast and makes me save a lot time when developing stuff! I think that nowadays it's an essential tool for front-end developers. Everyone should (maybe must) give it a chance.
I do use preprocessors, I use sass and less. The main reason people should use them is because they speed up development and they add extra features to css. If you only learn how to use variables and nesting, that alone can save you a lot of time. I prefer sass over less, but they are pretty close. Usually, you pick a preprocessor based on what your team knows or if you are using a framework. If you use a framework, you use the one that framework has picked. Once you know one preprocessor, moving to another one is pretty easy.
I discovered Less at some point, shortly after having built a couple of custom commands for TextMate that allowed me to use variables in CSS, using almost the same syntax as has later been proposed by W3C...
What I like so much about CodeKit is that it's a single app that brings everything I need to develop webpages. CodeKit watches the files and recompiles on the fly - it has a built-in webserver and when I save a Less file, it refreshes the CSS live, and animates (whenever possible) the changes so they're easily noticed!
What I like about Less is probably what people generally like about a CSS preprocessor, but here goes:
- That I can use variables/constants;
- That I can nest rules where it makes sense;
- That I can create mixins - A: for reusing code, and B: to make the code much more readable (e.g., having one line that just says `.toggleable();` instead of 8 lines of `display: none;` and various hacks to make it all work);
- That I can split my code into umpteen files and still only serve a single, compiled CSS file from the server without having to set up any Grunting/Gulping or similar noisy animals. :-)
Yes I do - I’m on the SCSS train for about a year now. It actually made writing stylesheets fun again. I think there is no reason to not use a CSS Preprocessor language since the entry barrier is low and the amount of extra features one can use flexible and optional. I got used to the major features such as nesting, variables, extends or mixins with conditionals etc. and can’t image for a second going back to plain old CSS.
Well, I use them, less and sass (sass mostly) and sometimes compass.
I found them very useful, especially on big projects like e-commerce websites and massive web apps where I need to write really stable and reusable code and don't want to spend lot of time on correcting my css after project is finished, and in later maintenance of code.
They are good tool to have under your belt, and can really help you in writing clean and concise code, and best thing of all is, it's fun, especially with all of that features (variables, mixins ...) that allows you to do much with less code, but you need to be very careful to not overuse them, because you can quickly create a lot of mess.
Yeah, I use Sass for Css3 and Coffee for JS. Stylus is good if you work with Jade project. SCSS and Less its basicly same, but I prefer Sass, it's more clean and powerfull.
Yes I use my own Less compiler to integrate CSS/PHP/WP projects. MoreLess (Class) was written three years ago, and never released to public.
I use Sass. The main things I like that Sass helps me with are the ability to modularize code into separate files, nest media queries, variables for colors and breakpoints, and combine/concatenate a minified stylesheet for production.
I use LESS as a CSS preprocessor. I use it independently from the app I'm building, so as not to affect load time, and I like it because it's closest to vanilla CSS. This way, if you find yourself in a situation where you have to fix something in pure CSS, you haven't forgotten how to do so, by working in LESS.
In general, I'm a big fan of preprocessors. They allow you to programmatically style your site or app, and they make writing clean, DRY, Object-Oriented CSS much easier.
I have surrendered to SCSS …it has the best tooling support (including Chrome) and the most devs using it. I *really* like the others too and have zero qualms about them.
Yes, I have been using CSS preprocessors from 2009 on all of my larger projects. It all started in 2009, while I was working on huge tourism accomodation agency project. I encountered standard issues, bunch of repeated elements, need for "functions" and math actions. First touch was with XCSS which was discountinued and then later on LESS (which I'm still sticking to in most of my projects) and SASS.
I think that reusability, ability to create your own small "barebones" of projects, customized mixins and functions is awesome. Since all of the code is open, ability to add more code as libraries (mixing predefined templates) is making us learn and code better. We still need to be careful. Preprocessors can create a bad habit of code-cluttering if we do not control output.
I'm using SASS and COMPASS this makes the work easier. I'm enjoying sassy code on RoR projects because rails compile the code on the runtime this is so pretty. On other projects like php project i'm using koala a free sass compilor it's fast and lightweight. Also if someone work on responsive web site he can create his own mixins like the popular example of @respond mixin this is the best way to make easy to edit and understand code.
I should use CSS preprocessor more but sometimes it is faster to code without a preprocessor on smaller project. I do not know much about the other ones but SASS is very easy to learn and really efficient, it is a great tool to use and I will definitely use it more in the near futur.
For most work at my day job, I don’t use a preprocessor, but that’s not by choice, it’s just the conversion process of a large web app code base takes time and I haven’t had enough to fully do so.
But for new side projects at work and any projects outside of work? I always use a preprocessor theese days, Sass in particular, and I write with the Scss variant. I like writing that way because there’s not a big mental shift away from writing traditional css - if I want to write traditional CSS at any time, or port over older code, I can, without a problem.
About the only downside with Sass in the way I run it can be of course compile time, but because I run libsass, gulp-sass in particular, I find that’s pretty damn fast. Also sometimes my sourcemaps don’t match up perfectly for devtools debugging, but that’s not the end of the world.
Overall, the benefits of preprocessors are huge: mixins, and variables alone are life savers for things like colors, break points and the like. Hope that helps.
Yes, I use a preprocessor. For the last several years, I have been using Sass. The biggest advantage I find is being able to break down my CSS into manageable sections/components with partials. Ultimately, a preprocessor allows me to write less code and take advantage of addons like Compass and Susy grids.
Only work with pre-processors with less and sass. After using can quote improvement in productivity, time saving and bites economy, ease to work with components. In short: quality of life. Today I write very little code, I can write the move organized and clean. Duplicate lines without rewriting code.
Yes I use sass and scss mostly around all my projects, and in them Scss mostly. But I like sass because of the neat CSS generation.
I don't use any of those preprocessors, because I just like vanilla CSS. It's one of the most simple and powerful language, I don't see any need for more complications to add. This is the first reason.
The second one, is the fact that once you started a project with those tools, only people who also use those tools can understand and work on your project, because it's not CSS anymore. Reading a Sass files you didn't write it's like reading a language you don't know, it's very hard. People could reply to that reason by saying "yeah but you need to learn to work with those tools", no we don't. Learning and mastering CSS is only thing we need to do. Be an expert at it, is the goal, because this is all we need in our job. Nothing more. Preprocessors could be very useful, I admit that, but the cons are bigger than the pros in my opinion.
Front-end developers can use every tools they want, but no one has the rights to impose a tool as standard for everyone.
Yes, I do use a CSS processor. I use Sass.
Preprocessors are an easy and powerful way of writing maintenance and modular code. Things like mixins and variables are extremely useful. The simplest example is: imagine you need to change a color. Without a preprocessor you need to find and replace each and every instance where the color is used, but with a variable you just need to change its value and you're done. Fast and simple.
Sass is so awesome that I can't go back to the way I used to write CSS anymore.
So far I'm a big fan of using sass in my workflow.
- @mixins,@extend. variables, partials are super powerful features that sass has to offer;
- You can run normal css within it;
- Largest community behind it;
- Get reason to start working with Command Line or Terminal.
I should say Yes. I always use preprocessor(s). But let explain how I started. At first I start learning Less. That was cool. I could wrote better and more modular css code and readable nested block. Then I heard something about sass. So I google about that and done something with it, like Simptip and Norouz egg. Sass is a nice tool for front-end developers who likes follow web trends. These tools were start point for me to follow other things like Compass, Bourbon and etc. I think this is the way for who wants to become an modern developer.
SCSS is my preprocessor of choice for CSS. Less and Stylus are great alternatives. All three tools keep my code modular and DRY. Debugging code is easy with the built-in error handling these tools provide.
Modules keep my stylesheets portable and reusable. They ensure DRY code that scales well as the project grows. I can even reuse common modules across different projects, reducing my development time by a factor of 10!
Debugging SCSS, Less and Stylus files are much faster than debugging CSS. The build-in error reporting notifies me instantly if I forget a closing bracket or semi-colon. Stylus and Sass do away entirely with brackets and semi-colons, relying instead on indentation and whitespace.
All three flavors of preprocessor are great and I highly recommend you become familiar with at least one. The preprocessor you choose depends on your comfort with whitespace-sensitive programming languages (think Ruby or CoffeeScript) and the your existing development environment.
Most preprocessors are too bloaty for my needs. I prefer Rework where I can choose only the features I need through its plugins.
For projects I normally use Scss mainly because its cleaner, your code is organized and it lets you use variables and mixins. To compile the Scss files I use CodeKit because it has autoprefixer built in. Overall, using a preprocessor saves me time writing the CSS.
At work (and many of my personal products) I love using SCSS. It is super easy to take an existing project written without a pre-processor and add some magic since there is no conversion needed. CSS is valid SCSS.
LESS is fine, I think I came to the preprocessor game a little too late to get much use out of it. I feel its aged a bit. SASS is awesome if you do Ruby, Python, or CoffeeScript—I do neither, so it feels a little alien to me and prefer SCSS over 'pure' sass. Stylus is great too, I used it in a client project a few months ago. It feels exactly like SCSS in day to day use, so I am not able to provide an in-depth opinion, but I did not mind it at all.
As far as using these processors, I love Bryan Jone's CodeKit for simpler projects. Once I get into heavier projects, I tend to switch to a gulp workflow.
I use Sass, and I used Less at my previous job. Initially I was reluctant to use a CSS preprocessor, as I liked the direct control that writing CSS directly afforded me. But in reality, CSS preprocessors are so helpful, they can be huge time saver. It also allows us to structure our files how we like, create re-usable variables and mixins, and generally makes our styles much more readable and maintainable. The compiled output is getting better all the time, and is pretty good already.
I currently use SASS/SCSS for a majority of my projects for it's amazing variable and mixin support. It makes it extremely easy to manage a vast array of colors or repetitive coding when it comes to things like vendor prefixes or other snippits. Of course, the flexibility and resourcefulness expands far beyond just that, but those are my main reasons for sticking to SASS/SCSS.
Each CSS preprocessor (Sass, LESS, and Stylus) has its own unique way of accomplishing the same task... add functionality to CSS (mixins, variables, nested rules, and more), they makes the code dry and easier to maintain, and while not a requirement for development, preprocessors can save a lot of time.
Back to the question, YES I use them and I encourage you all to try as many preprocessors as possible, you will not regret :). Stylus has a syntax very attractive but, I think that Sass with Compass is better on a whole bunch of different fronts, like media queries, @extent concept and especially loops logic with no guard mixins like LESS just solid programming and you'll get what you need, vendor prefixes included.
In the most crotchety old man voice I can muster up. No! I follow the actual spec! Because when things go wrong, I want only one absurdly complicated spec to read, comprehend, and implement.
My answer is kind of bias because I'm one of the co-organizers of SassConf. But I like using scss because of the ability to include regular CSS with the power of Sass.
What separates Sass from the rest is the community and the features. The features that I like the most is SUSY and source maps. SUSY is a layout framework that can create symmetric and asymmetric grid systems. Source maps is a feature where that the developer can use to find pre compiled CSS (aka see scss) while using the inspector element within the browser. This will help you find what variables, mixins and/or extends your components are using. They are many other features that I enjoy using....but that can by another post.
I'm definitely using Sass for all of my project with the Scss syntax. I can't image going back and write regular stylesheets before.
I don't use CSS preprocessors. I try not to create heavy CSS styles for fast loading pages.
I use CSS all the time, I really just don't have much of an opinion! I tend to keep things simple on my own, but then don't mind using a preprocessor when the project I'm on is using one.
Last, but certainly not least..
Tiffany B. BrownWebsite
I use Sass/SCSS. I resisted using a preprocessor for several years because it just seemed like a lot of additional overhead for marginal gain. Then I accepted some contract work with a team that used SCSS. So I stopped trying to fight it. Realizing I could manage colors, margins and such with variables sealed it for me. I still think that preprocessors make it easy to bloat your CSS with nesting, and occasionally behave counterintuitively to standard CSS. But that's where careful development and refactoring come into play.
The objective of this article is to clarify the CSS preprocessors. We sincerely hope this article and the results of our research will convince people who are currently not using CSS preprocessors of the possible benefits of CSS preprocessors. We hope they will consider using CSS preprocessors or even testing them to experience how CSS preprocessors might ease CSS writing.
We would like to thank all participants for providing their feedback to our research questions.
Find below once again the most commonly used CSS preprocessors:
Presentation material (free usage)
In order to allow you to present this article in an easy, clear and proper way we have also created an infographic, a powerpoint presentation and a .PDF file. Click on the item you want to view or download it and use it on your website, blog, college, course, et cetera.
Get new articles, interviews and roundups delivered to your inbox:
We'll send you our non-commercial newsletter a few times per year.
No SPAM ever, we value your privacy.