styled-component 사용시, 랜더링

tailwindcss를 사용하던 와중, 'use client' 지시어를 보고, 문득 styled-component와 next.js와의 조합이 어떤지 생각이 났다.

 

next.js와 tailwindcss와의 조합은 SSR를 사용함에 따라, CSS를 사전에 구성해둘 수 있으므로, 브라우저에서의 랜더링 성능이 styled-compnent보다 더 좋다는 것을 알고 있었다.

 

우선 이부분을 먼저 조사를 해봤다.

 

tailwindcss는 빌드 시, 프로젝트 코드내에서 사용되는 CSS만 빌드에 포함하고 사용하지 않은 코드는 제외한다. 그래서 우리는 아래와 같은 코드는 tailwindcss에서 사용할 수 없다는 것을 알고 있다.

<span className={`text-[${}px]`}>텍스트</span>

해당 코드는 빌드 타임에 모든 클래스를 생성해야 하는 tailwindcss 특성상 어떤 값이 올지 않수 없으므로 런타임 동안 동적으로 올 수 있는 은 쓸 수 없다.

 

tailwindcss는 next.js와 조합하여 사용했을 때, 이미 빌드 타임 때 생성한 최적화된 CSS 번들 파일을 사용하여 랜더링을 시작하므로, 런타임 시간에 CSS 조각을 생성하는 styled-component에 비해 성능상의 이점을 가질 수 있다.

 

styled-component에도 단점이 있는 것은 아니다, 프로젝트의 구성에 따라 복잡하고 동적인 스타일링이 많이  필요한 경우라면, tailwindcss보다 더 자유롭게 쓸 수 있고, tailwindcss보다 가독성 높은 코드를 구성하고, 캡슐화가 쉽고, 여러 장점이 있다. 하지만 동적인 스타일링이라는 기능을 위해서는 Next.js의 SSR 기능을 쓰기에는 제약이 크고, Next.js에서의 추가적인 설정을 통해 styled-component를 SSR 기능에 연동하여 쓸수는 있지만, 기본적으로 런타임 시간에 CSS를 계산하여 DOM에 추가해야 한다는 것은 화면의 깜빡임을 유발할 수 있다.

 

물론 이는 몇년 전의 styled-component를 썼을 때의 경험이고, 그때는 캡슙화와 동적 스타일링이 주는 강점을 높이 평가했었다. 무엇보다 tailwindcss의 가독성에 비하면 횔씬 이해하기 쉽게 코드를 구성할 수 있었다.

 

시간이 지나면서 next.js로 넘어가는 추세였고, react.js +  React Router 보다는 디렉터리 기반의 page나 app router 기능을 지원해 주는 next.js가 너무 좋았던 기억이 있다.