Tailwind에서 벗어나며 CSS 구조화 배우기

(jvns.ca)

7P by GN⁺ 15일전 | ★ favorite | 댓글 3개

몇몇 사이트를 Tailwind에서 시맨틱 HTML과 바닐라 CSS로 옮기며, Tailwind가 제공하던 규칙 중 필요한 것만 직접 재구현함
Tailwind의 preflight reset, 색상 팔레트, font scale처럼 익숙한 시스템은 유지하되 CSS 변수와 파일 분리로 바닐라 CSS에 옮겨 담음
CSS 대부분은 컴포넌트별 파일로 나누고 고유 클래스를 둬, 한 컴포넌트 수정이 다른 컴포넌트를 몰래 깨뜨릴 가능성을 줄임
Tailwind를 떠나는 배경에는 최신 Tailwind의 빌드 시스템 의존성, 2.8MB tailwind.min.css, 바닐라 CSS와의 혼재, CSS 제약이 있음
반응형 설계는 breakpoint보다 CSS grid의 auto-fit, grid-template-areas를 더 활용하려 하며 @layer, @scope, container queries도 학습 대상으로 삼음

Tailwind에서 배운 구조를 바닐라 CSS로 옮기기

8년 전 Tailwind를 처음 쓸 때는 CSS 코드를 어떻게 구조화해야 할지 몰랐고, 완전한 혼란보다 Tailwind가 훨씬 나은 선택이었음
최근 약 일주일 동안 몇몇 사이트를 Tailwind에서 시맨틱 HTML + 바닐라 CSS로 옮기며, Tailwind가 제공하던 규칙 중 필요한 부분만 직접 선택해 재구현하게 됨
A whole cascade of layers와 How I write CSS in 2024를 읽으며, 모든 CSS 코드베이스에는 레이아웃·폰트·색상·공통 컴포넌트 같은 서로 다른 관심사를 관리할 시스템이 필요하다는 점이 분명해짐
Tailwind에는 reset stylesheet, 색상 팔레트, font scale 같은 시스템이 이미 있었고, 익숙하고 유용한 부분은 바닐라 CSS에서도 모방할 수 있음

CSS 코드베이스에 둔 주요 시스템

