[Next.js] Next.js와 호환되는 css와 그렇지 못한 css에 대한 고찰

 

 

Next.js로 프로젝트를 하면서 드는 의문이 있다.

왜 MUI 같은 라이브러리들은 자꾸 호환이 안된다고 하는 걸까??

tailwind는 왜 되는걸까??

 

 

---

 

 

공식 문서를 보면 다음과 같이 나와 있다.

 

 

Next.js와 호환이 잘되는 것들

 

1. CSS Modules

2. tailwind CSS

3. Sass

 

 

Next.js와 호환이 잘 안되는 것

 

CSS-in-JS 

 

• chakra-ui
• kuma-ui
• @mui/material
• @mui/joy
• pandacss
• styled-jsx
• styled-components
• stylex
• tamagui
• tss-react
• vanilla-extract

 

근데 또 emotion은 이제 지원한다고 한다.

 

CSS-in-JS가 지원이 안되는 이유는??

이유는 다음과 같이 나타나 있다.

 

 

Warning: CSS-in-JS libraries which require runtime JavaScript are not currently supported in Server Components.

 

 

-> Next.js에서 Server Components(RSC)를 활용하면, 서버 측에서 pre-render 단계에서 미리 HTML과 CSS를 클라이언트에 전달합니다. 그리고 클라이언트가 이를 받아서 화면에 보여주게 됩니다. 따라서, Next.js의 서버 컴포넌트(RSC)를 활용하려면 빌드 시에 CSS 파일이 사전에 준비되어야 합니다. 반대로 런타임에 JavaScript를 사용해 CSS를 동적으로 생성하는 접근법 ( 이를테면 CSS-In-JS )은 Next.js의 RSC에 호환되지 않고 주로 클라이언트 컴포넌트에서 활용됩니다. 이는 서버 측에서 처리되는 RSC가 HTML과 함께 최적화된 CSS를 미리 클라이언트에 전달하는 특성 때문입니다. 

 

 

그럼 어떤 방식들이 빌드 타임에 css 파일을 만들 수 있어서 Next.js의 RSC와 호환이 되고 어떤 방식들이 그러지 못할까??

 

 

반응형

---

 

1. Vanilla CSS (순수 CSS)

순수 CSS는 별도의 라이브러리나 프레임워크 없이 웹 브라우저가 직접 해석할 수 있는 원시 CSS 코드를 사용하는 방식이다.

순수 Css는 별 다른 처리가 필요하지 않아 서버 컴포넌트(RSC)에서 호환 문제가 발생하지 않는다.

 

 

2. CSS Preprocessors (CSS 전처리기)

Sass, Less, Postcss 를 포함하는 CSS 전처리기는 빌드 타임에 순수 CSS로 컴파일 된다.

그래서 역시 호환 문제가 발생하지 않는다.

 

 

3. CSS Modules

CSS 클래스 이름을 고유하게 만들어 스타일 충돌을 방지하는 방식. 빌드 시점에 이미 스타일이 처리되어 최종 CSS 파일이 생성하기 때문에 서버 사이드 렌더링과 문제없이 호환 된다.

 

 

4. Utility-First CSS 

 Tailwind css 가 포함된다. 빌드 타임에 유의미하게 사용되는 유틸리티 클래스만을 포함하는 최적화된 CSS 파일을 생성한다.

생성된 CSS 파일은 서버 사이드에서 HTML에 직접 적용되므로, JavaScript의 실행 없이도 최종 사용자에게 스타일이 적용된 페이지를 제공할 수 있다.

 

 

4. CSS-in-JS

Styled-components, MUI 등을 포함하고 JavaScript를 사용하여 스타일을 정의한다. 그래서 런타임에 동적으로 스타일이 적용된다. 일부 라이브러리는 추가 작업을 통해 서버 사이드 렌더링을 지원한다.(ex. Emotion)

 

 

 

---

 

 

어쨌든 빌드 타임에 css가 완성되냐 , 런타임에서 JS를 통해 동적으로 css가 렌더링 되냐가 Next.js의 서버 컴포넌트와의 호환성을 결정해 준다고 결론을 내렸다!