Closed hyeyoonS closed 5 months ago
Vanilla-Extract는 Runtime CSS in JS의 문제점을 해결하기 위해 등장했습니다. CSS-in-JS는 런타임에 js 파일이 실생되면서 style을 생성하는데 이는 성능 저하의 원인이 될 수도 있습니다. 이를 해결하고자 빌드타임에 스타일 파일을 생성하는 제로 런타임 CSS가 등장하게 된 것입니다. 제로 런타임인 이유는 런타임에 생성되지 않고 빌드 타임에 CSS가 생성되기 때문입니다. 빌드 타임에 CSS 파일로 변환되고 head에 삽입되기 때문에 bundle 설정이 필수입니다.
바닐라 익스트랙트 제로 런타임 CSS를 사용한 이유는 CSS-in-JS의 성능 저하 문제를 해결하고, 다양한 편의 문법을 지원하기 때문에 선정하게 되었습니다.
이점
제로런타임? Build 타임에 미리 CSS 를 생성해두는 방식을 바로 Zero Runtime 이라고 한다. 즉, 런타임 이전에 미리 필요한 CSS 를 빌드 시점에 생성하여 제공하는 형식이다.
Vanilla Extract는 CSS-in-JS의 대안이 되나요? 네, Vanilla-Extract는 CSS-in-JS의 한 대안으로 볼 수 있습니다. CSS-in-JS 방식은 주로 스타일을 JavaScript 내에서 관리하며, 런타임에 스타일을 동적으로 생성하고 적용합니다. 반면, Vanilla-Extract는 이러한 과정을 빌드 타임에 처리하여 런타임에는 추가적인 성능 비용 없이 순수한 CSS 파일을 사용합니다. 이런 점에서 Vanilla-Extract는 성능 면에서 유리합니다
Vanilla-extract는 CSS-in-JS 라이브러리의 대안으로, 스타일 시트를 TypeScript 또는 JavaScript에서 작성할 수 있게 해주면서도, 런타임에서 추가 작업 없이 순수 CSS 파일로 컴파일하는 방식을 제공한다. 다음과 같은 주요 이점을 지닌다.
제로 런타임은 스타일이 클라이언트 측에서 처리되는 작업 없이, 빌드 과정에서 완전히 CSS로 컴파일된다는 의미. 이는 런타임에 JavaScript로 스타일을 계산하거나 적용하는 작업이 전혀 없다는 것을 뜻하며, 이로 인해 성능 개선 및 초기 로드 시간 단축이 가능해진다.
대안으로 사용될 수 있다. CSS-in-JS는 일반적으로 런타임에 스타일을 적용하는데, 이는 JavaScript 오버헤드를 발생시킬 수 있다. 반면, vanilla-extract는 빌드 타임에 CSS로 컴파일되어 런타임에 추가 리소스를 요구하지 않으므로, 성능이 민감한 애플리케이션에서 유용.
이러한 접근 방식은 개발자가 JavaScript의 편리함을 유지하면서도 런타임 성능 저하 없이 CSS를 관리할 수 있게 해 줌. 따라서, vanilla-extract는 특히 성능 최적화가 중요한 대규모 프로젝트에서 CSS-in-JS의 훌륭한 대안이 될 수 있다.
왜 Vanilla-Extract를 사용했나요?
이전에 CSS-in-JS인 Styled-component를 사용한 경험이 있습니다. 그런데 Styled-component는 런타임에 스타일이 결정되기에, 브라우저가 JavaScript를 해석하고 실행하는 시간과 ↔ 렌더링 엔진이 스타일을 적용하는 시간이 겹치면서 깜빡임과 함께 스타일이 잠깐 적용되지 않는 이슈가 있었습니다. 이에 대한 대안으로 제로런타임 CSS 라이브러리가 등장하였다는 것을 알게된 후, 학습과 함께 제로런타임 CSS를 직접 경험해보고 싶은 마음에 선택하게 되었습니다.
이점이 뭐죠? 제로 런타임의 뜻은 뭔가요? Vanilla-extract는 빌드 타임에 스타일을 처리하고 CSS 파일로 번들링하기 때문에 런타임 오버헤드가 거의 없습니다. 따라서 [제로런타임]이라고 표현합니다. 빌드 타임에 CSS파일을 번들링하면 브라우저가 스타일 시트를 로드하는 데 필요한 시간을 줄일 수 있어서, 초기 로딩 시간을 단축할 수 있습니다.
Vanilla-extract는 CSS-in-JS의 대안이 되나요?
완벽한 CSS-in-JS의 대안이 되지는 못할 것 같습니다. 아직 CSS-in-JS가 널리 사용되고 있기에, CSS-in-JS를 적용한 라이브러리를 사용하면 라이브러리에서 제공하는 스타일이 런타임에 덮어 씌워지는 문제가 있었습니다. 따라서 스타일 커스텀을 하려면 런타임에 커스텀 하도록 별도의 CSS파일을 생성해야 했고, 이는 코드의 일관성 유지와 유지·보수에 어려움이 있다고 생각됩니다.
CSS-in-JS는 js문법이 사용가능하여 동적인 css를 구현하는데 편리하고 className이 겹치지 않는다는 장점이 있습니다. 하지만 런타임에 자바스크립트 코드를 해석하고 css로 변환해야 하기 때문에 속도가 느린 이슈가 있습니다. 개인적으로 컴포넌트처럼 사용하는 형식이 실제 컴포넌트와 구분이 잘 안 되어 가독성도 떨어졌습니다. 제로 런타임의 이점이 있어 vanilla-extract를 사용했습니다.
📎 질문
왜 Vanilla-Extract를 사용했나요? 이점이 뭐죠?
제로 런타임의 뜻이 뭔가요?
Vanilla Extract는 CSS-in-JS의 대안이 되나요?
✏ 구술 답변 키워드
✏ 서술 답변
(아래는 의견에 따라 답변) Vanilla Extract는 CSS-in-JS의 대안이 되나요?
1번 답변 : 예. 런타임 오버헤드와 리소스 로딩시간 감소와 같은 성능적인 장점과 서버컴포넌트와의 궁합, 타입안정성이 좋다는 장점을 가지고 있기 때문에 CSS in JS의 대안 또는 개선안이 될 수 있는 스타일링 트렌드라고 생각합니다.
2번 답변 : 아니오. 런타임 스타일링의 한계가 있어 완전한 대안으로 보기 어렵습니다. 새로운 css 변수를 런타임에 생성하는데 제한이 있으며, CSS in JS 방식의 외부 라이브러리 사용시 바닐라 익스트랙으로 적용해둔 스타일이 라이브러리 스타일로 런타임에 덮어씌워지는 문제가 있기에 아직 완전한 대안이 되지 못한다고 생각합니다.
타입안정성을 Vanilla-Extract만 보장하느냐? (X) 스타일드컴포넌트도 타입스크립트와 사용하면 타입안정성O 자동완성O *근데 왜 Vanilla Extract ? => 라이브러리가 CSS파일을 타입스크립트에서 직접 생성하기때문에 더 직접적으로 코드와 스타일을 연동해줌 => 더욱 안정성 보장함!