reset
- Tailwind의 preflight styles를 tailwind.css에서 처음 약 200줄 복사해 사용함
- Tailwind reset에 오래 익숙해져 있었고, 모든 요소에 box-sizing: border-box를 적용하는 규칙은 요소의 너비가 padding을 포함하게 만듦
```
  * { box-sizing: border-box; }
```
- html {line-height: 1.5;} 같은 다른 reset 규칙에도 무의식적으로 의존하고 있을 가능성이 있으며, 이런 규칙 없이 CSS를 쓰려면 큰 적응이 필요해 보임
components
- CSS 대부분은 Vue나 React 컴포넌트와 비슷한 방식으로 컴포넌트별 파일에 정리함
- 각 컴포넌트는 고유 클래스를 갖고, 한 컴포넌트의 CSS가 다른 컴포넌트의 CSS를 덮어쓰지 않도록 구성함
- 실제로 바꾸고 싶은 CSS의 약 80%가 컴포넌트 파일 안에 있어, 100줄짜리 컴포넌트를 편집할 때는 그 100줄만 생각하면 됨
- 예를 들어 .zine 컴포넌트는 다음과 같은 HTML을 가질 수 있음
```
  <figure class="zine horizontal">
      <img src="whatever.jpg">
  </figure>
```
- CSS는 중첩 선택자로 .horizontal, .vertical, :hover 같은 상태를 컴포넌트 내부에 모음
```
  .zine {
    ...
    &.horizontal {
      ...
    }
    &.vertical {
      ...
    }
    &:hover {
      ...
    }
  }
```
- Web Components나 @scope처럼 컴포넌트 간 간섭을 프로그램적으로 막지는 않았지만, 관례를 정해 지키는 것만으로도 크게 나아진 느낌을 줌
colours
- colours.css에는 필요할 때 사용할 수 있는 CSS 변수를 모아 둠
- 색상은 어렵고 이번 리팩터링에서 색상 사용을 다시 검토하고 싶지 않았기 때문에 기존 방식을 유지함
- 유일한 규칙은 사이트에서 쓰는 모든 색상을 이 파일에 나열하는 것임
```
  :root {
    --pink: #fea0c2;
    --pink-light: #F9B9B9;
    --red: #f91a55;
    --orange: rgb(222, 117, 31);
    ...
  }
```
font sizes
- Tailwind에서는 text-lg, xl, 2xl처럼 크기 단계를 고르면 됐기 때문에 em, px, rem 중 무엇을 쓰는지 기억할 필요가 없었음
- 이를 바닐라 CSS에서도 유지하기 위해 Tailwind에서 가져온 크기 변수를 정의함
```
  --size-xs: 0.75rem;
    --line-height-xs: 1rem;

    --size-sm: 0.875rem;
    --line-height-sm: 1.25rem;
```
- 폰트 크기는 변수로 지정하며, Tailwind보다 조금 장황하지만 현재로서는 만족스러운 방식임
```
  h3 {
    font-size: var(--size-lg);
    line-weight: var(--line-weight-lg);
  }
```
utilities
- 여러 컴포넌트에서 반복되는 버튼 같은 요소는 utilities로 분류함
- 스크린리더 사용자에게만 보여야 하는 요소를 위한 .sr-only 같은 일부 유틸리티 클래스는 Tailwind에서 복사함
- 이 영역은 작게 유지하고, 변경할 때 조심하려 함
base
- “base” 스타일은 사이트 전체에 직접 적용하는 스타일임
- 사이트 전체에 많은 스타일을 강제할 만큼 확신이 없기 때문에 이 영역은 매우 작게 유지함
- 현재 괜찮다고 느끼는 규칙은 <section>과 a 두 가지이며, <section> 규칙은 나중에 바뀔 수 있음
```
  /* put a 950px column in the middle of each <section> */
  section {
    --inner-width: 950px;
    padding: 3rem max(1rem, (100% - var(--inner-width))/2);
  }

  a {
    color: var(--orange);
  }
```
- base 스타일은 처음에는 거의 비워두고, 공통으로 원하는 것을 찾을 때 컴포넌트에서 base로 옮기는 상향식 방식이 가장 쉬워 보임
spacing
- padding과 margin을 관리하는 방식은 아직 완전히 정해지지 않았음
- Tailwind를 쓸 때는 원하는 모양이 나올 때까지 padding과 margin을 여기저기 즉흥적으로 넣었고, 지금은 그보다 더 원칙적인 방식을 찾고 있음
- 현재는 가능한 한 바깥 레이아웃 컴포넌트가 간격을 책임지도록 하려 함
- 여러 자식을 가진 <section>에서 자식 사이를 균일하게 띄우고 싶을 때는 다음 규칙을 사용할 수 있음
```
  section > *+* {
    margin-top: 1rem;
  }
```
- 참고한 자료로 the owl selector와 “no outer margin”이 있음
responsive design
- Tailwind에서는 md:text-xl처럼 특정 크기 이상에서 text-xl 스타일을 적용하는 미디어 쿼리 기반 문법을 많이 사용했음
- 지금은 breakpoint를 많이 쓰지 않아도 되는 더 유연한 CSS grid 레이아웃을 만들려고 함
- auto-fit을 사용하면 큰 화면에서는 2열, 작은 화면에서는 1열을 자동으로 사용할 수 있음
```
  display: grid;
    grid-template-columns: repeat(auto-fit, minmax(min(100%, 400px), max-content));
    justify-content: center;
```
- grid-template-areas도 많이 사용했으며, Tailwind로는 사용할 수 없다고 보는 뛰어난 기능임
- 참고한 자료로 CSS Tricks의 A responsive grid layout with no media queries가 있음
build system
- 개발 중에는 별도의 빌드 시스템이 필요하지 않음
- CSS에는 내장 @import 문이 있어 파일을 나눠 가져올 수 있음
```
  @import "reset.css";
  @import "typography.css";
  @import "colors.css";
```
- CSS에는 중첩 선택자도 내장되어 있음
```
  .page {
    h2 { ...}
  }
```
- 프로덕션용으로 CSS 파일을 묶고 싶다면 esbuild를 사용할 수 있음
```
  esbuild style.css --bundle --loader:.svg=dataurl  --loader:.woff2=file --outfile=/tmp/out.css
```
- 보통 CSS와 JS 빌드 시스템 사용을 피하지만, esbuild는 웹 표준 기반이고 정적 Go 바이너리이기 때문에 괜찮다고 봄
- esbuild에 대해서는 2021년에 esbuild와 Vue 관련 글을 쓴 적이 있음

