CSS preprocessors

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.

I use Scss because most projects use it and Stylus on my own projects. I'm really fond of the stylus syntax, the fact that it makes my stack 100% JavaScript and find that it's by far the fastest compiler.

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.

Why Scss?

• 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.

Why?
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 use Less (javascript api) and Sass (Libsass or Compass). I started using less and loading the less.js to compress in the run time the less files, but then, I downloaded the foundation package that bring with Libsass or compass, which is more easy and faster. You have to have some knowleage to set up, node.js, bower, ruby, etc. Less and Sass are very cool, also I saw that stylus is very similar but less formating.

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...

I only used the variables and nesting features for a long time but I didn't really like that it was done with JavaScript, so I looked around for some kind of tool, and found Less.app for the Mac - after a couple of years, the author of that app created CodeKit, which is the third most important tool in my setup (TextMate is 1st, GitHub 2nd :-)

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.

I use them solo, mostly with command line and with grunt, javascript task runner and prefer sass, because majority of people with whom i work use sass too.

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.

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.