저도 한때는 styled-components, emotion 등등 css in js 라이브러리 들을 자주 사용하곤 했습니다. 심지어 처음에 tailwind css를 보고 저게 모야! 라고 생각을 했던 개발자중 한명입니다. 처음에 코딩을 배울때 selector 형식 css 를 먼저 접하다 보니 css-in-js 는 혁명적이 였다고 생각도 했습니다. 그러면 먼저 CSS-in-JS 에 대해서 알아가 봅시다!
CSS-in-JS
처음 코딩 했을 때 사용 했던 selector 형식의 문제점을 해결하고자 등장하게 되었습니다.
참고 자료 : https://blog.vjeux.com/2014/javascript/react-css-in-js-nationjs.html
1. Global namespace
css는 global namespace를 갖게됩니다. 모든 css 스타일이 전역에 선언되기 때문에 변수명이 겹치지 않도록 주의해야 합니다.
2. implicit Dependencies
하나의 css를 여러 태그, id, class 에 적용 될수 있습니다.
이러한 문제 때문에 1대 N 의 관계가 되어 개발자는 항상 class 변수 명을 지을때 중복되지 않게 하기 위해 기억을 해야하는 문제점이 있습니다.
3.Dead Code Elimination
모든 css 클래스는 페이지 전체에서 접근이 가능하며, 이는 불필요한 스타일 정의가 많아질 위험을 증가시킵니다. 시간이 지나면서 css파일은 방대해지며, 사용되지 않는 클래스가 계속 추가되거나, 중복된 스타일이 쌓여가는 현상이 발생할 수 있습니다. 이는 Dead Code의 주요 원인 중 하나 입니다.
4.Minification
클래스 이름을 축소하고 js와 css를 사용자에게 조금 더 빠르게 보낼수 있다는 이점이 있지만, 모든 개발자들이 그 변수 이름을 추측할수 없다는 문제점이 있습니다.
5.Sharing Constants
실제로 개발을 하다보면 css 와 js 간에 상수를 공유하는 것은 쉽지 않습니다. 실제로 그렇게 해야하는 실제 사례가 있습니다.
6.Non-deterministic Resolution
우선순위 문제입니다. 같은 specificity를 가질 경우 뒤에 정의된 클래스가 적용되어 문제를 발생시킵니다.
7.Breaking Isolation
특정 스타일이 다른 스타일과 의도치 않게 상호작용하거나 영향을 미치는 상황을 의미합니다. 의도치 않게 변경되면, 문제를 찾고 수정하기 어려워져 유지보수가 복잡해질 수 있습니다.
이러한 이유 때문에 CSS-in-JS 가 등장하게 되었습니다.
Next 에서의 CSS-in-JS
간단하게 styled-components 의 경우 SSR을 사용할 경우, 서버에서 스타일을 미리 계산하여 HTML에 포함시킵니다 이러한 이유 덕분에 서버에서 스타일을 미리 렌더링하여 FOUC(Flash of Unstyled Content) 문제는 발생시키지 않지는 않습니다.
초기 렌더링 단점
초기 렌더링 시 css를 적용하기 위해 javascript 코드가 실행되어야 하며, 서버에서 HTML을 생성할 때 스타일도 함께 계산되므로 tailwind 보다 약간 더 많은 시간이 필요합니다.
빌드 및 번들 크기
런타임에 동적으로 CSS를 생성하므로, 번들에 스타일을 정의하는 javascript 코드가 포함됩니다. 사용 되는 스타일에 따라 번들 크기가 증가할 수 있습니다. (큰 프로젝트에서 성능에 영향을 미칠수 있습니다.)
런타임 성능
일반적으로 큰 차이를 느낄 정도는 아니지만, css를 생성하고 적용하는 부분에서 javascript 로직이 필요합니다.
총평
ssr을 지원하지만, 서버에서 스타일을 계산하는 과정이 추가되므로 초기 렌더링에 약간의 시간이 필요할 수 있습니다.
Tailwind CSS
태일윈드는 Utiliy CSS 로 classname 을 컴포넌트로 만드는 것이 아닌 기능을 추가하는 것이며 빌드시 사용하지 않는 클래스는 purge(제거되어) 번들 크기를 감소시키는 역활도 하여 Dead Code Elimination 문제 해결에 기여합니다 또한 프로젝트가 커져도 style 관련 코드들이 비례해서 증가하지 않는 점도 있습니다.
물론 CSS 모듈과 Sass가 있지만,
CSS module 의 경우 스타일 시트를 계속 관리해 줘야 한다는 점에서 불편함이 있고, Sass는 설정과 관리의 복잡함도 있어 이러한 문제점에서 자유롭고 성능 저하 없이 사용하기 편한 Tailwind 를 권장하는 것이 아닌가 생각 됩니다.
이상으로 간략하게 왜 next 에서 태일윈드를 권장하는가? 에 대해서 정리해 보았습니다. 잘못된 부분이 있으면 댓글 남겨 주시면 정정하겠습니다.
긴 글 읽어주셔서 감사합니다.
