Comments on What Will Save Us from the Dark Side of CSS Pre-Processors?

24 Reader Comments

Back to the Column
  1. I’m just wondering if CSS is not going to rescue us from post-processors that rescue us from pre-processors…

    And I’m not kidding when I say this: sometimes, I prefer writing VanillaCSS, using no tricks impossible to maintain, and guess what? It is cool.

    Copy & paste the code below to embed this comment.
  2. Truth be told, I think pre/post-processors should be installed at the server level along with concatenation, minification and image processing services. There’s little need for a company to marry itself to a technology like Sass (just an example, calm down) that’s run on a local machine - I’ve already seen it fail getting stuck in legacy systems. Especially when those kinds of tech change so much (looking at: Sass, Less, Stylus AND Grunt, Broccoli, Gulp as examples)

    I’d love to write vanilla CSS, push to a server and have a apache module or server-side framework process and polyfill the code. It would be a lot more future-proof, but that’s just my opinion.

    Copy & paste the code below to embed this comment.
  3. I don’t see why this is such an issue: while it is true that it is possible to write illegible compiled-CSS, it’s also possible to write illegible vanilla CSS (I’ve seen a lot). But a nicely commented, partitioned Sass, Less or whatever code will output readable or at least understandable CSS which will be reusable in the future.

    I’m personally using a combination of Sass and Autoprefixer with certains restrictions (my own set of good practices if you will): only simple (or exhaustively commented) mixins, limited use of extend and no more than 4 level of nesting. The resulting, non-minified, CSS output can be reused as-is if needed.

    Copy & paste the code below to embed this comment.
  4. Thanks for mentioning myth.io. Since I started using that, all my needs for LESS, SASS & Co have disappeared. The one thing that makes it perfect (imho) is that it uses plain CSS and just adds the latest features not implemented by all browsers yet (vars, math, color manipulation, ...) coupled with taking away the need for vendor-prefixes. So as a programmer I don’t need to learn a special preprocessor-syntax, but just use the things that will be in the next iteration of CSS anyway.

    Copy & paste the code below to embed this comment.
  5. Sounds like you’re saying there are some tools, and if you use them without proper knowledge and precautions, they can cause you pain and make life harder. If that’s the case, this could have been a tweet; am I missing something? Does this unpack to something more controversial or challenging?

    Copy & paste the code below to embed this comment.
  6. The last section is exactly right. Force multiplying technologies amplify everything that goes in, including ineptitude. It’s not just garbage in, garbage out. It’s garbage in, 10x garbage out. But, used wisely, such tools are very valuable.

    Copy & paste the code below to embed this comment.
  7. I agree with Corey. Misuse of a tool due to lack of proper knowledge and precautions does not mean that the tool is broken. In fact, in this case, that assertion can even be dangerous as it can lead to confusion or aversion to utilizing good tools because authoritative voices have called them in to question. This is not to say we shouldn’t constantly question the tools we use and keep an eye on better solutions to avoid becoming attached to and protective of less than ideal technologies. However, right now CSS is the problem and CSS pre-processors are what will save us - even if it ultimately results in their abandonment and their better qualities being integrated in to some other solution or, ideally, CSS itself. That could take a while though and there might be other solutions along the way but what we should avoid is unnecessarily calling in to question the effectiveness of these tools and potentially fragmenting or diminishing the concentrated and collective effort the web community has devoted to making CSS pre-processors such an excellent and unified solution to so many of the fundamental problems with CSS. (Key word ‘unnecessarily’) When a better solution emerges, we should be ready to put our weight behind it but, even after reading this article a couple of times, I fail to see the problem with CSS pre-processors that we need to be saved from. I know this: after experiencing the glory of working with pre-processors I’ll never (willingly) write vanilla CSS, as it exists now, again. I look forward to the day when it has evolved enough to ditch the tools but, until then… pre-processors are the technology through which we can implement good ideas and best practices while we wait for CSS to catch up.

    Copy & paste the code below to embed this comment.
  8. I guess I’m just stuck in my ways, but I disagree with the whole assertion that managing CSS by hand was a big deal. Or at least crafting the very basics of it seems pretty simple.

    Don’t get me wrong, our system has functionality to perform concatenation, minification, and variables ... but that’s it. I haven’t felt the need for much more ... but then again, I am the type that loves to keep up with the trade and implement emerging features. For example, I recently updated an admin for a client and included the will-change property. That’s not very well supported at this time but it’s still a good thing to have for future support IMHO.

    Copy & paste the code below to embed this comment.
  9. I’ve found that adapting BEM syntax in my LESS and SASS files means I still have a clue what the output CSS will look like. Preprocessors output quality worries me, so I limit myself to using concatenation, minification, variables, calculations, and no nesting at all except in edge cases. I have now met designers who joined the industry in the last 3 years, due to joining forward-thinking companies,  have never written vanilla CSS. Now that’s scary—like a more technical version of those Dreamweaver users who never checked the output HTML of their Design Mode work.

    Copy & paste the code below to embed this comment.
  10. I think that tools like SASS, when used correctly, are amazingly useful to designers and developers. I understand the concerns that when used incorrectly they cause all sorts of issues but it reminds me of when javascript libraries first became a big thing. Suddenly anyone could use a library and a plugin or two to create all sorts of amazing effects with little or no knowledge of javascript. This led to all sorts of the same issues as you outline, I would argue you could almost just replace css/pre-processor/SASS with javascript/library/jQuery above and have something that would closely resemble how I _still_ feel about these libraries.

    Yet I wouldn’t argue against their use, I would just argue for the people using them to spend the time to get a greater understanding of the underlying technologies so that they use them as a tool to accomplish their goals rather than as a crutch to support a lack of knowledge and understanding.

    In the end I guess it boils down to “I have the same concerns – I suggest a different solution”. Don’t throw pre-processing out, used correctly it can solve a great number of real world issues with CSS and save everyone a whole lot of time.

    Copy & paste the code below to embed this comment.
  11. As someone who spends half of my time at work deciphering other people’s badly written PHP, it occurs to me that it’s not the tool, it’s the author.

    I am very disciplined in how I write my code, making sure it’s easy to read and coherent.  This goes for how I write my PHP, my HTML, and my SCSS.  My predecessors were not.  Occasionally you find someone who was organized in their CSS but their PHP is a jungle.  Others I go through and find where they used a ‘div’ instead of an ‘a’ tag.  (WHY?!?!)

    If you are disciplined and follow best practices, all of this becomes a moot point.  Yes it’s possible to create crazy CSS with pre-processors but it’s also possible to create crazy CSS all on your own, just like it’s possible to create crazy PHP, crazy HTML, or crazy Javascript.

    To go cliché, “With great power comes great responsibility.”

    Copy & paste the code below to embed this comment.
  12. @Alan Moore That Dreamweaver comment is what I have been thinking for a while when hearing about tools and more tools that helps speed up development. Yes, if developers just use it and never bother to learn what it is doing for them, chances are they are just relying on the infamous Design Mode. Well said.

    Copy & paste the code below to embed this comment.
  13. @ powrsurg + @ Alan Moore —still happily crafting CSS by hand with BBEdit these days in a hand crafted post + beam home in Vermont. It may be quaint and vanilla, like Ben & Jerry’s, but to me, it’s all about learning, growing, and knowing what the code is doing, and not about speed and production. In this sense it’s a bit slower, but precise and analogous to the slow food movement.

    Copy & paste the code below to embed this comment.
  14. I would argue that we’ll have to worry less and less about the raw CSS we ship to users as time goes on. Just like we don’t worry about the compiled assembler code when we write JavaScript today.

    As Chris Coyier points out, using Sass just means going up one step up the “abstract-o-meter”. Adding that layer of abstraction is a natural response to the growing complexity of what we’re trying to build on the web. I’m happy to use a powerful authoring language like Sass and let my compiler turn that into whatever kind of robot-barf the browser happens to understand.

    Copy & paste the code below to embed this comment.
  15. There is no ‘dark side’ to pre-processors, I find. If anything, I think it’s more a problem to do with with how the CSS is written. What’s more, writing CSS Vanilla on a website with a large scale is just asking to be a maintenance nightmare in my eyes.

    That’s why I write CSS using a pre-processor and include a post-processor: because I usually work on projects with a wide architecture. Therefore, I need something to keep the scalability under control as well as practice a CSS methodology to prevent bad authorship. The post-processor helps take care of styles that are necessary to prefix and not bloat my styles, nothing more.

    As for maintainability, maybe when pure CSS variables and more pragmatic ways of writing for the larger scale become a thing, then we won’t need to have this debacle but the reality is we have alternatives for them *now.*

    Copy & paste the code below to embed this comment.
  16. A great article. I’ve seen the best and the worst of both worlds — pre processors are a mess to set up and often get in the way when things just need to be done. A lot of time get’s lost in figuring out the documentation of a mixin. The @extend directive is definitely something not to be messed with a lot since inproper usage often leads to bloated and unreadable code. Autoprefixer now solves vendor prefixing issues so there is no need for pre processing them.

    Writing CSS using post processors like Myth or Pleeease is a walk in the park since it’s only CSS. The main issue with post processing CSS is the lack of nesting, proper variables and media query bubbling.

    There are a lot of cases when pre processing is really valuable such as automatisation of .png or .svg sprites, math calculation and advance functions. Utilising the best of both worlds is a reality today, but upcoming CSS features such as calc(), variables, color and custom MQ will slowly push out the need for pre processing.

    Copy & paste the code below to embed this comment.
  17. Mr. Wright and Lain are on point. CSS is not mystical and I think server-side processing could help. When I made the 6,000 lines of CSS code for the Lenmar battery central that powers best buy’s battery finder (I don’t maintain that code anymore) 3 years ago it would have been handy, but it felt too new. 3 months later I was screaming how awesome it is, but if you’ve got the SASS to say we should use LESS preprocessing maybe we should call the next version MORESASSY and get rid of the “dark side” you mentioned so we can bring the pre-processor suffering to light…

    Copy & paste the code below to embed this comment.
  18. Thanks for the article. However, I do feel that in very rare cases, there is a dark side to anything. Its ultimately people, programmers.

    We were having this conversation the other day at my organization on how to improve this, that and the other; what new technology to adopt; what new tools to bring in etc.

    At some point, one among us stood up and said. “Nothing, I repeat, Nothing can replace good programmers”. We all knew that was true.

    Copy & paste the code below to embed this comment.
  19. Do you see a cssnext? It is like Myth, but it is based on PostCSS and so still developing, instead of Myth. https://github.com/cssnext/cssnext

    Copy & paste the code below to embed this comment.
  20. BTW, there is a nesting in postprocessors: https://github.com/postcss/postcss-nested

    I am sorry, that PostCSS has so bad docs, but I am rewriting them right now :).

    Copy & paste the code below to embed this comment.
  21. Agree with the likes of @Alan Moore’s Dreamweaver comment, @JamesTaylor and @NicolasHoffman… I like writing vanilla CSS. It lets me have an intimate relationship with the code and it means I know everything that’s happening and why. I may be alone here, but I think eventually CSS preprocessors will go away and much of their functionality will be brought to native CSS. There are so many gross websites out there that take so long to load, even on high bandwidth connections. People seem to care less and less about performance, but as we move more and more to mobile it’s going to become even more important. It’s true people can mess up vanilla CSS too, but I think that if people really understand CSS then it’s less likely to happen writing it directly vs using a preprocessor.

    Copy & paste the code below to embed this comment.
  22. Good Article
    BDM
    https://www.facebook.com/SavvyTekmate
    www.savvytekmate.com

    Copy & paste the code below to embed this comment.
  23. Another aproach to the css postprocessor world is
    http://stylecow.github.io/

    It’s faster and easier to use than postcss (with plugins) and solves some of its issues

    Copy & paste the code below to embed this comment.
  24. this is a very nice article.. piastra per capelli

    Copy & paste the code below to embed this comment.
  25. Sorry, commenting is closed on this article.