Grow your CSS skills. Land your dream job.

Poll Results: Popularity of CSS Preprocessors

Published by Chris Coyier

A few months ago we started this poll about CSS preprocessor syntax. It generated quite a discussion and nearly 13,000 responses. Let's wrap it up by looking at the collected data.

I put it all into this chart:


Full size. Fonts: Hoefler Text, Idlewild, Chartwell

Consider the rest of this article the ALT text for that image. Of the near 13,000 responses, the breakdown was like this:

Sass 5%
Scss 13%
LESS 23%
Stylus 3%
I don't like any of them 7%
I don't have a preference 2%
I've never tried any of them 46%
Other 1%

From this we can infer that "most" people have tried or currently use a CSS preprocessor (54%). I go back and forth in my thoughts on this number. On one hand it seems a bit low considering how much talk there is about them lately and that this poll represents people that visit and interact with a website named "CSS-Tricks." On the other hand, there is a bit of a uncomfortable legwork involved in getting started using preprocessors. You have to work locally. You need your whole team on board. You have to download and run new software. It's not just opening a text file and editing/saving it like editing regular CSS is. I think it's rather encouraging that 54% of people care enough about their workflow to try this.

We don't know much about the 46% that have never tried it, but I'd speculate it is a split between "I don't need this", "I didn't even know about them", and folks like this: "real men don't need preprocessors."

From here we can get to the meat of the poll: figuring out what the most preferred syntax is. Of the 54% of people that have tried them, 83% of those have a preference. The other 17% either don't like any of them or don't have any particular preference. What we don't know is how many of these folks have actually tried out several of them and chosen the one that works best for them. Surely outside factors influence this. For instance, they are working on a Rails project and Sass comes with it. They like it so they've just stuck with that. Or, they are working on a project using Twitter Bootstrap which is built in LESS. They like it so they've just stuck with that.

Of the folks that have tried preprocessors and have a preference, we can break it down by syntax. LESS is the most popular at 51% of those people. The Sass syntaxes together come to 41%. Stylus is at 6% and Other (e.g. a custom PHP processor) at 2%.

Of the people that prefer Sass, 71% like the scss syntax (more like CSS) and 29% like the sass syntax (whitespace dependent, no braces or semicolons).

It will be interesting to revisit these numbers is a year or two. All polls are archived here. New poll soon.

