2021-07-08
1890
#react
Nwose Lotanna
260
Jul 8, 2021 ⋅ 6 min read

Benefits of using styled-components in React

Nwose Lotanna Web Developer and Writer

Recent posts:

react children prop how to properly type

How to type React children correctly in TypeScript

Learn modern best practices for typing React children in TypeScript, including ReactNode, PropsWithChildren, ComponentProps, and why React.FC is no longer recommended.

Ohans Emmanuel
Dec 19, 2025 ⋅ 7 min read
complete guide to internationalization next js

The complete guide to internationalization in Next.js

Learn how to internationalize Next.js apps with Lingui and next-intl, covering App Router, RSC, routing, locale detection, and dynamic language switching.

Ivan Vlatkovic
Dec 19, 2025 ⋅ 13 min read

Vite vs. Webpack for react apps in 2025: A senior engineer’s perspective

Vite vs Webpack in 2025: a senior engineer’s take on performance, developer experience, build control, and when each tool makes sense for React apps.

Peter Aideloje
Dec 19, 2025 ⋅ 3 min read
vitest 4 adoption guide

Vitest 4 adoption guide: Overview and migrating from Jest

Learn how Vitest 4 makes migrating from Jest painless, with codemods, faster tests, native ESM, browser testing, and a better DX.

Onuorah Bonaventure
Dec 18, 2025 ⋅ 15 min read
View all posts

7 Replies to "Benefits of using styled-components in React"

  1. Reasons not to use styled components
    Extra page weight as you add lots of extra divs to style your components
    More page weight as you need to include a library to replace something you get for free in all browsers
    Less code -re-use compared to using proper CSS
    Slower than using stylesheets as there is no caching ~ bad for the user
    Slower as you have to create inject the styles into the head on each page load
    Hard to get a consistent style across a site.

    I interview a lot of devs who cannot think of a single reason why styled components have any issues/downside, I don’t mind if people want to use them but no library comes without some downside. I really wish people would focus on the user before using any library, rather than focus on what is comfortable for them as a developer.

    1. Same thing apply for stylesheet in case of adding styles and classes at the top of html in head tag. You can render a component and check!
      By the way with the power of browsers these days, those weights you mentioned are almost non performant at all.

  2. Thanks so much for this. Performance and caching are huge. Another developer-related issue that I have is complex functions written directly within the css in style-components. You end up troubleshooting code just to get a style to load in some cases.

  3. “Extra page weight as you add lots of extra divs to style your components”

    Not sure where you got that from. It doesn’t add anything to the markup apart from classes.

  4. > Extra page weight as you add lots of extra divs to style your components

    Depends on how you create the Styled Components, you can achieve same DOM tree with SCSS or CSS and Styled Components

    > More page weight as you need to include a library to replace something you get for free in all browsers

    Yeah though you optimize it at Component level. As you are using React, ofcourse there had bee tradeoff in that case as well, you are creating DOM nodes one by one.

    > Less code -re-use compared to using proper CSS

    Properly done Design System with Styled Components will achieve much higher code reuse

    > Slower than using stylesheets as there is no caching ~ bad for the user

    If using CSS or SCSS, the CSS is exported to One File with webpack which is more heavier and maybe better cached but whole CSS has been delivered to user even if it is not needed. So we have slower and less performant Initial page load

    > Slower as you have to create inject the styles into the head on each page load

    Not slower as you are injecting on the component specific styles’ classes and is very small. Combined with Components delivered on need basis, not all the styles get inserted to the HEAD, but the needed ones. Hence not too much is lost.

    > Hard to get a consistent style across a site.

    Like I said, if done properly, you can have really great experience for site wide experience.

    —-

    > I really wish people would focus on the user before using any library, rather than focus on what is comfortable for them as a developer.

    Of course we are making for user but we don’t wanna spend lot of time debugging fixing CSS quirks because of Cascading effects.

    I would prefer very less cascaded levels so that debugging is easy.

    As the class names are generated dynamically, there are small, small as 7-10 characters. While CSS or SCSS, need to use ideologies like BEM for less Cascading Conflicts in DOM.

    Small class names means saving package size as that class name was not present two times in same bundle (once in CSS and once in HTML)

  5. I really don’t get why this is so popular. Whenever I come across it I’m put off by how ugly it makes the DOM look in developer tools – instead of clean classes like ‘header subheader’ it just adds so much noise to the HTML. Don’t think it’s very good for writing DRY styles either unless I’m missing something. Importing a properly scoped .scss file in every component is so much cleaner IMO.

Leave a Reply

Would you be interested in joining LogRocket's developer community?

Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.

Sign up now