Difference of PostCSS and Scss?

After a few year didn't doing a front end task now i read a new like PostCSS, Style Components and more.

So what is advantage and disadvantage of each..

Start a personal dev blog on your domain for free and grow your readership.

3.4K+ developers have started their personal blogs on Hashnode in the last one month.

Write in Markdown · Publish articles on custom domain · Gain readership on day zero · Automatic GitHub backup and more

Tommy Hodgins's photo

Both PostCSS and SCSS belong to the family of 'CSS preprocessors'. Styled Components is part of the 'CSS-in-JS' family of plugin, including Aphrodite, Glamorous, and many more. So to answer these I'll have to give you the advantages and disadvantages of each family of CSS plugin.

Before I do that, I'd like to mention that PostCSS is the closest thing in the CSS world to what 'Babel' is in the JavaScript world - it parses CSS, loads plugins that apply transformations to your code, and manages these transformations. SCSS a preprocessor and can be loaded by PostCSS, but PostCSS has the ability to load a lot more than just SCSS :D With PostCSS you could manage SCSS and Less and Stylus code, plus other things - all in the same codebase together.

CSS Preprocessor Advantages

  • using a preprocessor can help reduce overall code size
  • using mixins (plugins) allows you to create small shorthands for common snippets you re-use often
  • sometimes large chunks of code (like CSS animations) can be expressed a more simple instructions, and turned into the full-length code later

CSS Preprocessor Disadvantages

  • often conflict with CSS grammar, meaning nearly every preprocessor (unintentionally) excludes, conflicts, or limits you from using certain syntax or features in CSS
  • requires a build step (some people strongly dislike compiling an interpreted language)
  • All of your preprocessor knowledge stays limited mostly to that preprocessor you learned, and doesn't translate well to regular CSS or other tools

CSS-in-JS Advantages

  • lets you define a 'design system' and 'automatically' styles elements it finds according to your definition of what it should look like
  • depending on which plugin you use, you may be dealing 100% with JavaScript and not actually touch CSS at any point. For some people this is what they want ¯\(ツ)\
  • since it's happening inside JavaScript tools, it's easy to send or receive code from other JS-based tools

CSS-in-JS Disadvantages

  • often requires you to be using JavaScript framework or library in your workflow to be building your code, otherwise these plugins can't run
  • some tools make it harder to style pseudo classes (:hover, :focus, :active, etc) or pseudo-elements (:before, :after, etc) or make use of smarter selectors like :nth-of-type(odd) , or add media query breakpoints
  • Many tools ignore the 'Cascade' part of CSS and work by applying styles to the element's HTML style="" attribute, which leads to overly fragile styles (what if 2 plugins want to change the style="", all they see is what's there, not what's putting it there or why)
Atul Sharma's photo

PostCSS and SCSS both are CSS Pre- Processors (means you write CSS code using some tool (PostCSS/SCSS) specific style and it will get converted to CSS after a build process ) .

Using CSS Pre-Processors give you a lot more functionality than writing CSS in traditional style (Like auto-prefixing of vendor specific classes, complex calculation inside classes, using Global/local variables, mixins, functions, nested classes .. a lot more ).

The main difference between SCSS and PostCSS is the light nature of PostCSS. Means SCSS installation always carries all the functionalities it can provide while PostCSS is more modular in approach and you add functionalities that you need only in form of PostCSS plugins. (Like you need Auto-Prefix add its plugin).

Here's a good overview of PostCSS with the problems it solves while compares to SCSS & SASS. ashleynolan.co.uk/blog/postcss-a-review

Jason Knight's photo

I've NEVER seen any advantages to any CSS pre-processor that couldn't be equally accomplished by simply knowing how to use CSS properly, easing up on the mental midgetry of throwing classes at EVERYTHING, and bothering to leverage your semantics and CSS selectors.

Which is how I end up with 12 to 16k of markup where people using CSS preprocessors, OOCSS methodology, and mind-numbingly halfwit bull like front-end frameworks blow 60 to 100k!

