모두가 Tailwind CSS v4를 두고 논쟁하는 진짜 이유
Tailwind CSS v4에 대한 논쟁이 어디에서나 일어나고 있습니다. 하지만 대부분의 사람들은 엉뚱한 것을 두고 다투고 있습니다.
진짜 문제는 유틸리티 클래스(utility classes)냐 인라인 스타일(inline styles)이냐가 아닙니다. 스타일링이 어디에 위치하는지, 그리고 그로 인한 인지적 비용(mental cost)을 누가 부담하느냐의 문제입니다.
Tailwind v4는 설정을 CSS 파일로 옮겼습니다. JavaScript 설정 파일 대신 @theme을 사용합니다. 이는 워크플로우를 더 깔끔하게 만들어 줍니다.
하지만 이것이 논란의 원인은 아닙니다. 논란은 v4가 서로 다른 두 가지 패턴을 더 사용하기 쉽게 만들었기 때문에 발생합니다.
패턴 1: 컴포넌트 내의 유틸리티 클래스. HTML이나 JSX에 클래스를 직접 작성합니다. 이를 통해 요소가 어떻게 보이는지 정확히 알 수 있습니다.
패턴 2: @apply 방식.
CSS 파일에 .alert나 .alert--error와 같은 시맨틱 클래스(semantic classes)를 생성합니다. 이를 통해 요소가 무엇인지 알 수 있습니다.
두 방식 모두 작동하며, 어느 것도 틀리지 않았습니다. 단지 서로 다른 철학을 따를 뿐입니다.
A 그룹은 코로케이션(co-location)을 믿습니다. 모든 것이 한 곳에 머무는 것을 선호합니다. B 그룹은 시맨틱한 이름을 믿습니다. 목적을 설명하는 이름을 원합니다.
디자이너가 에러 색상을 빨간색에서 주황색으로 변경할 때, A 그룹은 코드 파일을 뒤져야 합니다. B 그룹은 CSS 파일의 한 줄만 수정하면 됩니다.
Tailwind v4는 @apply를 더 자연스럽게 느껴지도록 만듭니다. 이로 인해 긴장감이 더 커졌습니다.
팀 규모에 따른 선택 방법은 다음과 같습니다:
소규모 팀: 유틸리티 클래스를 사용하세요. 클래스 이름을 짓는 데 시간을 허비할 필요가 없습니다. 모두가 같은 파일을 작업할 때 더 빠르게 움직일 수 있습니다.
컴포넌트 라이브러리:
@apply또는 CSS 변수를 사용하세요. 사용자가 여러분의 내부 디자인 토큰(design tokens)을 알 필요는 없어야 합니다.대기업: 하이브리드 모델을 사용하세요. 디자인 시스템 팀이 시맨틱 클래스를 관리하게 하고, 애플리케이션 개발자는 빠른 레이아웃 구성을 위해 유틸리티를 사용하게 합니다.
단순히 긴 클래스 문자열을 읽기 싫어서 @apply를 사용하지 마세요. 그것은 전략이 아니라 회피입니다.
가장 목소리가 큰 비판가들은 프레임워크가 아니라 도구와 싸우는 경우가 많습니다. 에디터에 IntelliSense가 부족하거나 팀에 디자인 토큰 시스템이 없다면, 워크플로우가 망가진 것처럼 느껴질 것입니다.
프레임워크를 탓하기 전에 워크플로우부터 개선하세요.
Tailwind v4는 강력한 릴리스입니다. CSS 우선(CSS-first) 설정 방식은 더 낫습니다. 논쟁은 단지 팀이 명확한 결정을 내려야 한다는 신호일 뿐입니다.
선택하세요. 문서화하세요. 그리고 나아가세요.
여러분의 팀은 어떤 방식을 사용하나요? 유틸리티 클래스를 사용하시나요, 아니면 @apply를 사용하시나요?
출처: https://dev.to/enjoy_kumawat/the-real-reason-everyones-fighting-about-tailwind-css-v4-4o0g