Comments

  1. Interesting. Shows the importance of having a “killer app” for a piece of technology – in this case Bootstrap. I prefer Sass, but the Bootstrap/LESS combination is clearly having a massive impact on usage.

    …that’s really important. Just as jQuery essentially won the Javascript library wars and became the de facto industry standard, exactly the same is going to happen with CSS pre-processors.

    I think Sass is a better choice than LESS for a couple of reasons, but ultimately which one we have to learn will be based on market share. Pretty equal right now (the infographic is a little misleading when it separates SCSS and SASS, when they’re essentially the same preprocessor). At some point one of them is going to become dominant.

    • I don`t think that jQuery analogy stands here. jQuery is a ‘final’ product, included in most of the websites. On the other hand, sass or less is involed in the development process as a third party tool. There is no real competition between the different languages. As long as they can get enough support they`ll be around. The key is the community whether it`s jQuery, wordpress, sass or less.

    • Can’t make the comparison to jQuery for the reasons @Balazs pointed out. A similar point is that Less has a free simple GUI, and has Twitter bootstrap support.

      The Pre-Processor game is new still even though its been around for some time. Stylus is generally used by node.js developers, SASS is “generally” used for Ruby on Rails, and you see that LESS is used more so by php developers, and you can match up the market share of the programming language with the CSS preprocessor.

      Obviously each of these tools has a command line interface that allows you to use them with any development stack of your choosing, but in the end from a development workflow perspective it usually is in your best interest to use your programming languages most popular preprocessor from a pure support for the framework perspective. For instance stylus has “nib” which is like compass. You can use nib with any framework but the implementation for a node project is an NPM install and 1 extra line of code, whereas I would need to setup a correct director structure and compile build in order to use nib in a non node.js project.

      The real question in my mind is what do the actual pros prefer. Not to say that css-tricks.com is not filled with pros, but at the same time we need to look to industry giants, large internet companies, and large web development agencies and ask why they use the tools they use.

  2. SASS seems perfectly fine to me only reason I use LESS instead is because SASS makes me use Ruby.

  3. Permalink to comment#

    I’m going to make the assumption that LESS is more popular because of the proliferation of Twitter Bootstrap. Sass is probably the future, but LESS is, in my opinion, an easier introduction to preprocessors.

  4. @Todd: agreed!

  5. I haven’t started using any of the preprocessors as it involves learning yet another language format. At this point I’m in the middle of courses for PHP and MySQL/RDBMS. When I’m done with that and have finished with ActionScript3.0 and my portfolio course, I have KineticsJS waiting patiently. Once I feel I have gotten familiar enough with KineticsJS, I’ll start messing with pre-processing.

    I have downloaded and installed SCSS/SASS, Ruby, and Rails. I just don’t have time to deal with all that now. I do like the idea of nesting CSS and OOCSS so I will get to it all soon. It’s just not risen to the top of the list yet.

    Right now I’m more concerned with regular CSS, learning CSS animation, and why hsla/rgba don’t seem to work half the time in CSS gradients.

  6. It’s weird that there are so many more people using (or writing about) Sass and SCSS than about Stylus, because Stylus actually has more watchers on GitHub.

    You guys should check out Stylus, it’s pretty epic in combination with nib. I’ve switched from LESS to Stylus recently. :)

  7. I was expecting that the SASS + SCSS will win over LESS by a great margin. But I’m glad. I like LESS more so maybe the results will inspire some great people to make interesting tools based on this preprocessor, since for now LESS seems to be somewhat forgotten.

  8. Having never used any kind of pre-processor this has inspired me to take that first leap. I’m also quite surprised that 46% are in the same boat as me.

  9. I started with LESS because it was easier to start with because it is Javascript, also, there is PHP LESS that allows for PHP based CMSes to use it.

    But after switching to Sass along with Compass, Sass beats LESS in my opinion.

    1. You can do really advance logic with loops, ifs, etc.
    2. The file helpers are amazing image-url, image-width, image-height, etc.
    3. The development output mode with comments for the source file and line number.
    4. The magically moving of includes to the top of the stylesheet.

  10. I find LESS more natural and shorter to write as well as more flexible to beginners, but with enough work put into it, using scss/sass can be much better because of certain things like COMPASS (and the variables are nicer with the $ sign).
    I’ve used one as much as the other and still have no preference between the two (it was LESS when I voted).

  11. I’ve just yesterday made the switch from LESS to SASS (SCSS variant), from all the research I’ve done it seems like the more mature and developed language. The logic handling seems far better.

    After spending a good few hours over the past day rewriting my codebase (boilerplate, responsive grid, mixins) to SCSS I will say that LESS syntax is more clear to work with, SASS would probably be much the same as LESS however being the old syntax of the two (SASS/SCSS) I was hesitant to adopt it.

    The big power of SASS that I can see is the media query handling and the ability to use Compass, I haven’t made that jump yet but the option will be their to explore.

    One thing I believe it is pointless to count as a factor between the two is the compiling, LESS can be served using JS, but don’t, it’s a memory hog and creates JS depency. CodeKit is compatible with LESS/SASS/Haml/CoffeeScript/Compass and will auto-monitor files for changes and compile on the fly… LiveReload does similar if Windows users are interested (currently in BETA), for LESS there’s also SimpLESS. Point being, you’ll find a simple way using either route.

    Pick one and go, it will shave hours off your workflow, it doesn’t matter which, you can easily change… just try it.

  12. Martin
    Permalink to comment#

    Maybe it is time to write a good article on this site about what preprocessors are and what they can do for you, to get those 46% (I am somewhere in those statistics) on board.

  13. Tony
    Permalink to comment#

    Stylus is part of express, which is a node module, maybe that is why it has more watchers on github.
    I have never tried sass, but I am going to, I started with Less and like it a lot, Sass looks even more interesting and stylus is the balls!

  14. I have to say, using LiveReload for Mac has made using SCSS a breeze! I was terminal first, but now I don’t even have to think about it thanks to LiveReload – and there’s a beta version for Windows too – I think if you want to get started with SASS/SCSS then try LiveReload! :)

  15. Jason Medrano
    Permalink to comment#

    23% don’t give a fuck about site performances.
    Debug a LESS based site on a shared hosting or even a basic VPS and see the difference with SASS.
    Who cares about site optimization should use a
    pre-compiled CSS preprocessor. I personally use SASS/SCSS with Compass.

    • LESS does have the ability to be processed “on the fly” with JavaScript, but I’d wager the vast majority of people using it are using it just like Sass, in that is pre-compiled before deploying. I just want to make that distinction clear. It’s not LESS’s fault if people use it dumbly =)

    • Ben
      Permalink to comment#

      Jason, there are development tools like http://wearekiss.com/simpless that are similar to sass –watch

      I think having the javascript is purely for quickly diving into less without having the requirement of having to install any software.

      Most serious developers who are considering either less/sass would understand why using a client-side compiler would be a very bad idea.

    • @Ben very nice have not seen this one before. Agree should not be letting the client compile the code especially for mobile.

      @Chris have you guys talked about this before in any of the article about LESS?

    • Jason Medrano
      Permalink to comment#

      @Chris
      LESS supremacy comes from a range of factors.
      1. Adoption by “so called web design gurus” that baited so many lazy “aspiring web design gurus” in.

      2. The growth of Ruby and Rails.

      I embrace your bet and I think that most developers use dynamically generated CSS code

  16. DarrenM
    Permalink to comment#

    Sorry Chris, I just want to pick you up on one little point: 56% ain’t even close to ‘most people’. In fact, what it says to me is that nearly half of the people who responded have NEVER tried a preprocessor.

    I might add that I was in that number when I answered the poll, but since then have downloaded Compass and I’m loving it. Can’t say it has changed my life, but just the simple addition of variables has made so much difference (not having to scan though the code for that ‘blue’ that the client wants me to use all over the place) that it’s worthwhile.

    Anyway, point being that you’re a long way from ‘most’ but articles like your earlier one comparing LESS and SASS which highlight the reasons for using a preprocessor help raise the awareness and introduce people like me to new stuff, so that’s a plus. Run it again in 6 months and see how the numbers have improved.

    • Nicholas Chamberlin
      Permalink to comment#

      Lol, “raise awareness” … Like coding CSS is aids and CSS preprocessors are the cure.

    • Going with that – 46% aren’t using, and 7% don’t like them, so that means effectively 53% are not using them. Meaning less than half – definitely not ‘most people’ are using them. I use SASS at work, so I’m not in that camp, but it does mean your post is disingenuous at best. =)

    • DarrenM
      Permalink to comment#

      Well, no, “raise awareness” as in “introduce people to new stuff”. Don’t know where you’re coming from with the AIDS analogy, too clever for me. But then only an idiot would think SASS is new, right?

  17. Seems to me that the people who responded to the poll would generally be those who take a more proactive role in learning the ups and downs of web development. I’m sure there are plenty who regularly visit this site and just didn’t respond.

    That being said I think the polls were definitely inciteful thanks for sharing it with us.

  18. Nicholas Chamberlin
    Permalink to comment#

    I would have liked to know what people use the majority of their time, not just their preferred. Not sure if that would have changed how people answered the question. While I may have tried sass and less, and prefer less over Sass, that doesn’t necessarily mean that I use either of those the majority of my time. Maybe I’m splitting hairs?

  19. Mike
    Permalink to comment#

    Simply put, LESS has dominated because it has a set of strong tools on Windows. Sure, it’s not hard to install Ruby and to use SASS on Windows, but users want something that works quickly. I prefer SASS, but I’ll only use LESS because of its great support in Komodo Edit and Visual Studio through extensions.

    As I’ve already said on Reddit, it’s entirely likely that LESS has already won because of its tool set.

  20. I enjoyed the comment about the polls being “inciteful” – I personally find them insightful, but they do often cause quite good discussions so Andrew is probably correct!

    I think that the very first chart is misleading given the title it appears under. If this chart displays “Your preferred CSS preprocessor” the valid answers are either the name of your preferred CSS preprocessor, “other” if you use a niche one or “none” if you don’t have a preferred one.

    By splitting “No pref”, “Never used” and “don’t like” you are able to come to a false conclusion. You change the question to “Have you used a pre-processor” and answer it with “Most people have”.

    It is also worth noting in your results that you would expect a bias towards CSS preprocessors for your readership, given that you have told people about them, a la “There is nothing to be afraid about in this brave new world of preprocessing.”

    Having said all of this, I’m not against CSS preprocessors and they might even have the best possible effect of getting some of these features into native CSS, which would be awesome.

  21. I would be curious to see where the “don’t use” brethren fall when it comes to the type of work they do.

    For me, I’m a “small time” guy that doesn’t generally do his work locally. The sites I work on are almost always less than 20 pages, usually closer to 8 or so. I’ve read the recent pre-processor articles and still don’t really see any benefit to learning them given my site sizes.

    I don’t have problem admitting I’m largely a Dreamweaver user. I can build a site completely in notepad if I wanted (with PHP, JS and the whole shebang) but I can develop rapidly in Dreamweaver and use the GUI layout for 80% of the CSS, tweaking the rest by hand.

    I keep reading things like one of the previous posters above that said, “Pick one and go, it will shave hours off your workflow, it doesn’t matter which, you can easily change… just try it.”

    But honestly, given what type of work I do and how quickly I can bang it out in Dreamweaver, I just don’t see that being the case…or at least I haven’t seen a persuasive argument to the contrary.

    I just wonder how many of the “don’t use”/”don’t have a pref.” voters fall into a similar category?

  22. “We don’t know much about the 46% that have never tried it, but I’d speculate it is a split between “I don’t need this”, “I didn’t even know about them”, and folks like this: “real men don’t need preprocessors.”

    I think you are forgetting an important category of people. Those that simply did not yet get to it. Because they’re too busy, because they’re maintaining sites that still do it the old way, or because they think it’s a major switch.

    I was part of that group, being fully aware of preprocessors but not yet using them. Until I tried SASS/Compass in combination with Scout. It took me about an hour to make the switch and I’m never doing any project without it.

  23. Jesus Bejarano
    Permalink to comment#

    People that don`t know anything about preprocessor or neglec them should look this

    video http://www.youtube.com/watch?v=FlW2vvl0yvo&list=HL1339547552&feature=mh_lolz

    to see what is all about

  24. I really don’t see the point of using any of these preprocessors. It just seems pointless to have to learn more syntax and to have to install extra software just to do things that can be done in a simple text editor. Why does CSS need variables – just search and replace. Why does CSS need shorthand – just set up your own custom snippets, keyboard shortcuts, or macros. I don’t think that there is anything that a preprocessor can do for me that can’t be done just as fast in vim. But maybe I’m wrong as I have only played with LESS a little with bootstrap.

    • I asked the same questions myself! Why do we need this? Search and replace comes handy but it is very limited comparing to some sass (or less) features.

      Some of my favourites in sass:

      COLOR:

      
      $main-color: #333333;
      $main-lighther:lighten($main-color,5%);  //->  #262626
      $main-darker:darken($main-color,5%);    //->  #404040
      

      EXTEND:

      let`s say you have a clearfix hack, called .cf. Normally you would add it to your html tags to clear the floats with sass you can do something like this:

      
      .cf {
        // clearfix stuff comes here
      }
      header,footer,#main{
       @extend .cf;
      }
      

      This compiles to :

      
      .cf,header,footer,#main{
       // clearfix stuff comes here
      }
      

      …and there are plenty more

    • Jason Medrano
      Permalink to comment#

      @Randy
      For a little site (landing page, one page sale letter, etc) I agree with you.
      But for large projects or long term growing projects, CSS code management becomes a pain.
      Preprocessors help to maintain code and save time (time == money)

    • I guess that I’m just unique because I like to leave out steps that require my markup to be processed by external tools before it can be displayed to the end user. In the end, I just don’t see it saving me any time compared to what can already be done with the standard command line text processing tools that come with linux. Nearly every example that I’ve seen of the markup vs how it compiles into CSS looks like the compiled CSS is easier to maintain to me and no longer to type especially since I use a custom made set of snippets in vim for html5 and css3. I think they are cool alternatives but not necessarily better than the old ways yet. The main benefit of these processors seems to be that the CSS gets minified, but there are other tools to do this already. Really, its all about your personal workflow and it would probably be a good idea for everyone to at least try these tools out. I have used LESS for building one web site and am trying it out again for another but still haven’t seen any true time savings.

    • Could you tell me, how you can achive something like I mentioned, using macros, snippets or the command line stuff you mentioned ? I`m a bit confused…

    • @Balazs
      I’m not at all saying that my workflow can do everything that can be done with LESS or SASS, just that the few extras that it does offer are not quite worth it to me. Your color example, I cannot do as vim can’t choose hex colors by adjusting percentages (or maybe it can with a script) but that is not enough to win me over yet. The other example just doesn’t seem to save any less typing and the organization seems easier to maintain in the post processed format. The advantage I guess is that you can keep everything seperate in the stylesheet, but it will be compiled into a speedier loading end result? Also most people here are probably using Macs, so I have no access to things like codekit that probably make all this a little more compelling to use as I’ve seen Chris’s video demo on getting started with SASS. I’m still giving preprocessors a chance and just set up a script for my .less files to auto compile every night just before my sites automatically upload to my server, so that takes some of the extra effort out of the equation for me!

    • DarrenM
      Permalink to comment#

      Certainly not a guru, but one example where I’ve found SASS to be very helpful is when you have a series of elements that have dimensions or other attributes that are relative to some predetermined size, like a page or column width. You can specify that size as a variable (technically-speaking it’s a constant, not a variable) and then perform mathematical operations on it to calculate dimensions of child nodes. It’s not only useful if the size ever changes, it’s also handy not to have to perform those calcs in your head when you’re entering the styles.

      Also there are the ‘lighten’ and ‘darken’ commands which can be used to create a gradient background around a main colour. You can create a variable for that main colour and have SASS calculate a shade 5% lighter and 5% darker for your gradient. Then if the colour changes, it automatically changes the gradient. There’s no way I could work out what the RGB should be for those colours in my head, SASS does it for me.

      Perhaps it is down to what you’re used to. As a programmer first and web developer second, I find it second nature to have as little hard-coded as possible and to just do calculations on variables and constants to determine things that are relative. Hope that makes sense.

    • @DarrenM: Big time SASS/Compass fan here, after being skeptical at first. So I agree, it’s hard to explain how powerful SASS/Compass is to those that have never tried it.

      Having said that, I just wanted to remark that relative coloring can be done partly without SASS as well. You can define a basecolor, and to create your “relative” gradient you use RGBA to lighten or darken a shadow, gradient, whatever. To darken (rgba(0,0,0,.5)), to lighten rgba(255,255,255,.5), where .5 is the strength.

      Still, that doesn’t come close to what other things one can do with colors in SASS.

    • Pat
      Permalink to comment#

      I felt the same for a long time but now I won’t build a site (big or small) without Sass/Compass. Features which I find help my workflow so much are:

      – CSS3 mixins (auto-generate all the prefixes),
      – IE filter fallbacks (< IE9) and SVG gradient fallbacks (IE9) for gradients
      – inline images in CSS as base64 strings with a simple function call
      – cachebusting css images
      – A compass plugin called rgbapng which when you pass in an rgba value will automatically generate a 1x1px opaque image in that color and inline it in your CSS for browsers that don’t understand RGBA.
      – passing hex values rather than RGB to get RGBA values e.g. rgba(#123456, 0.5)
      – Ceaser mixins for generating CSS3 cubier bezier transitions based on Robert Penner easing equations.
      – Spriting has been a godsend!!!!

  25. vote for SaSS

  26. Permalink to comment#

    People, give them a try really! I was also reluctant to get on the boat, but once you’re on it, you don’t want to go back.
    I love SASS/ Compass, and the Susy grid system, it takes the pain away from building responsive sites, and makes the code much easier to read and maintain.
    You can always look at the generated CSS, and you should and if you don’t like what you see, go back and tweak your SCSS or whatever syntax you’re using, that’s how you learn. It’s not a huge time investment, it will feel natural very fast, trust me.
    Do a weekend project just to try it out.

  27. Thanks for posting this post. According to me my vote goes to SCSS

  28. I voted for “never tried”, but after “SASS vs. LESS” article I used Stylus + nib for latest project :)

  29. LESS all the way, with Codekit as my preprocessor.

  30. I just started using Sass and I don’t know why I didn’t use it before. I’ve coupled my workflow with LiveReload and the Bourbon Sass mixins and tools library and I’m blown away. Anyone that says it’s more work is either 1.) afraid of learning something new; and or 2.) just plain lazy. If any of these preprocessors does one thing, it’s to make your life easier.

    Tired of writing a bunch of repetitive crap? Nest stuff in Sass. Hate the old find+replace method? Use a variable. Want to reuse code you used on a different element? Use @extend. Hell, it even does math for you. I built a responsive layout using the flex-grid features that Bourbon includes and I was able to make a multi-column, fully responsive layout in a few hours. No additional frameworks involved. All of my styles are divided into their own stylesheets and then automatically compiled into one file upon save, via LiveReload. On top of that, LiveReload automatically refreshes my browser for me whenever a file in the watched folder changes.

    How can anyone dislike this workflow? It’s stupid simple and completely hands off. Sass alone changed my entire workflow. All of those snippets you have saved? Yeah, throw that shit out and build a base SCSS file that you reference to every time. You can turn each snippet into a @mixin, plug it into your base SCSS file, include that file into your main SCSS file and then use your snippets on the fly. No copy+pasting.

    It’s a no-brainer. Like the Sass website says, “Sass makes CSS fun again.”

  31. Permalink to comment#

    I have only ever used LESS but after reading all this I think it’s time I broke away from my comfort and looked into SASS

  32. Was of the “real men don’t need preprocessors” variety, until I finally thought, ‘Oh well, let’s just give it a try, it won’t hurt.’

    Obviously, I bought into it (SASS) right away – within ten minutes I was like, “This is what I have wanted all along each time I was coding CSS!”

    Thank you SASS creators for translating our vague dissatisfaction with CSS into reality. And for the other ‘real men’, don’t let your pride get in the way – SASS (and probably LESS) is the _correct_ way to code CSS.

  33. Permalink to comment#

    Can you provide this poll annually? I’d love to see the results year-over-year.

This comment thread is closed. If you have important information to share, you can always contact me.

*May or may not contain any actual "CSS" or "Tricks".