MAYBE if people stopped using hundreds of K of CSS spanning a half dozen or more files to do the job of 32k or less in one file, they wouldn't be diving for nonsensical pointless garbage like SCSS.

All I've ever seen it done is further enhance the ineptitude and ignorance of those who use it. I've NEVER seen ANYTHING done with them that couldn't have been done more efficiently and effectively without them, unless it was something that has zero damned business on a website in the first place!

Oh, and Tommy Hodgins that first claim under "advantages" in your post? I've never seen that one be true... at least not by the time the preprocessor finishes off vomiting up whatever mess it has the unmitigated gall to call CSS.

Don't even get me STARTED about the derpitude of doing CSS from JavaScript, which is why everything wrong with SCSS gets multiplied tenfold in PostCSS. Controlling appearance from JavaScript for anything more than an animation enhancement (which even then should only be a class swap to trigger CSS3 doing the heavy liftting or height as a bugfix) -- EPIC /FAIL/. Do not pass go, do not collect $100.

Even server-side, it's dubios -- the tutorials about PostCSS all showing examples that would be LESS code without it! The "custom selectors plugin" being the poster child for how PostCSS is in the same class of stupid as w3.css! What the blazes type of brain damage does it take to see an advantage in this?!?

Much like the idiocy of HTML/CSS frameworks, I cannot fathom how or why anyone would choose to use these systems apart from knowing so little HTML or CSS they are unqualified to be using either in the first damned place!

Tommy Hodgins's photo

I don't use any preprocessors in my own code, so I'm being pretty objective when I'm listing out the advantages here. Consider the case of animation where, whether it's due to necessary vendor prefixes you end up with a lot of duplicate rules, or in the case of repeated rules with small changes that could be expressed as loops, but you're looking at the flat result.

In both of those cases if your purpose for writing the code is teaching somebody the patterns they need present, it's a lot simpler to look at the base pattern written for a preprocessor that supports automatic prefixing, as well as something simple like a loop, than it is to scan over the flat results (no matter the line count) of CSS that would need to exist to support those patterns and ideas in actual browsers.

It's pretty common when teaching concepts and ideas to use pseudo-code, in the case of CSS preprocessors, the pseudo-code you're teaching with can be functional. Ana Tudor uses Sass as a teaching tool to teach animation this way.

In that regard the 'code' in your codebase is the shorthand, pseudo-code-like preprocessor dialect, rather than the code it may expand out to. When you're building a product you have to think about the generated code, but sometimes the codebase you're maintaining or working on exists primarily in the preprocessor form, and usually those are shorter rather than longer.

I do laugh a little bit when somebody uses a preprocessor and the end result ends up being much shorter and simpler CSS - there are definitely cases where it's overkill, limits your expressive ability, and it is really easy to generate lots of unnecessary code (in an amount that would take too long to do by hand by accident), but I think there are a lot of different applications for writing it, and not all even end up in a browser. What about writing examples for a book about CSS animation, surely the more succinct expression (preprocessor) would be preferred to the long form CSS.

As for JS-powered styling 😎 You might be talking to the wrong guy about that one! :D I'm 100% in favour of CSS, and I love writing my CSS as vanilla CSS from scratch. Writing just what I need, and nothing more… but if I genuinely need to do something beyond what CSS can do by itself, I'd rather extend CSS using another supported web standard language (JavaScript) than use a non-standard technology.

Lately I've been doing a lot of experiments with JS-in-CSS, and this month I'm experimenting (for the first time) with preprocessing, but I'll be consuming both an HTML file and a CSS stylesheet that contains custom 'container queries', and it outputs HTML + vanilla CSS (using CSS media queries). The output is CSS you'd never want to figure out, or write by hand. The calculations are something the machine can interpret and apply to your HTML and CSS very simply, but would be a massive headache for a human to try to figure out. (Perhaps too complex!)

Every day from December 1st -> December 25th I'm posting about a CSS plugin or technique that goes beyond what CSS normally does in some way, the thread starts here: twitter.com/innovati/status/936605657888935.. and today's was all about interpolating JS in CSS stylesheets <3