머릿말
이번에 next-pro에서 첫 프로젝트로 sns만들어보기를 진행하게 됐다. 리액트를 사용하는건 정해져 있지만 그 외 필요한 라이브러리, 프레임워크는 내가 사용하는 명확한 이유가 있어야 한다는 조건하에 자율적으로 사용하라고 말씀해 주셨다. 그래서 일단 css는 어떤것을 사용하는게 좋을지 찾아보았다. 내가 생각한 기준으로는 1차(나의 흥미), 2차(러닝커브, 장점 단점 비교)로 나누어 보았다.
기본 (css module + sass)
- css module은 css를 작성하는 방법론중의 하나로 생각해서 선택지로 넣었다.
- css도 결국 한 스코프로 모이기 때문에 다른 파일에서 사용한 class명이 중복될 수도 있어서 사용되는 파일마다 class명을 따로 지어줘야하는데 module을 사용하면 지역 스코프로 class명을 지정해 파일에 같은 class명을 지어줘도 상관이 없다. 또한 내가 사용했던 vue처럼 한 컴포넌트의 style을 한눈에 볼 수 있고, 유지보수가 쉬운것도 장점이라고 말할 수 있다. 또한 기본 css를 사용해봤던 사람이라면 무리없이 사용할 수 있다는것도 중요한 점 중 하나로 볼 수 있다.
- 하지만 css module의 경우는 style을 동적으로 처리하는것에 어렵고, 조건부 스타일링이 제한적이다. 하지만 이 단점은 classnames라는 라이브러리를 추가적으로 설치해 보완할 수 있다.
Tailwind
It's fast, flexible, and reliable — with zero-runtime.
- tailwind는 부트스트랩같이 많은 유틸 class로 이루어진 css 프레임워크이다. css작성 없이 tailwind에서 제공하는 class명을 사용하고 조합해서 스타일링을 진행하는 방식으로 빠른 개발을 진행할 수 있게 한다.
- 획일화된 부트스트랩의 디자인과 다르게 class명을 조합해서 다양한 종류의 디자인을 만들어낼 수 있다는 확장성을 가지고 있다.
- class명을 많이 적을거면 inline style을 적용하는게 낫지 않나? 라는 생각을 할 수도 있다.
- inline style은 미디어 쿼리를 사용할 수 없기 때문에 반응형 디자인을 구현할 수 없고, 의사 클래스(:focus)나 의사 요소(::before)를 사용할 수 없다는 단점이 있다.(애초에 여러 단점으로 인해 inline style은 지양되고 있다.) 그리고 inline style을 사용한다면 공통적으로 사용하는 css를 사용하는 html마다 다 적용해야하는데 css코드 양이 많아진다.
- 초반에 class명을 익혀야하기 때문에 문서를 참고해야한다는 러닝커브가 조금은 있다는 단점이 있다. (하지만 class명이 직관적이기도 하고, 자동완성 시켜주는 익스텐션(Tailwind CSS IntelliSense)가 있어서 큰 단점이라고 생각하지는 않는다.)
- module 방식과 같이 동적으로 class명을 설정하는것이 어렵고 번거롭다고 한다.(공식문서에서도 동적으로 class명을 설정하지 말라고 한다. - 개인적으로 저정도로 동적으로 사용하는건 필요하지 않다고 생각한다. 아래 방법도 충분히 좋다.)
- 코드가 지저분해 보일 수 있고, html과 css의 관심사를 분리하지 못한다는 단점도 있다.
- 나는 class작명을 잘하고 싶지만, 정말 못하는데 이미 있는 class명을 쓰면 되기 때문에 이런 고민 해결에 도움이 될 수도 있을 것 같다. 익스텐션을 추가로 설치하면 러닝 커브도 크게 높지 않을 것 같고, 디자인에 조예가 없는 나한테는 디자인적으로 고민하지 않아도 된다는것도 메리트로 다가왔다. 그리고 내가 진행하는건 개인작업이지만, 팀작업에서 공통된 class명을 사용한다는것도 문서의 통일성을 주지 않을까 하는 생각도 있다.
Css In Js (Vanilla-Extract)
- 자바스크립트안에서 css스타일을 작성하고 조작하는 방법을 css in js라고 한다.
- css in js는 자바스크립트의 변수와 함수를 활용해서 동적인 스타일링을 가능하게 한다.
- 이 스타일코드는 런타임에 해석된다.(미리 css를 추출을 할 수 있는 라이브러리도 있다.)
- colocation - 컴포넌트 파일에 관련된 코드들을 함께 두는 방식이다.
- 지역 스코프 스타일이라서 class 이름의 충돌을 걱정하지 않아도 된다.
- 하지만 css in js는 런타임에 js파일이 해석되면서 style을 생성하기 때문에 style의 규모가 크고 빈번할 수록 성능이 저하된다는 단점이 있다.
- 이러한 단점을 해결하기 위해서 zero-runtime css in js인 Vanilla Extract이 생겼다.
- 런타임이 아닌 빌드때 css를 생성하고 생성된 css를 브라우저에 전달해서 적용하는 작업이다.이렇게 하면 런타임 오버헤드를 막을 수 있다.
- vanilla extract는 타입스크립트를 사용해서 하는 css in js이다. 타입스크립트이기 때문에 타입 안정성을 지킬 수 있다.
- 단점은 개인적으로 러닝커브가 제일 클 것 같다는 점과 빌드 때 css를 생성하기 때문에 빌드 설정을 해주어야 한다는 번거로움이 있다. 하지만 러닝커브가 그렇게 높을것 같지도 않고, 새로운 도구를 사용하는데 설정하는것은 단점으로 꼽기 애매할 뿐더러 공식문서에 방법이 잘 나와있고 많은 번들러를 지원하고 있어서 내가 사용하는 번들러에 맞게 쓰면 될 것 같다는 생각이다.
그래서 어떤걸로 골랐냐면
글을 작성하기 전에는 무조건 tailwind를 사용해보려고 했다. atomic디자인에 대해서 조금 더 알아보고 싶었고 깊게 해보고 싶었던것과, 많이 사용하는것에는 이유가 있으며 많이 사용하기 때문에 참고할 문서들이 많다는 생각이고, class명을 직관적으로 쓸 수 있기 때문에 너무 좋을것 같았다. 그리고 예전에 보았던 css in js 방식중에 styled-component를 보고 복잡해 보이고, 문서가 지저분해 보인다는 개인적인 생각 때문에 css in js방식은 거리감도 있었다.
하지만 이번에는 vanilla extract을 사용해 보려고 한다. 이유는 다음과 같다.
- 기존 css in js의 단점인 런타임 오버헤드를 해결했음
- Sprinkles, Recipes를 활용하여 확장성을 높일 수 있음
- 타입스크립트로 type-safe하게 style을 작성할 수 있음
마치며
이번에는 어떤 방식으로 css를 작성할 것인지 생각해보았다. 아토믹 디자인과 css가 브라우저에 적용될 수 있는 방법, 런타임 css와 zero runtime에 대해서 포스팅하면 좋을것 같다는 생각을 했다.
참고
https://wonny.space/writing/dev/hello-tailwind-css
https://www.daleseo.com/tailwind/
https://fe-developers.kakaoent.com/2022/221013-tailwind-and-design-system/
https://junghan92.medium.com/번역-우리가-css-in-js와-헤어지는-이유-a2e726d6ace6
https://velog.io/@keumky1/Vanilla-Extract란-무엇인가#recipes로-좀-더-깔끔하게-스타일링하기