Tailwind에서 벗어나는 이유

Tailwind는 2018년 이후 빌드 시스템 의존성이 훨씬 커졌고, 최신 Tailwind를 빌드 시스템 없이 쓰는 것은 불가능해 보여 수년간 Tailwind v2를 사용해 왔음
빌드 시스템 없이 Tailwind를 쓰는 대안으로 litewind가 있는 것으로 보임
Tailwind는 원래 빌드 시스템과 함께 쓰는 것이 전제였지만, 실제로는 그렇게 하지 않았기 때문에 많은 프로젝트에 2.8MB짜리 tailwind.min.css 파일이 남아 있었고 다소 어색하게 느껴짐
Tailwind를 처음 쓸 때보다 CSS 실력이 더 좋아짐
Tailwind에는 결국 제약이 있으며, CSS에서 이상하거나 특수한 작업을 하고 싶을 때 항상 가능하지는 않음
그런 제약은 매우 유용할 수 있고, 실제로 바닐라 CSS로 옮기면서 Tailwind의 일부 제약을 다시 구현하고 있지만, 이제는 필요한 제약만 골라 쓰고 싶어짐
같은 프로젝트 안에서 바닐라 CSS와 Tailwind가 섞인 사이트들이 생겼고, 이를 유지보수하는 것이 즐겁지 않았음
더 시맨틱한 HTML을 작성하면 어떤 느낌인지 궁금했음

앞으로 배워보고 싶은 CSS 기능

@layer는 cascade layer를 다루는 기능으로, 아직 사용하지 않았지만 배워보고 싶은 기능임
@scope는 컴포넌트나 특정 범위 안의 스타일을 다루는 데 관심이 가는 기능임
container queries는 컨테이너 기준 반응형 설계를 위한 기능으로 배워보고 싶음
subgrid는 CSS grid 관련 기능으로 관심 목록에 있음

Tailwind를 완전히 부정하지 않는 결론

지금은 Tailwind에서 벗어나고 있지만, Tailwind를 쓰기 시작한 것 자체는 여전히 만족스러움
Tailwind를 사용하면서 많은 것을 배웠고, tailwind.min.css를 삭제한 뒤에도 사이트 안에서 Tailwind의 일부를 계속 사용할 수 있음
wizardzines.com의 CSS를 원래 설계하고 작성한 Melody Starling 덕분에 사이트의 멋지고 재미있는 부분이 만들어졌음
CSS 작업 중 CSS Tricks, Smashing Magazine 등에서 많은 CSS 글을 읽었고, CSS 커뮤니티가 실천 방식을 많이 공유해 큰 도움이 됨

GeekNews Weekly에 포함된 글입니다. 에디터 코멘트 보기

▲

shakespeares 13일전 [-]

zero-config로 변경되면서 좀 더 낫지 않나요?

답변달기

▲

GN⁺ 14일전 [-]

Hacker News 의견들

의미론적 HTML과 접근 가능한 마크업을 오래 가르쳐 왔고, 스크린 리더용 사이트와 앱도 많이 다뤄 봤는데 Tailwind의 가장 큰 문제는 HTML과 CSS를 생각해야 하는 순서를 뒤집는 데 있음
HTML은 문서의 의미를 표시하는 것이므로 거기서 시작하고, 그다음 CSS로 스타일링해야 함. 스타일 때문에 추가 요소가 필요하면 div나 span을 쓸 수 있지만 먼저 더 나은 요소가 있는지 고민해야 함
Tailwind는 개발자를 CSS 우선 접근으로 밀어 넣어서, 원하는 Tailwind 클래스를 먼저 생각하고 그 클래스를 걸기 위해 DOM에 또 다른 div를 넣게 만듦
웹 개발자의 역량에는 미래에도 읽기 좋고, 모든 사용자가 쓸 수 있으며, HTML/CSS 명세와 대체로 맞는 HTML과 CSS를 만드는 능력이 포함돼야 하는데 Tailwind는 그 면에서 실력을 떨어뜨림. Tailwind 웹사이트의 첫 예제도 div와 span뿐이고, 새 개발자에게 나쁜 교육이 되었으며 LLM이 별도 지시 없이는 div 수프를 뱉어내는 흐름에도 기여했다고 봄
- Tailwind 자체가 접근성 없는 앱이나 div 수프를 강제하는 건 아닌데, 개발자의 무관심이나 이해 부족을 Tailwind 탓으로 돌리는 건 불공평함
  어떤 도구든 잘못 쓸 수 있고 Tailwind도 예외는 아님. CSS를 약 20년 썼고 Less, SASS/SCSS, Stylus, PostCSS도 써 봤지만 최근 몇 년간 Tailwind에 정착한 이유는 오히려 더 견고한 애플리케이션 스타일링을 가능하게 해주기 때문임
  스타일/클래스 추상화를 과하게 만들지 않아도 되고, 영향을 받는 마크업에 스타일을 바로 두면 인지 부담이 줄며, 느슨한 선택자가 의도치 않게 스타일을 바꾸는 일도 줄고 디버깅도 쉬워짐. 맞춤 CSS 프레임워크가 있는 코드베이스보다 Tailwind 코드베이스가 단순한 사이트/앱을 제외하면 덜 복잡하고 덜 취약한 경우가 많음
  일관된 글꼴·색상·크기 척도, 더 작은 번들, Tailwind를 아는 개발자 간의 일관성, 탄탄한 생태계와 LLM 친숙도까지 고려하면 많은 팀에 훌륭한 선택지임. 결국 대부분의 도구처럼 누가 쓰느냐에 따라 잘 쓰일 수도, 못 쓰일 수도 있음
- 그 접근에는 어느 정도 순수성/정확성에 대한 열망이 있는데, 나는 오래전에 내려놨음
  HTML/CSS/JS의 난장판은 브라우저를 대상으로 할 때 필요한 악으로 보고, 내게는 그냥 표현 계층일 뿐임. 업무에서는 데이터베이스 스키마나 백엔드 비즈니스 로직의 정확성에 훨씬 더 중점을 둠
  지저분한 표현 계층은 가능한 적게 쓰면서도 어느 정도 유지보수 가능한 코드가 나오면 충분하고, 그 목적에는 Tailwind가 잘 맞음. LLM이 잘 작성하고, 새 개발자가 빨리 이해하며, 나중에 읽고 고치기도 꽤 쉬움
  Tailwind 프로젝트가 새 개발자가 HTML/CSS를 배우는 최선의 방법은 아니라는 데는 전적으로 동의하지만, 새 개발자가 좋은 데이터베이스 스키마, 직관적인 API, 테스트 가능한 비즈니스 로직 등에 집중하는 편을 더 선호함
- 반론을 몇 가지 들면, 원칙적으로 마크업과 스타일을 분리하는 건 좋지만 특정 구현에는 어차피 추가 마크업이 필요하고 이는 2000년대 초반부터 알고 있던 사실임
  Tailwind 자체에는 적절한 HTML 태그 대신 div와 span을 쓰도록 강제하는 요소가 없음
  문서와 인터페이스는 다르고, Tailwind는 인터페이스에서 훨씬 더 말이 됨. 인터페이스에는 Tailwind를 쓰고 다른 콘텐츠에는 범위가 제한된 HTML 선택자를 쓸 수 있음
  복잡한 CSS 코드베이스를 작성하는 것보다 Tailwind가 약 4배 빠르고 사실상 오버헤드가 없다는 점은 어떤 평가를 하든 장점으로 남음
- Inverted Triangle CSS(ITCSS) 가 더 널리 쓰이지 않는 게 아쉬움. 캐스케이드를 거부하는 대신 받아들이고 개발자에게 유리하게 작동하게 만듦
  요약하면 CSS를 명시도 순서로 작성하는 방식임:
  /scss/
  ├── 1-settings. <- 전역 설정
  ├── 2-design-tokens <- 글꼴, 색상, 간격 등
  ├── 3-tools <- Sass 믹스인, CSS 함수 등
  ├── 4-generic <- 리셋, 박스 크기, 정규화 등
  ├── 5-elements <- 제목, 버튼, 링크의 기본 스타일
  ├── 6-skeleton <- 레이아웃 그리드 등
  ├── 7-components <- 카드, 캐러셀 등
  ├── 8-utilities <- 유틸리티와 헬퍼 클래스
  ├── _shame.scss <- 나중에 고칠 해킹
  └── main.scss
  ITCSS는 CSS 코드베이스에서 명시도 싸움을 사실상 없애 줌. 보통 !important가 들어가는 유일한 곳은 유틸리티 계층임
  [1]: https://matthiasott.com/notes/how-i-structure-my-css
- Tailwind를 쓴다고 접근성을 본질적으로 포기하게 되는 건 아님. 어떻게 그런 결론에 도달했는지 모르겠음
  컴포넌트 라이브러리를 보면 aria 속성도 포함해 줌: https://tailwindcss.com/plus/ui-blocks/marketing/sections/pr...
  랜딩 페이지처럼 디지털 브로슈어에 가까운 것이 아니라면 항상 마크업부터 시작하고 그 위에 CSS 클래스를 추가함
Tailwind의 좋은 점 두 가지는 AI 학습 데이터에 클래스 정보가 이미 많고, 스타일 충돌이 없다는 것임
그래서 AI가 새 스타일을 만들 때 기존 스타일시트를 참조할 필요가 없어 문맥 관리에 좋음
맞춤 CSS에서는 AI가 기존 스타일시트를 읽어야 충돌이나 중복 작성이 줄어드는데, 큰 스타일시트는 AI의 메모리 공간을 많이 차지해서 문제가 될 수 있음
Julia Evans의 글을 정말 좋아함
취약함과 솔직함의 자리에서 글을 씀. 많은 사람은 똑똑해 보이려고 쓰지만, Julia는 “나도 다 아는 건 아니지만 발견한 것 중 나누고 싶은 게 있다”는 태도로 씀. 직접 알지는 못해도 사랑하는 사람들에게 무언가를 나누는 것처럼 느껴질 정도임
마지막 Strange Loop에서 Randall Munroe와 함께 발표했는데, 발표 후 그와 이야기하려고 기다린 사람들도 있었지만 나는 Julia와 이야기하려고 기다렸음. bash 스크립트를 Perl로 다시 쓰라는 내 농담을 이해하지 못한 것 같아 진심으로 미안함
- 그 표현이 딱 맞음
  나는 Julia는 아니지만, 공개 발표나 프레젠테이션에 대해 거의 같은 철학을 갖고 있고 발표를 어려워하는 동료들에게도 심어 주려 해 왔음. 동료와 사랑하는 사람들에게 내가 조금 더 익숙한 지식, 그리고 그들에게 도움이 될 수 있는 것을 전할 수 있다는 건 큰 특권임
CSS Modules는 캐스케이딩 문제에 대한 더 단순한 해법임. 고유한 클래스명을 만들어 클래스 충돌을 막아 줌 [1]
Tailwind의 두 가지 큰 단점인 가독성 [2]과 도구 지원도 없음. 특히 Chrome과 FireFox DevTools에서 디버깅하고 대화식으로 실험하는 도구 지원이 더 낫다고 봄
[1] https://x.com/efortis/status/1888304658080256099
[2] https://github.com/ericfortis/tailwind-eye
Tailwind에서 늘 인상적이었던 건 지지자들의 거의 모든 논거가 결국 “CSS를 주니어 수준 이상으로 배운 적이 없다”로 귀결된다는 점임
“Tailwind가 없으면 커다랗고 정리 안 된 CSS 파일 하나가 통제 불능으로 커지고, 오래된 코드와 !important가 가득해질 것” 같은 말을 흔히 듣는데, CSS도 다른 기술 역량처럼 하나의 기술임
딱 보기 맞게 만들 수 있을 만큼만 배우고 땜질만 한다면, 야망이 코드를 정리할 능력을 아주 빨리 앞질러 버림
- 그보다 더 나쁨. Tailwind에 대한 흔한 논거는 CSS가 어떻게 작동하도록 만들어졌는지에 대한 완전한 무지와, 다른 맥락이라면 개발자들이 숭배할 원칙, 예컨대 반복하지 말라 같은 원칙의 폐기에서 나옴
  Tailwind와 CSS를 두고 이야기하다가 상대가 “캐스케이딩”이 무슨 뜻인지 모를 뿐 아니라, 스타일시트 맥락에서 그 개념이 유용할 수 있다는 생각조차 해 본 적 없다는 걸 깨닫는 순간이 정말 답답함
- 경험 많은 Tailwind 지지자들은 또 다른 온라인 논쟁에 끌려들어 갈 시간에 더 나은 일을 하고 있을 가능성이 큼
  90년대부터 CSS를 많이 써 오다가 Tailwind를 살펴봤고, 이해가 된 뒤로는 순수 CSS를 대부분 피하게 됨. 어떤 의미에서는 하나의 난장판을 다른 난장판으로 바꾸는 셈이지만, 개인적으로는 여러 파일에 걸친 겹치고 모순되는 캐스케이드보다 지역화된 클래스 수프를 다루는 편이 낫다고 봄
  둘 다 깔끔하게 구현할 수 있지만, Tailwind 난장판을 정리하는 편이 CSS 난장판보다 훨씬 낫고 전체 개발 과정도 더 즐겁게 느껴짐
- 틀린 말은 아니지만, 함께 일해 본 “풀스택” 개발자의 압도적 다수는 CSS를 아주 기본 수준만 알고 깊게 배우는 데 관심이 거의 없었음
  나도 20년 넘게 프로그래밍했고 웹 개발도 거의 15년 했지만 CSS를 제대로 배울 동기를 찾기 어렵다. 따라가야 할 기술 역량이 너무 많고 CSS는 내 우선순위에서 꽤 낮음
  전문가에게 맡기고 싶지만 회사들은 전담 프런트엔드 개발자를 뽑으려 하지 않음
- 순수 CSS 코드베이스를 배우는 데 더 많은 노력을 들이는 것보다, Tailwind 코드베이스를 보면 이해하기 쉽지 않나? Tailwind가 더 쉽게 규모를 키운다는 논거의 일부가 바로 그거 아닌가?
- SQL을 감싸는 라이브러리를 쓰는 사람들에게도 같은 말이 적용되지 않나?
잘 확장되는 HTML과 CSS 작성에 초점을 둔 깔끔한 웹 개발 가이드를 쓰고 있음: https://webdev.bryanhogan.com/
여기 사람들에게 유용할지도 모르겠음. 스타일링에는 Tailwind 같은 것을 쓰지 않고, Astro나 Svelte 같은 현대 프레임워크와 CSS만 사용함
모든 프로젝트에 reset.css, var.css, global.css, util.css를 두고, 나머지 스타일은 해당 컴포넌트나 레이아웃에 범위를 제한함
- JavaScript 프레임워크를 쓰면 전체 목적이 좀 무색해지는 것 아닌가?
- 직접 만든 자기만의 Tailwind처럼 들림
좋은 글임
외부 라이브러리 의존성을 제거하고 처음부터 직접 해결책을 만드는 걸 좋아하지만, Tailwind에서는 그렇게 하지 않기로 한 분명한 이유가 있음. 프로덕션 최적화를 제공해서 실제로 필요한 최소한의 CSS만 배포되도록 보장해 주기 때문임
globals.css나 다른 곳에 색상, 간격 등 선택지를 모두 열거해 두어도, 프로덕션에서 그 변형을 전부 쓰는지 걱정할 필요가 없음. Next.js 같은 프레임워크 안에서 작업하면 빌드 시 이 최소화 단계가 자동으로 일어나기까지 하니, 이것만으로도 Tailwind에서 옮기지 않을 충분한 이유가 됨
Tailwind에서 인라인 CSS를 쓸 때 감당하기 어려운 제약을 느낀 적도 없고, Tailwind의 그리드 도구로 화면 폭에 따라 잘 반응하는 그리드를 구현하는 데도 큰 문제가 없었음. 글에서 나온 시나리오들은 Tailwind 또는 Tailwind와 CSS 조합으로 모두 해결해 봤고, grid-column-areas가 기본으로 없는 건 사실이지만 반응형 그리드 레이아웃에서 큰 제약으로 느낀 적은 아직 없음
Tailwind의 가장 큰 문제는 읽는 데 익숙해지는 시간이 오래 걸린다는 점임. 우리는 인라인 CSS는 나쁘고 전역 범위 CSS가 좋다는 식으로 배우며 깔끔한 HTML에 익숙해지는데, 실제 Tailwind 코드, 특히 긴 줄을 보면 처음에는 정말 읽기 어려워 보임. 오래 쓰다 보니 그 모양에 완전히 익숙해졌고, 결국 내게 Tailwind는 더 효율적이고 유지보수 가능하며 심지어 더 읽기 좋다는 결론에 이르렀지만 시간이 꽤 걸렸음
요즘 정말 마음에 드는 접근은 Tailwind와 범위 제한 스타일을 함께 쓰는 것임(Svelte와 Vue에서)
이렇게 하면 Tailwind의 편의는 유지하면서 템플릿 오염을 최소화할 수 있음:
+
{{ count }}
- 나도 마찬가지로 꽤 초기에 이 방식에 정착했음. Tailwind 제작자들이 권장하는 방식과는 어긋나지만, 한 번도 후회한 적 없고 잘 작동함
내게는 Svelte와 LLM이 Tailwind 필요성을 완전히 없애 줬음
알고 보니 Tailwind를 주로 쓰던 이유는 스스로 부과한 제약이 아니라 CSS 충돌 회피와, 나에게 더 논리적으로 느껴지는 문법 때문이었음
- Svelte가 Tailwind에 대한 입장에 왜 영향을 줬는지 궁금함
Tailwind에서 가장 좋은 점은 임시 클래스명을 만들 필요가 없다는 것임. 더 이상 BEM을 쓰지 않아도 됨

답변달기

▲

GN⁺ 15일전 [-]

Lobste.rs 의견들

개인 프로젝트에서는 더 이상 CSS/JavaScript 프레임워크를 거의 쓰지 않음
의존성이 없으면 공급망 취약점도 생길 수 없기 때문임. 물론 취약점은 그 한 종류만 있는 건 아니지만 도움이 됨
- 나도 꽤 순정 HTML/CSS/JS로 돌아왔고, 직접 만든 것만 조금 얹어 쓰는 편임
  프레임워크 피로감, npm audit 과부하, 그리고 LLM 덕분에 구현 방식에 대한 남의 평가를 덜 신경 써도 된다는 점이 합쳐진 결과임. 예를 들면 “왜 React와 Tailwind를 안 쓰냐” 같은 질문들
