Menu

Why Use CSS Preprocessors? (Open Thread)

CSS preprocessors like Sass and Less are now a common part of our workflows. They have their pros and cons, and I’d like to start a discussion about their value to our work.

Some possible talking points (up to you, though):

The floor is yours. See you in the comments!

What’s the deal with these open threads?

In my post about the Six Revisions redesign, I shared to you that one of the things I wanted to work on was creating more chances for us to talk and engage with each another. Open Threads is hopefully a small step towards this.

I want to try this concept out and get your feedback before formally codifying any sort of community guidelines, but a couple of basic ground rules:

  1. We’ll only keep the threads open for a short time: I’m thinking this period should be between three to five days, but I’d like to get your feedback on this. The current thread will be open from Saturday until Wednesday, then the comments section will be closed. This way, you won’t come in here six months from now after we’ve have already moved on from the topic.
  2. Let’s be civil: There might be instances where a topic we’re talking about leads to disagreements, which is OK. When this happens, let’s promise each other not to let our passion about our viewpoints take us down towards name-calling, flame wars, and so forth. Instead, let’s offer each other constructive counter-arguments when replying to comments that are contradictory to what we believe in.

Anyways, I’m excited to hear your thoughts about the subject of this open thread. CSS preprocessors are really interesting to me, and I wanted to see what you felt about them.

This was published on Mar 21, 2015

20 Comments

Jens Törnell Mar 22 2015

Nesting CSS is the most important for me but variables and import is nice as well. Started using LESS but now use SASS. More features less bugs. Prepros are compiling.

    Jacob Gube Mar 22 2015

    Yes, those are definitely huge benefits!

    I’d like to see if I could kindly ask you to elaborate more on the features you like in Sass that Less doesn’t have. Making a switch to another preprocessor usually comes with a cost — migrating existing projects, learning another set of guidelines, undoing past habits, and so forth — so the features in Sass must’ve been compelling enough for you to make the jump.

    By the way, I’m using Less at the moment, and have very limited production-level experience with Sass/SCSS, so I’m really curious to hear your thoughts .

    I like SCSS’s variable syntax better than Less because it adopts a familiar variable-declaration syntax (at least for PHP and Ruby programmers).

    SCSS

    $link-color: #0000b2;

    Compared to:

    Less

    @link-color: #0000b2;

    Less variables look like CSS at-rules such as @import, which is a bad thing in terms of readability and non-ambiguity in our stylesheets (if that even makes sense).

    But in my opinion the Less variables syntax is still much better than the latest version of W3 specs for CSS custom properties:

    CSS

    :root {
      --link-color: #0000b2;
    }

      Johnny Lin Mar 22 2015

      For me, the reason I moved from LESS to SASS is mainly because of Compass. It makes background sprites unbelievably easy to use, and it comes with a ton of mix-ins that make putting together CSS so fast (with plenty of docs). And it doesn’t come with any predetermined styles (like Bootstrap does), so I never have to worry about overriding anything.

      Jacob Gube Mar 22 2015

      This is definitely a BIG advantage.

      Less has some Compass-like frameworks (but at the moment, they’re not in the same scale as Compass). Less Framework and The Semantic Grid System, for example.

      Jacob Gube Mar 22 2015

      This is definitely a BIG advantage.

      Less has some Compass-like frameworks (but at the moment, they’re not in the same scale as Compass). Less Framework and The Semantic Grid System, for example.

    Nesting is also the biggest pitfall of css preprocessors. If you loose sight of what it compiles to you end up with css rules that are very hard to overwrite (!important is really just a last resort). Nesting is awesome, but just because you can doesn’t mean you should.

      Jacob Gube Mar 22 2015

      I think this concept applies to virtually everything – when things are used appropriately, it’s great, but abuse it and it starts becoming a problem rather than a solution.

Adam Spelbring Mar 22 2015

I’ve used frameworks like Bootstrap that uses them by default but I replace it with my own. I love writing my own CSS. It’s the best part of being a designer/developer to me.

When I first heard about them, I thought they were a great idea. But in practice I found that I really had no use for them and it only served to slow me down.

Maybe I don’t work on the right kind of sites. Maybe I’m just old and have been doing it too long. But I still believe nothing is better then writing your own and not having to have unnecessary (to me) technology interfere with the process.

    Jacob Gube Mar 22 2015

    Adam, a concept in your your comment really resonated with me, that there’s no “right” tool/framework/workflow except for the ones that work for you, your philosophy, and your dev projects. If the developer feels the tool is a hindrance rather than an asset, then it’s not a good fit, and there’s nothing wrong with that. “Do whatever it takes to get the job done,” is one of my philosophies, and that also means dropping things from my process because they’re interfering with the work at hand.

Luke Pettway Mar 22 2015

I love using SASS . The big win for me is being able to segment sheets into chunks such as header, footer, nav, etc which makes it far more organized and easier to follow.

