티스토리 뷰
😇 CSS Never...
개발자들의 고민은 가지각색이겠지만 대부분의 고민은 이름 짓기가 가장 고민이 크다.
변수, 함수명, 클래스명 등등.. 프론트엔드 입장에선 CSS를 작업해야 하는 경우 CSS 클래스명에 대한 고민도 크다.
CSS 클래스명을 소홀히 하게되면 하나의 엘레멘트를 수정하게 되었을 때 사이드 이펙트로 다른 엘레멘트도 의도치 않게 수정하게 된다.
때문에 대안으로 나왔던 방법들이 BEM, OOCSS, SMACSS 같은 CSS 방법론들이다.
하지만 이러한 방법론들을 쓰더라도 클래스명을 짓는 데에 대한 시간적 고민은 해소되지는 않는다.
최근 작업하면서도 팀 내엔 프론트엔드는 2명밖에 없는데 작업량은 너무 많았다.
시간적 여유가 없는 입장에서 손꼽은 건 기능 개발과 별개로 CSS작업을 하는 시간이 아쉬운 부분이 있었다.
처음에는 쉽다고 느끼지만 데이터가 많거나 복잡한 페이지를 만들게 되면 이만큼 난해하고 노가다성인 것도 없을 것이다.
그만큼 클래스명에 대한 고민도 많아지고 깊어진다.
우리 팀도 마찬가지였고 이에 대한 비용을 해소하고자 고민하고 있던 와중이었다.
😮 깨우치다
연말이 되면 시기적으로 빅테크 기업들이 하나둘씩 컨퍼런스를 진행한다.
때문에 오전에 시간을 내어 팀원과 같이 컨퍼런스를 시청하는 시간을 가지고 있었는데 만났다..
functional css와 figma를 이용한 디자이너와의 웹프론트 협업 이야기 (feat. AdorableCSS)
카카오의 컨퍼런스인 if(kakao) 2021에서 유용태 님의 세션을 듣게 되었고 많은 내용 중 우리를 일깨워 주었던 부분은
- CSS 클래스명은 의미기반이 아닌 시각적 기능에 기반한 이름을 지은 변하지 않는 단일클래스를 작성하자
- 변하지 않는 CSS를 먼저 만들어두고 HTML에서 스타일을 조립해서 작성하자
- 의미가 없는데 의미를 부여하여 이름을 짓는 건 너무 힘들다.
- 위와 같은 의미 있게 지은 이름들은 다른 곳에서 재사용하기 힘들다. (다른 곳에서는 그곳에 맞는 의미를 부여했기 때문)
이후에도 많은 부분을 언급해 주셨고 이러한 패러다임은 우리의 마음을 뺏어가기에 충분했다.
또한 재사용되는 엘레멘트의 클래스를 지어서 사용한다는 건 SPA에서는 해당 엘레멘트는 컴포넌트 화가 될 수 있고
컴포넌트를 생성 시 의미 있는 컴포넌트명을 짓기 때문에 CSS 클래스 명의 의미부여 또한 해소될 수 있다고 생각했다.
굳이 CSS 클래스명 + 컴포넌트명 두 번의 의미론적인 이름을 지을 필요는 없다.
🔨 프로젝트 시작과 CSS framework 도입
최근 다른 서비스 마이그레이션 프로젝트를 새로 시작하게 되었다.
이전 마이그레이션 프로젝트와 다르게 새로 도입할 부분들을 고민하던 중 Tailwind CSS를 도입을 고민하고 있었다.
vue-styled-components, css modules도 고려하였지만 기존의 결정대로 Tailwind CSS를 도입하기로 결정하고
Nuxt.js 문서와 Tailwind CSS 문서를 보던 도중 두 사이트의 디자인이 유사하다는 걸 느끼고
Nuxtjs.org의 Tailwind 세팅이 궁금하여 Nuxtjs.org Github에 들어가 보았다.
근데 당연히 있을 것 같았던 tailwind.config.js는 없었고 windi.config.js가 있었다.
😎 Windi CSS.. 누구냐 넌!
Windi CSS는 2020년 릴리즈 된 신생 CSS Framework이다.
Tailwind CSS와 같은 utility-first CSS Framework이며 양쪽 모두 Nuxt.js에서 초기 프로젝트 빌드시 템플릿 지원이 된다.
특이점은 태생부터 Tailwind CSS의 대체제로 나왔으며 Tailwind CSS 2.0을 계승하여 만들어졌다.
(Tailwind CSS의 최신 버전은 2021년 11월 버전 3.0 릴리즈)
그런 만큼 문법적으로 상당히 비슷하며 문서 또한 둘 다 잘 되어있다.
👏 왜 Windi CSS인가?
그렇다면 대체제라고 자처하는 만큼 더 나은 점이 무엇인가 찾아보면
- Class Grouping
<!-- Windi CSS -->
<div class="bg-white dark:hover:(bg-gray-800 font-medium text-white)"/>
<!-- Tailwind CSS -->
<div class="bg-white dark:hover:bg-gray-800 dark:hover:font-medium dark:hover:text-white"/>
- Shortcut (공통 클래스 선언)
// windi.config.js
export default {
theme: {
/* ... */
},
shortcuts: {
'btn': 'py-2 px-4 font-semibold rounded-lg shadow-md',
'btn-green': 'text-white bg-green-500 hover:bg-green-700',
},
}
💡 이외 차이점은 아래의 링크에 있으며 Tailwind CSS 3.0전의 비교 부분이라 클래스 + 수동 값
항목은 Tailwind CSS 3.0에도 추가되었습니다.
차이점 정리
- Tailwind CSS 사용하던 개발자가 속도측면에 대한 이슈를 해결하고자 만든 만큼 성능적인 측면도 우위가 있다. (참고: Windi CSS 태생에 대하여)
- 실제 간단 수정을 했을 경우 빌드 타임 차이가 있음
- Nuxt.js & Tailwind CSS 템플릿으로 CSS 수정을 하려니 빌드 타임이 너무 오래 걸림
- 해당 이슈에 대해서도 인지를 했는지 JIT라는것을 이용해서 이슈를 해결하고자 하는 듯함
- JIT mode를 사용하면 확실히 빌드 타임이 줄어듦 → 근데 왜 기본 템플릿에는 안 넣었는지는 의문
🙌 결론
- Nuxt.js 공식에서도 사용하고 스페셜 스폰서로 있는 만큼 좀 더 특화될 느낌이 있어서 쓰는 것이 좋아 보인다.
- 상대적으로 작은 Vue 커뮤니티의 서드파티 라이브러리 중 괜찮은 스타수를 받고 있어서 안정적으로 사용이 가능하다.
- 차별화된 기능들이 있기 때문에 Tailwind CSS보다 좀 더 유리한 측면들이 있다.
- 로고가 더 이쁨(?)
현재 프로젝트를 시작하며 사용하는 중이며 개발경험은 상당히 만족스럽고 익숙해진다면 생산성 또한 높아질 것으로 예상되어 꾸준히 사용할 생각이다.
아래는 카카오 웹툰에서도 왜 utility-first CSS Framework 도입했는지에 대한 글입니다.
'Vue' 카테고리의 다른 글
🙌 Vue Custom Snippets 만들기 (2) | 2022.02.06 |
---|---|
🔨 TODO ! - 컴포넌트 분리하기 (feat. 상태관리(state), function) (0) | 2022.02.01 |
🖼️ TODO ! - 컴포넌트 분리하기 (feat. component, props) (0) | 2021.12.27 |
📝 TODO ! - 컴포넌트 import, state 선언 (1) | 2021.12.23 |
📒 TODO ! - 형태 알아가기 (0) | 2021.12.20 |
- Total
- Today
- Yesterday
- 개발자회고
- postman
- 공공데이터포털
- function
- vue3
- 오물오물
- vue
- nodejs
- 리액트
- CORS
- font-family
- vue예제
- vue입문
- 프론트엔드면접
- VanillaJS
- INPUT
- inline
- 공공데이터
- CSS
- 프론트엔드개발자
- 프론트엔드회고
- baegofda
- 프론트엔드
- 생활코딩
- HTML
- axios
- JavaScript
- cssom
- react
- 노드JS
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |