styled-component 를 즐겨 사용하지만, 불편함도 슬슬 느끼고 있던 시점에서 CSS-in-JS의 사용이 좋지 않을 수 있다는 의견을 제시한 글을 발견하여 요약해보고자 했습니다.
(이러한 방향으로 해석할 수 있구나 정도로 참고정도만 하시는걸.. 포스팅 글에 대한 여러 찬반 의견들이 있습니다)

참고문헌

https://dev.to/srmagura/why-were-breaking-up-wiht-css-in-js-4g9b

요약

CSS-in-JS를 사용하는 이유

• 우선은 css.module 과 마찬가지로 스코프 범위 내 스타일링 지정이기에 전역적으로 스타일링이 겹치게 되는 현상을 막을 수 있습니다

• 하나의 컴포넌트와 관련된 스타일을 하나의 파일에서 처리할 수 있습니다

• (가장 자주 사용!) 리엑트 내 state 나 props 값을 변수로 전달하여 스타일링을 처리할 수 있습니다.

이러한 장점과 달리 단점은?

• CSS 파일이 아니기에, 컴포넌트가 렌더링 될 때 작성된 스타일 코드들은 모두 document 내 CSS 파일 형식으로 직렬화가 되어야 합니다.
  (스타일 직렬화란 작성해둔 CSS 객체 코드를 document 내 CSS 문자열로 변환하는 과정입니다)

• 대표적인 CSS-in-Js 라이브러리인 Emotion 의 경우 이러한 직렬화 과정을 렌더링 내부에서 진행을 하게 됩니다. (인라인 스타일과 동일)

• 즉, 컴포넌트가 랜더링이 진행될 때 마다 스타일 규칙을 다시 정립하고, 이는 랜더링 비용으로 이어집니다. (포스팅 글에서는 이 부분을 가장 큰 단점으로 이야기 하고 있습니다.)

• 이외 단점으로는 js 번들 사이즈의 증가, next.js 와 같이 SSR 환경에서의 여러 오류들 등이 있습니다.

대체할 수 있는 수단은?

• CSS-in-JS의 장점을 모두 가져오기는 힘들지만, 주요 특징 중 하나인 지역 스코프 내 스타일 설정의 경우 기본 module 방식도 가능하며, Sass 역시 이를 해결해줍니다
  (다만 여전히 특정 props를 통해 스타일의 변수로 활용하기는 힘듭니다)

• 반복될 수 있는 스타일작업 (ex. display : flex) 의 경우 매번 작성해주기에는 개발자 경험에 좋지 않을 수 있는데, 이러한 부분을 일정부분 해소시켜줄 수 있는 유틸리티 클래스 사용 tailwind 나 bootstrap 사용도 권장합니다.