Styled-components was one of the first CSS-in-JS libraries that gained widespread adoption in the React ecosystem. It introduced a novel way to style components by leveraging tagged template literals, allowing developers to write actual CSS code within their JavaScript files. This approach provided several benefits, such as scoped styles, dynamic styling based on props, and improved developer experience.

A wonderful solution for its time, for those who didn't like toggling between JS and CSS files, styled-components provided a seamless way to keep styles close to the components they affected. It also offered features like theming and automatic vendor prefixing, which simplified the styling process.

Being a run-time library, styled-components injects styles into the DOM at runtime, which can lead to performance overhead, especially in large applications with many styled components. This can result in slower initial load times and increased memory usage, but for most applications, the impact is negligible.

As a design systems engineer in the year our lord 2026, who has had to migrate a large codebase away from styled-components, I have a few thoughts on rules that I would put in place before adopting styled-components in a new project:

• Make sure there is a theming solution that separates global styles from product-area specific styles. Encourage engineers to pause before reaching for createGlobalStyle.
• Establish what rules should be allowed on design system components. For example, do not allow for non-tokenized colors to be applied to components, decide on whether properties like margin and padding should be allowed to be set on all components or should these be restricted to layout components only? Some kind of linting tool like this could be helpful.
• Implement a code review process (or build pipeline) that ensures styled-components are used appropriately and consistently across the codebase. Do not allow more than one level of over styling (so a person can apply styles on a design system component, but that component shouldn't be imported to be used somewhere else to be styled again). We want some level of flexibility, but not too much.
• Encourage engineers to help audit the codebase with component-monitoring tools like Omlet's vscode extention to identify and refactor over-styled components.