Being able to easily import other SASS sheets, compile as one sheet, and then using grunt to minify everything has also made my life easier.

Another big win are mixins and extends because you can really take advantage of logic to calculate sizes of borders,margins, and anything else. You can also make boilerplate code functions for a project that use variables to determine how something should look which can save a user a lot of time.

Although not directly built into SASS, spriting via Compass is very useful too.

    Jacob Gube Mar 22 2015

    Modularization is something I’m working on right now, actually!

    I still work with a single stylesheet. But I’m compartmentalizing my stylesheets into components now in my dev branch (should have done it in the beginning). It’s just not manageable to have one dev stylesheet for me anymore, even with some sort of style guide/architecture inspired by a hodge-podge (and maybe that’s another problem altogether, haha) of concepts from SMACSS and Code Guide by @mdo. The Six Revisions version 2 source stylesheet (which is still actually just v2.0.0-alpha.1) is 1,100+ lines I think. For the v2.0.0, the selectors and media queries must be better optimized, and I think before we get there, it has to be modularized (if not, then definitely in the first minor-release cycle).

    Hopefully your comment inspires those still on the fence to at least try out a preprocessor to see if they can derive value from it! Also, Compass seems to be a major attraction over Less, @Johnny Lin pointed it out too.

Paris Paraskeva Mar 22 2015

Tried several times to incorporate less or scss into my workflow but every time I gave up on in mostly due to the added element of complexity and learning yet another language/format. Benefits were little and didn’t realy justify sticking with less of sass. Didn’t see the point of variables since I can easily search and replace colors, didn’t see the point of nesting since it made code less readable and generally I beleivd the benefits of less and sass are overhyped!

For what it’s worth I do web dev for ten years now and worked on 200+ projects so far with 99% of them coded with a completely custom cms so I wrote tons of code and value anything making my life easy. CSS preprocessors and extra complexity that’s not worth for

    Jacob Gube Mar 22 2015

    200 projects. And to do that with a custom CMS, instead of an open source platform like WordPress or Drupal… That’s, to say the least, impressively productive. Do you work in a team or are you an independent developer?

    Theoretically, preprocessors are meant for devs like you, who work in the scale that you do, but from what you’ve said, they’re posing as a hindrance instead.

Barbara Kawalec Mar 23 2015

I use SASS for every project now, usually with Bourbon and Neat for grids. And Prepros for compiling . I sometimes add Bitters or some Refills components if it suits the project.

It’s great to be able to have the stylesheet divided into smaller parts, especially for larger sites. I use variables to have all site colours in one place and colour functions to modify them (no need for Photoshop for that any more). I use sass comments a lot for comments that I don’t want to show in the final stylesheet or to temporarily hide lines of code.

As someone said before, you have to be careful about nesting (makes your scss file look organized and it’s tempting to use it unnecessarily). Nesting of media queries is another feature that I have mixed feelings about. It makes life much easier and I use it but I wish sass blocked them in the compiled stylesheet.

What happened to this website theme? It looks horrible now.

    Jacob Gube Mar 23 2015

    Hi Tim. The site was recently updated. Please see my post about the redesign.

    I agree. Jacob, i cannot love your web development blog more — but i have to agree with Tim. Your current theme is horrible — no hierarchy at all !!!! Even proper selection of fonts could give a decent hierarchy and improve the look of your blog. You can do better. A friend who criticizes is better than then ” yes man “

      Jacob Gube Mar 25 2015

      Typographic hierarchy is something I now recognize as something I need to really work on as I iterate on the design.

      And, I thank both you and Tim for sharing your feedback. You’re completely right, a person who’s being honest — regardless of whether or not what they’re saying is positive or negative — is better than someone who will just tell you whatever you want to hear.

      Thanks Sam.

Clayton Mar 24 2015

I build (and maintain) a slew of sites. Most of them are written in Sass, some in Less and some in strait CSS. I definitely enjoy building with Sass. I know I’m not using it to its full extent, mostly just a few mixins, but it’s something I look forward to growing into.
That said, maintaining any preprocessed site can be a nightmare. I’ve spent many hours chasing down variables, un-twisting grids from @media calls, and dealing with production sites with compressed CSS. And that doesn’t even include the time trying to sort out which version of Compass a site was compiled with.
I’d like to say I always have well organized, SMACSS compliant code, but the truth is when push comes to shove you make it work. What that leaves is sometimes messy code that’s hard to untangle.
In a maintenance situation, if you gave me a choice between strait CSS and Sass(or Less), I’d choose CSS.

    Jacob Gube Mar 25 2015

    What you’ve said is very interesting.

    Theoretically, preprocessors should make maintaining/updating CSS easier because of variables and other features that allow you to write less code (which indirectly translates to fewer lines of code to worry about and maintain) but what you’ve said is they can actually lead to the opposite situation, and that normal CSS is actually easier to maintain.

This comment section is closed. Please contact us if you have important new information about this post.

Partners