이건 그냥 CSS가 동작하는 방식임
이걸 모르고 Tailwind를 맹목적으로 쓰는 걸 보면 밖에 나가 구름에 소리치고 싶어짐. 내가 보기엔 Tailwind의 90%는 문법만 다른 인라인 스타일이고, <FONT> 태그보다 한 단계 나은 정도라고 볼 수도 있음
- 이 댓글의 목적은 잘 모르겠지만, 거의 8년 동안 Tailwind를 쓰면서 Tailwind 사용자를 깎아내리는 이런 댓글을 수없이 봤고, 그중 어떤 것도 Tailwind를 벗어나거나 CSS 실력을 키우는 데 도움이 되지 않았음
  이 블로그 글은 내가 실제로 알아야 했던 내용을 설명한 것임
- “Tailwind의 90%는 문법만 다른 인라인 스타일”이라는 건 그다지 정확하지 않음
  Tailwind는 인라인 스타일과는 꽤 다르게 동작하고, 오히려 CSS와 훨씬 비슷함. 글에서도 짚듯이 Tailwind를 잘 쓰게 해주는 좋은 습관 상당수는 효과적인 CSS를 쓰는 데도 필요한 습관임. Tailwind는 모든 요소에 암묵적인 스코프가 있는 CSS 블록을 붙여주되, 독특한 DSL을 쓰는 것에 더 가까움
- CSS가 어떻게 동작하는지 아는 것과 효과적으로 쓰는 법을 아는 건 큰 차이가 있음
  CSS 동작 방식은 잘 알지만, 순정 CSS는 부담스럽고 그래픽 디자인에도 약해서 여전히 Tailwind를 씀. 이 글은 Tailwind를 바탕으로 CSS를 구조화하는 아이디어를 제공함
최근 흐름을 잘 따라가지 못한 입장에서는, 이 글이 현대적인 CSS 관행을 꽤 잘 보여주는 듯함
영감을 받은 글들로 이어지는 링크가 많은 점도 마음에 듦. 읽을거리로 좋아 보이고, 아직은 "no outer margin"만 읽어봤음
다만 기본 스타일을 “아래에서 위로” 잡는 접근에는 조금 회의적임. 달리 뭘 할지는 모르겠고 시도해볼 만해 보이지만, 기본 스타일은 본질적으로 까다로운 편임
이 글이 정말 좋았음
나도 작은 사이트들을 이것저것 많이 만들면서 CSS를 서서히 배웠고, 처음부터 이런 시스템적인 사고를 더 했더라면 도움이 됐을 것 같음. 프레임워크에는 꽤 거부감이 있지만, 쓰지 않다 보니 원하는 대로 구현할 줄 알아도 구조 없는 허공에 떠 있는 느낌을 자주 받았음
“Tailwind는 별로니 그냥 CSS를 써라”가 아니라, “Tailwind는 훌륭하지만 이제는 필요 없을 수도 있다”는 식이라 좋음
CSS를 손으로 구조화하는 데 늘 어려움을 겪었는데, 이 글 덕분에 훨씬 다른 방식으로 생각하게 됨
CSS를 정리할 때 이 구조화 기법이 꽤 유용했음: https://rstacruz.github.io/rscss/
전반적으로 원글에서 jvns가 설명한 내용과 잘 맞고, 그 위에 구조와 정리를 조금 더 얹어줌

답변달기

Tailwind에서 벗어나며 CSS 구조화 배우기

Tailwind에서 배운 구조를 바닐라 CSS로 옮기기

CSS 코드베이스에 둔 주요 시스템

reset

components

colours

font sizes

utilities

base

spacing

responsive design

build system

Tailwind에서 벗어나는 이유

앞으로 배워보고 싶은 CSS 기능

Tailwind를 완전히 부정하지 않는 결론

함께 보면 좋은 글 β

댓글과 토론

Hacker News 의견들

Lobste.rs 의견들