Eslam Hefnawy
Apr 6, 2023 ⋅ 7 min read

SCSS vs. styled-components: Advantages and caveats

Eslam Hefnawy Serverless Architect at Serverless, Inc. Co-creator of the Serverless Framework and the lead architect of Serverless Components.

Recent posts:

Comparing Cms Options For Django: Wagtail Vs Django Cms

Wagtail vs. Django CMS: Comparing CMS options for Django

Selecting a CMS for Django can be challenging. Two popular options are Wagtail and Django CMS. Let’s explore their features, pros, and cons.

Chimezie Innocent
Jun 25, 2024 ⋅ 6 min read
Handling File Uploads In Next.js Using UploadThing

Handling file uploads in Next.js using UploadThing

Manage file uploads in your Next.js app using UploadThing, a file upload tool to be used in full-stack TypeScript applications.

Jude Miracle
Jun 21, 2024 ⋅ 15 min read
Exploring Advanced Support For Vite 5 In Storybook 8

Exploring advanced support for Vite 5 in Storybook 8

Explore the latest updates in Storybook 8, focusing on its improved support for Vite 5 as a build tool.

Will Soares
Jun 20, 2024 ⋅ 5 min read
Using Next Js With React Suspense To Create A Loading Component

Using Next.js with Suspense to create a loading component

Next.js 13 introduced some new features like support for Suspense, a React feature that lets you delay displaying a component until the children have finished loading.

Suraj Vishwakarma
Jun 19, 2024 ⋅ 9 min read
View all posts

6 Replies to "SCSS vs. styled-components: Advantages and caveats"

  1. “Since styled-components don’t come with any globally scoped selectors, you don’t need to worry about conflicts and styles overwriting each other. Although Sass comes with nice upgrades such as nesting and variables, it’s more likely to lead to overwriting styles.”

    Well. You are comparing oranges and apples here. If you would use scss using css modules and not using them as a globally available stylesheet then this would not be a problem. E.g instead of importing using `import ‘/.styles.scss’` you would import using “import styles from ‘./styles.module.scss” and then apply the styles to the elements using …. Besides. Using styled-component makes your code highly dependent on a specific framework. Css modules can be used with css, sass, less etc.

  2. I think this article horribly underplays the downside of mixing all the styles together. if you look at this trivial example, the “wrapper” class has 8 properties. Now imagine passing this through a couple of libraries each adding a couple of overrides, and for something simple that sets a position and font you end up with ~50 properties most of which override each other. This chain is impossible to debug (by design) because you can’t trace it back without looking through every component in the hierarchy. And when you get to start using style merging and the tree for your component style has dozens of nodes, it becomes infeasible to fix CSS anymore and leads to rewrites.

    The “benefit” of not listing the flat list of class names like class=”one two three … fifteen” is that you end up with one class:

    .merged {


    except without pointers back to the original classes.

    This article mentions that “legacy” websites have more SCSS. Well… it’s a better solution and styled-components codebases just haven’t been around long enough to evolve into ugly behemoths, but it’s only a matter of time.

  3. At work, we use styled components in all of our non-trivial React projects. The codebases are large (some millions of lines of code), and it is very easy to reason about the styles — the projects are certainly not “ugly behemoths”. I used to use Sass/SCSS in my personal projects and have since moved to styled components for the productivity increase and cleanliness. Your comment appears more naive and hurtful than useful to the discussion. Mind you, I think Sass is awesome — I would still use it for any non-React project.

  4. If js is single thread, and dynamic css in NOT ‘a head of time’ vs SCSS.
    Plus injecting dynamic css cause browser repaint.
    Is it worthwhile?

Leave a Reply