Tailwind CSS v4.0 출시

 (tailwindcss.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Tailwind CSS v4.0은 프레임워크를 처음부터 다시 작성한 릴리스로, 빌드 성능을 크게 높이고 설정·커스터마이징 흐름을 CSS 중심으로 바꿈
  • Catalyst 기준 전체 빌드는 v3.4의 378ms에서 v4.0의 100ms로 3.78배 빨라졌고, 새 CSS가 없는 증분 빌드는 35ms에서 192µs로 182배 개선됨
  • 설치는 @import "tailwindcss" 한 줄과 무설정 기본값으로 단순해졌으며, Vite 사용자는 PostCSS 대신 @tailwindcss/vite를 쓸 수 있음
  • v4.0은 cascade layers, @property, color-mix(), logical properties 같은 현대 CSS 기능을 활용하고, 콘텐츠 자동 감지와 내장 @import 처리를 도입함
  • 컨테이너 쿼리, 3D transform, 확장된 gradient API, @starting-style, not-*, field-sizing, color-scheme, inert 등이 코어 기능으로 들어와 별도 플러그인 의존이 줄어듦

처음부터 다시 작성한 고성능 엔진

  • Tailwind CSS v4.0은 수년간의 아키텍처 경험을 바탕으로 프레임워크를 처음부터 재작성한 버전임
  • 자체 프로젝트 벤치마크에서 전체 재빌드는 3.5배 이상, 증분 빌드는 8배 이상 빨라짐
  • Catalyst 기준 중앙값 빌드 시간은 다음과 같음
    • 전체 빌드: v3.4 378ms → v4.0 100ms, 3.78배 개선
    • 새 CSS가 있는 증분 재빌드: 44ms → 5ms, 8.8배 개선
    • 새 CSS가 없는 증분 재빌드: 35ms → 192µs, 182배 개선
  • 새 CSS를 컴파일할 필요가 없는 증분 빌드는 100배 이상 빨라져 마이크로초 단위로 완료됨
    • 프로젝트를 오래 작업할수록 flex, col-span-2, font-bold처럼 이미 사용한 클래스를 다시 쓰는 경우가 많아 이런 빌드를 자주 만나게 됨

현대 CSS 플랫폼 활용

  • v4.0은 Tailwind CSS v3.0 이후 발전한 웹 플랫폼 기능을 적극 활용함
  • 주요 기반 CSS 기능은 다음과 같음
    • Native cascade layers: 서로 다른 스타일 규칙이 상호작용하는 방식을 더 세밀하게 제어함
    • Registered custom properties: gradient 애니메이션을 가능하게 하고, 큰 페이지에서 성능을 크게 개선함
    • color-mix(): CSS 변수와 currentColor를 포함한 모든 색상 값의 불투명도를 조정할 수 있음
    • Logical properties: RTL 지원을 단순화하고 생성되는 CSS 크기를 줄임
  • 이런 기능들은 Tailwind 내부 구현도 단순화해 버그 표면적을 줄이고 유지보수를 쉽게 만듦

설치와 빌드 통합 단순화

  • 설치 흐름은 단계와 보일러플레이트를 줄이는 방향으로 정리됨
    • npm i tailwindcss @tailwindcss/postcss
    • PostCSS 플러그인에 @tailwindcss/postcss 추가
    • CSS 파일에서 @import "tailwindcss" 사용
  • v4.0에서는 @tailwind 지시문 대신 CSS 한 줄로 Tailwind를 가져와 사용할 수 있음
  • 템플릿 파일 경로를 포함해 아무 설정 없이 시작할 수 있는 무설정 흐름을 제공함
  • 별도 외부 플러그인 없이 @import 규칙을 번들링하고, vendor prefixing과 현대 문법 변환에는 Lightning CSS를 내부적으로 사용함
  • Vite 사용자는 PostCSS 대신 @tailwindcss/vite를 선택할 수 있음
    • Tailwind CSS v4.0은 PostCSS 플러그인으로도 빠르지만, Vite 플러그인을 쓰면 더 나은 성능을 얻을 수 있음

콘텐츠 자동 감지와 내장 import

  • v3에서 필요했던 content 배열 설정은 v4.0의 자동 감지 휴리스틱으로 대체됨
  • .gitignore에 있는 항목은 자동으로 무시해 의존성이나 버전 관리되지 않는 생성 파일을 스캔하지 않음
    • 예: /node_modules, /coverage, /.next, /build
  • 이미지, 비디오, .zip 등 바이너리 확장자도 자동으로 무시함
  • 기본적으로 제외되는 소스를 명시적으로 추가해야 할 때는 CSS 파일 안에서 @source 지시문을 사용할 수 있음
    • @source "../node_modules/@my-company/ui-lib";
    • @source도 같은 휴리스틱을 사용하므로 바이너리 파일 타입은 별도 확장자 지정 없이 제외됨
  • v4.0 이전에는 다른 CSS 파일을 @import로 인라인하려면 postcss-import 같은 별도 플러그인이 필요했지만, 이제 내장 import 지원으로 다른 도구가 필요 없음
    • import 시스템은 Tailwind CSS 전용으로 만들어졌고 엔진과 긴밀히 통합돼 더 빠르게 동작함

CSS-first 설정과 theme variables

  • v4.0의 큰 변화 중 하나는 프로젝트 설정을 JavaScript가 아니라 CSS에서 직접 수행하는 방식임
  • tailwind.config.js 파일 대신 Tailwind를 import하는 CSS 파일 안에서 @theme을 사용해 커스터마이징할 수 있음
    • 디자인 토큰 설정
    • 커스텀 유틸리티 정의
    • 커스텀 variant 정의
  • @theme에 정의한 디자인 토큰은 기본적으로 CSS 변수로 노출됨
    • 예: --font-display, --breakpoint-3xl, --color-avocado-500, --ease-fluid
  • 이렇게 생성된 CSS 변수는 런타임에서 일반 CSS로 참조할 수 있음
    • 인라인 스타일 재사용
    • Motion 같은 라이브러리에 전달해 애니메이션 처리

동적 유틸리티 값과 variant

  • v4.0은 여러 유틸리티와 variant가 특정 임의 값을 설정 없이 받도록 단순화함
  • 그리드는 별도 설정 없이 원하는 크기를 사용할 수 있음
    • 예: grid grid-cols-15
  • 커스텀 boolean data attribute도 미리 정의하지 않고 타깃팅할 수 있음
    • 예: data-current:opacity-100
  • px-*, mt-*, w-*, h-* 같은 spacing 유틸리티는 단일 spacing scale 변수에서 동적으로 파생됨
    • 예: --spacing: 0.25rem
    • w-17은 calc(var(--spacing) * 17) 형태로 생성됨
  • v4.0과 함께 나온 업그레이드 도구는 더 이상 필요 없는 임의 값 문법을 감지하면 대부분 자동으로 단순화함

색상 팔레트와 컨테이너 쿼리

  • 기본 색상 팔레트 전체가 rgb에서 oklch 로 업그레이드됨
    • sRGB 색 공간의 한계를 벗어나 더 넓은 gamut을 활용해 색상을 더 선명하게 만듦
    • v3와 색상 간 균형은 유지하려고 했기 때문에 기존 프로젝트 업그레이드 시 breaking change처럼 느껴지지 않아야 함
  • 컨테이너 쿼리 지원이 v4.0에서 코어로 들어와 @tailwindcss/container-queries 플러그인이 필요 없어짐
  • 새 @max-* variant로 max-width 컨테이너 쿼리를 사용할 수 있음
  • 일반 breakpoint variant처럼 @min-*과 @max-*를 쌓아 컨테이너 쿼리 범위를 정의할 수 있음

3D transform과 gradient API 확장

  • v4.0은 3D transform을 위한 API를 추가함
    • rotate-x-*
    • rotate-y-*
    • scale-z-*
    • translate-z-*
  • gradient 기능도 확장돼 커스텀 CSS 없이 더 다양한 효과를 만들 수 있음
  • 선형 gradient는 각도를 값으로 받을 수 있음
    • 예: bg-linear-45
    • 기존 bg-gradient-*는 bg-linear-*로 이름이 바뀜
  • gradient 색상 보간 모드는 modifier로 제어할 수 있음
    • bg-linear-to-r/srgb
    • bg-linear-to-r/oklch
    • v4.0의 기본 보간은 OKLAB이며, 다른 색 공간 modifier도 사용할 수 있음
  • 새 bg-conic-*, bg-radial-* 유틸리티로 conic·radial gradient를 만들 수 있음
    • 기존 from-*, via-*, to-*와 함께 동작함
    • 색상 보간 방식 설정 modifier와 gradient 위치 같은 세부 제어를 위한 임의 값 지원을 포함함

새 variant와 유틸리티

  • 새 starting variant는 CSS @starting-style을 지원함
    • 요소가 처음 표시될 때 속성 transition을 만들 수 있음
    • JavaScript 없이 페이지에 나타나는 요소를 애니메이션 처리할 수 있음
    • 브라우저 지원은 아직 대부분 팀에 충분하지 않을 수 있지만 가까워지고 있음
  • 새 not-* variant는 CSS :not() pseudo-class를 지원함
    • 예: not-hover:opacity-75
    • media query와 @supports query도 부정할 수 있음
  • v4.0에는 다음 유틸리티와 variant도 추가됨
    • inset-shadow-*, inset-ring-*: 단일 요소에 최대 4개 box shadow 레이어를 쌓을 수 있음
    • field-sizing: JavaScript 없이 textarea 자동 크기 조절을 지원함
    • color-scheme: dark mode에서 밝은 scrollbar를 제거할 수 있음
    • font-stretch: 다양한 폭을 지원하는 variable font를 조정함
    • inert: inert 속성으로 표시된 비상호작용 요소를 스타일링함
    • nth-*: nth 계열 스타일링을 지원함
    • in-*: group 클래스 없이 group-*와 비슷하게 동작함
    • :popover-open: 기존 open variant로 열린 popover도 타깃팅함
    • descendant variant: 모든 하위 요소를 스타일링함

시작과 업그레이드 경로

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 한때 Tailwind의 여러 결함과 실제로 현대적인 “순수” 웹 방식과의 비호환성을 강하게 비판했지만, v4의 큰 진전은 매우 반가움
    Tailwind 테마를 네이티브 CSS 변수로 접근할 수 있고, 문서에 외부 스타일시트에서 네이티브 변수로 작성한 버튼 컴포넌트 예시까지 있는 건 엄청난 변화임
    CSS만으로 설정할 수 있는 것도 훌륭하고, 이제 Tailwind가 합리적인 아키텍처를 집어삼키는 JavaScript식 “바이럴” 프레임워크가 아니라 어떤 프로젝트에도 추가할 수 있는 유틸리티처럼 느껴짐
    지난 몇 년간의 비판이 효과가 있었든, 스스로 좋은 결론에 도달했든, Tailwind 찬반 논쟁의 상당수는 이제 덜 관련 있어 보이고, 그건 매우 좋은 일임. 이제 제품을 만드는 데 집중할 수 있음

    • 실제로 쓰는 면에서는 여전히 비판적이지만, Tailwind가 AI 생성 워크플로에 잘 맞는 점은 놀라움
      무엇이든 체계적으로 표현할 수 있어서 정말 잘 작동하고, 거기에 굉장히 유용한 무언가가 있음
    • Tailwind 찬반 논쟁이 더는 관련 없다는 데는 동의하기 어렵고, 디자이너/디자인 엔지니어로서는 두 가지 문제가 있음
      첫째, JavaScript/Tailwind 엔지니어들이 디자인 논의를 장악해 버렸음. “유틸리티 우선”, “사용되지 않는 코드 제거”, “타입 안전 CSS”보다 디자인 시스템, 예를 들어 타이포그래피에서 Perfect Fifth를 쓸지 Perfect Fourth를 쓸지 같은 문제에 더 집중함
      둘째, Tailwind는 실제 제작 과정에 참여하기 어렵게 만듦. 디자인 결정이 flex items-center shadow-lg p-6 hover:bg-gray-50 dark:bg-gray-800 py-[calc(theme(spacing[2.5])-1px)] 같은 난해한 React 컴포넌트 표현 안에 묻힘
      JavaScript 엔지니어에게는 이해될 수 있지만, 체계적인 디자인에는 장벽이 됨. CSS로 정밀한 수학적 관계를 표현하는 대신, 더 편한 인라인 스타일을 쓰는 셈임
    • Tailwind CSS의 색상 팔레트만 갖고 싶음

  • CSS는 예전보다 훨씬 쓰기 쉬워졌고, 대부분의 브라우저도 이제 일관되게 동작함
    빌드 단계가 필요 없고, 마크업을 과도한 코드로 어지럽히지 않으니 배울 가치가 있음
    HTML 안에 style 속성을 직접 쓸 수도 있는데, 예전에는 관심사 분리를 위해 피했음. 그런데 왜 비슷한 방식을 다시 도입하려는지 의아함. 단지 몇 글자 줄이려는 건가 싶음
    style 속성은 머릿속에서 코드를 변환할 필요도 없으니 오히려 더 직관적으로 보임. 매력을 잘 모르겠음

    • style 속성으로는 할 수 없는 게 꽤 있음. 예를 들면 의사 클래스 :hover, :focus, 의사 요소 ::before, ::after, 미디어 쿼리, 키프레임과 애니메이션이 있음
      큰 프로젝트에서 개발자 경험도 좋지 않음
      반면 곧 표준이 될 @scope는 스타일을 가까운 곳에 배치하는 데 좋은 추가 기능임: https://developer.mozilla.org/en-US/docs/Web/CSS/@scope
    • 요즘 Tailwind는 CSS 클래스 대신 추상화 계층 역할을 하는 컴포넌트 추상화 시스템과 자주 함께 쓰임
      컴포넌트 추상화는 의미와 스타일을 더 강하게 분리해 줌. 두 경우 모두 “hero” 추상화를 찾아야 하지만, 컴포넌트 세계에서는 스타일뿐 아니라 HTML 태그 이름까지 추상화함
      어느 쪽이든 “스타일 세부사항”은 페이지 소스 파일인 “콘텐츠”에서 분리되어 있음. 관심사 분리, 즉 콘텐츠와 표현의 더 나은 분리를 위해 빌드 단계를 감수할 수 있음
    • 매력은 CSS 클래스 이름을 지을 필요가 없고, HTML과 나란히 있어서 읽기 쉬우며, 이름 짓는 방식이 표준화되어 어디서나 같은 규칙을 쓴다는 데 있음
      별도 파일을 관리하고 쓰지 않는 컴포넌트를 제거할 필요도 줄어듦
      style 태그로는 할 수 없던 미디어 쿼리를 쓸 수 있고, 다른 곳에서 쓰는 클래스를 바꿔버릴 위험도 없음. CSS의 전역 스코프는 장점도 있지만 위험함
    • React와 강한 결합을 너무 당연하게 받아들이게 된 결과임
      스타일은 디자인 시스템이 아니라 컴포넌트에 속한다고 여겨짐. JavaScript 우선 엔지니어링 생태계에는 현대 CSS와 체계적 디자인의 힘을 아는 디자인 주도 회사가 더 필요함
    • 큰 프로젝트에서 다뤄야 하는 파일 수를 보면 Tailwind가 꽤 매력적으로 보임
      일반 .css 방식은 이상한 이름, 중복, 충돌 가능성이 생김. css modules도 선택지는 되지만 컴포넌트/페이지마다 파일 수가 사실상 두 배가 됨
      sass나 less는 css modules와 일반 .css의 문제를 한데 섞는 느낌임
      Tailwind를 본질적으로 좋아하거나 싫어하진 않고, 처음엔 아주 싫어했지만, 컴포넌트와 페이지로 이루어진 200개 이상 파일 프로젝트에서는 가치가 느껴짐

  • Tailwind에 대한 첫 반응은 “귀찮다”였음. CSS를 이미 아는데 이제 CSS를 다시 배워야 하는 느낌이었음
    부모가 아이 수학 숙제를 도와주려다, 학교에서 배우는 방식이 예전과 완전히 달라져 자기 풀이법은 여전히 맞지만 받아들여지지 않고 아이는 두 체계를 맞추느라 짜증내는 상황과 비슷해 보임
    팀에서 잘 작동하고 확장도 잘 되니 그냥 써야 한다는 분위기는 이해하고, 경험도 해봤음
    그래도 여전히 클래스나 태그를 대상으로 하는 평범한 스타일시트가 더 좋음. 특히 CSS가 이제 중첩 선택자를 지원하니 더 그럼
    스타일시트 관리 문제는 있고, Remix/React Router처럼 라우트 수준에서 CSS 파일을 정의하고 적용하는 방식이 마음에 듦. 그걸로 부족하거나 동적 스타일이 .css 파일로 너무 복잡하면 style={{...}}도 늘 가능함
    CSS는 강력하고 유연하며 확장 가능해서, Tailwind는 개선이 아니라 제한처럼 느껴짐. 계속 인기 있는 이유는 잘 모르겠지만, 3~4년 뒤에는 다들 또 다른 것으로 옮겨가 있을 거라고 봄

    • 처음엔 CSS를 다시 배우는 느낌이 답답했고, 예전에는 같은 주장을 했음
      하지만 Tailwind를 쓰는 오픈소스 프로젝트에 기여하면서 익숙해졌고, 이제는 다르게 느낌
      Tailwind는 본질적으로 style={{…}}의 속기법에 가까움. .css 파일이나 스타일 객체로는 여러 줄이 필요한 걸 하나의 유틸리티가 15자 정도로 끝냄
      “visual text replacement css” 같은 걸 검색하거나 CSS 치트시트, 8년 전 CSS-Tricks 글을 뒤지는 시간이 크게 줄었음. 대신 항상 Tailwind 문서를 보고 원하는 일을 하는 유틸리티 클래스를 빨리 찾음
      놀랄 만큼 많은 부분이 머릿속 캐시에 들어오고, 레이아웃 작업에 필요한 모든 CSS를 외우려는 것보다 훨씬 낫게 느껴짐
    • 이제 컴포넌트 전체가 한 파일 안에 들어오기 때문이라고 봄
      별도로 CSS를 만질 필요가 없고, 스타일이 적용되는 요소 바로 위에 있어서 서로 대조해 볼 필요가 없음
      css 속성만으로도 가능하긴 하지만, 모두가 그건 잘못된 방식이라고 배워왔다는 문제가 있고, 여러 유틸리티가 들어 있는 문자열 목록이 순수 CSS 객체를 쓰는 것보다 쉽기도 함
    • 제한은 가능한 복잡도를 줄이고, 그래서 Tailwind가 이김
      거대하고 복잡한 시스템 위에 얹힌 조합 가능하고 표준화된 모듈형 래퍼라서 큰 진전임
    • 아이와 수학을 배우고 있는데 내가 배운 것과 다르지 않고, 여전히 빨리 풀 수 있음
      반면 소셜 미디어에는 곱셈과 나눗셈을 섞어놓고 정답은 하나뿐이라고 하는 글들이 있음. Tailwind가 그 정도로 나쁘진 않지만, 늙은 입장에서는 그 방향에 더 가까워 보임

  • Tailwind를 좋아함. 지난 4년 동안 3개 프로젝트에서 썼고, 직관적이고 문서가 좋고 단순했음
    프로젝트의 모든 스타일된 div마다 이름을 지어야 했던 emotion과 styled-components 시절이 그립지 않음
    Tailwind에서는 컨테이너가 그냥 div와 몇 개 클래스일 뿐임. 이름 짓기 논쟁이 줄고, 이름 짓는 데 쓰는 머리와 리뷰 시간이 줄어듦

    • styled div마다 이름을 고민해야 한다는 문제가 자주 보이는데 조금 의아함
      뭔가 이름 붙이는 데 1초 넘게 생각해 본 적이 거의 없음. 실제로 누군가에게는 이게 막히는 지점인가? 정말로 거기서 마비될 정도인지 궁금함
    • “몇 개 클래스”라고 한다면 아주 좋은 제품 책임자와 일하는 듯함
      내가 겪은 사람들은 가능한 모든 세부사항을 끝없이 지정하곤 했음. 웹 폼을 자기 개인 HGTV 리노베이션처럼 다룸
      Tailwind를 한 번 써봤을 때 클래스가 마크업보다 한 자릿수는 더 많아졌고, 금방 읽기 어려워졌음
    • 여러 프로젝트에서 써봤지만 마음에 들지 않았음. 큰 프로젝트에서는 빠르게 지저분해지고, 새 Bootstrap처럼 느껴짐
      지금은 CSS-in-JS 워크플로에 만족함. LLM 도움으로 예전식 CSS를 작성하는 방식임. LLM에 이미지를 보여주고 컴포넌트를 요청하면 적절한 이름까지 붙어서 바로 나옴
    • 선택할 수 있다면 React를 피하는 주된 이유 중 하나가 이것임
      React에서 스타일링은 별로고, Tailwind를 쓰더라도 그나마 덜 나쁜 선택지일 뿐임
      프론트엔드 프레임워크와 빌드 단계를 쓴다면 용도에 따라 Svelte와 Astro가 좋음. 평범한 CSS로 스타일링할 수 있고, 컴포넌트를 작게 유지하면 클래스 이름을 거의 쓰지 않아도 됨
      요소 선택자를 쓰고 프레임워크가 빌드 시점에 스타일 스코프를 잡아주게 하면 됨

  • 내 사이트에 Tailwind를 써봤고 꽤 마음에 들었는데, 흔히 말하는 이유와는 조금 다를 수 있음
    Tailwind의 진짜 가치는 한 요소에 영향을 주는 모든 스타일을 한곳에서 읽을 수 있다는 점임
    클래스 이름이 길어질 수는 있지만, 브라우저 개발자 도구를 매번 열거나 하나 이상의 스타일시트를 위아래로 오가는 것보다 긴 한 줄을 읽는 편이 훨씬 빠름
    나중에 그 코드로 돌아와도 다른 요소를 바꿔버릴까 걱정하지 않고 자신 있게 수정할 수 있음
    CSS의 캐스케이딩 성격은 여전히 유용하지만, 보통은 스타일을 한 요소에만 제한하고 싶음. 나머지는 CSS로 돌아가지만, 실제로 작성하는 CSS는 아주 적음. 대개는 여백만 맞추고 싶기 때문임

    • 바로 그 점이 Tailwind가 좋고 편한 이유라고 봄
      “X를 어떻게 하지?”가 30분짜리 조사 작업이 아니라 빠른 문서 검색으로 끝나는 점도 마음에 듦
    • 요소에 적용된 모든 스타일을 보여주는 도구는 IDE에도 있음. 예를 들어 Intellij의 “Show Applied Styles for Tag”나 Chrome 개발자 도구에서도 읽기 좋게 보여줌
      이 HN 글에 나온 Tailwind 조각들은 그에 비하면 꽤 무서워 보임
    • 어느 정도 동의하지만 같은 문제가 남아 있음
      div에 text-xl을 추가하고 그 안에 중첩된 div와 span이 있으면 모두 text-xl을 상속하므로, 중첩 요소에서는 무엇이 text-xl을 유발하는지 보려면 결국 요소 계층을 거슬러 올라가야 함
      그래도 전체적으로는 조금 더 쉽긴 함

  • “빌드 시간 단축”, “더 이상 @tailwind 지시문 없음”, “JavaScript 설정 없음”, “현대 웹을 위해 설계”라는 문구는 이렇게 들림
    CSS가 이제 우리가 직접 하던 걸 다 할 수 있지만, 그래도 우리가 아직 필요하다고 계속 가장하자는 느낌임

    • 싫어할 거라면 적어도 그게 무엇이고 왜 사람들이 쓰는지 이해하려고는 해야 함
    • Tailwind의 판매 포인트는 처음부터 “거의 인라인 CSS지만, style 속성보다 덜 번거롭고 훨씬 최적화하기 쉬움”이었음
    • 예전에는 일반 CSS로 못 해서 Tailwind가 필요했던 게 무엇인지 궁금함
      Tailwind는 거의 CSS에 1:1로 대응하지 않나?
    • 정말로 그렇게 받아들였나 싶음
      Tailwind를 좋아하지 않는 건 이해하지만, 허수아비를 세워 공격하기보다 Tailwind의 어떤 점이 싫은지 말하는 편이 낫다고 봄
      다른 사람의 오픈소스 프로젝트와 유용하게 쓰는 사람들을 깎아내리는 것도 좋지 않음

  • CSS를 잘 아는 사람들에게 묻고 싶음. 나는 잘 모름
    개인 Phoenix 프로젝트를 1.7로 올리는 중이고, Phoenix가 이제 기본으로 Tailwind를 쓰길래 Bootstrap 대신 써보려 했음
    지금까지는 Bootstrap 버전은 “그럭저럭 괜찮아” 보였는데 Tailwind 버전은 엉망처럼 보임
    디자이너가 되려 하지 않고도 괜찮아 보이는 기본값을 얻는 가장 쉬운 방법이 뭘까? 아니면 그냥 Bootstrap을 다시 설치하고 끝내야 할까?

    • 그 경우라면 Bootstrap을 다시 설치하는 쪽임
      Tailwind는 디자인을 제어하고 싶을 때 도구를 주지만, 결국 디자인을 직접 제어해야 함
      그냥 보기 좋고 Bootstrap 느낌이 나는 것도 괜찮다면 Bootstrap이 맞음
      이론상 Tailwind 위에 Bootstrap을 재구현한 프로젝트들이 있어서 Bootstrap 같은 출발점과 Tailwind의 힘을 함께 줄 수 있지만, 실제로는 그냥 Bootstrap을 쓰는 것보다 잘 작동하는 걸 못 봤음
    • 그 목적에는 DaisyUI를 씀. 예시 데모 사이트는 여기 있음: https://nwk-landing-kit.netlify.app
      DaisyUI 문서는 여기 있음: https://daisyui.com
    • Bootstrap 같은 컴포넌트를 찾는다면 무료로 https://flowbite.com/를 써볼 만함
      Tailwind에도 유료 컴포넌트가 있고, 그냥 복사해서 붙여넣으면 됨. 익숙해지면 Flowbite 컴포넌트를 조금씩 고칠 수 있다는 점이 좋음
    • 누가 돈을 내는지에 따라 다름
      직업 안정성이 있고 이것저것 만지고 싶다면 Tailwind를 가지고 놀아도 됨. 유행에 민감하고 목소리 큰 사람들은 대체로 Tailwind를 좋아하는 듯함
      하지만 자기 프로젝트이거나, 자체 자금이거나, 마감이 있다면 이미 아는 Bootstrap을 쓰고 UI로 소모전 벌이기보다 일 끝내는 데 집중하는 게 낫음
    • Tailwind와 Bootstrap은 사과와 애플파이 비교에 가까움
      Tailwind는 컴포넌트를 만들기 위해 쌓아야 하는 클래스들을 제공함
      UI 컴포넌트 소스를 함께 쓰면 더 쉬울 것임. 예전에 TailwindUI를 써봤지만 유료였고, 좋은 무료 대안도 있을 것 같음

  • “Tailwind냐 아니냐” 대화에는 명확한 패턴이 있음. Tailwind가 언급될 때마다 반복됨
    30분 이상 제대로 써본 적 없고, 잠깐 시도했거나 문서만 훑은 사람들이 있음. 이들은 Tailwind를 싫어하고 “순수 CSS” 같은 걸 선호함
    반면 실제 프로젝트에서, 한 명보다 많은 팀 안에서 써본 사람들이 있음. 이들은 가치를 이해하고, 트레이드오프를 받아들이며, 좋아함
    첫 번째 그룹에서 두 번째 그룹으로 넘어가는 사람은 많이 봤지만, 두 번째에서 첫 번째로 돌아가는 사람은 거의 못 봤음
    그래서 Tailwind가 성공한 것임. 순수주의자의 눈에는 아름답지 않을 수 있지만, 만드는 사람과 실용주의자의 눈에는 정말 훌륭함

    • 나는 그 두 그룹 어디에도 잘 맞지 않는다고 봄
      Tailwind에 반대하는 건 아니지만 아직 써보지 않은 이유는 Web Components나 React Styled Components 같은 다른 선택지보다 왜 더 나은 접근인지 잘 보이지 않기 때문임
      가장 큰 문제는 Tailwind가 HTML을 수많은 유틸리티 클래스로 어지럽혀 읽고 유지보수하기 어렵게 만든다는 점임
      거대한 전역 CSS 파일과 고전적인 태그 이름 기반 CSS보다 낫다는 건 알지만, 컴포넌트에 스코프된 CSS를 전역 이름공간을 오염시키지 않고 쓰는 방법은 이미 있음. Web Components와 Styled Components가 그 예임
      둘 다 스타일을 컴포넌트, 더 일반적으로는 특정 HTML 태그 묶음에 직접 묶어 두므로 어떤 스타일이 어디에 적용되는지 보기 쉬움
      전역 클래스 이름도 필요 없고, 원치 않는 부작용이나 충돌 걱정도 줄어듦. 컴포넌트를 제거하면 관련 스타일도 함께 제거되므로 사용하지 않는 CSS가 남을 걱정이 없음. shadow DOM 덕분에 한 컴포넌트 스타일이 다른 컴포넌트에 의도치 않게 영향을 줄 위험도 없음
      표현용 스타일을 마크업에 직접 섞지 않아 HTML을 짧고 읽기 쉽게 유지하는 걸 중요하게 생각함. Tailwind처럼 스타일이 모두 class 속성에 들어가면 한 줄에 긴 클래스 목록이 생기고, 실제 클래스 이름까지 함께 써야 하면 HTML이 지저분해짐
      어떤 스타일이 적용되는지 한눈에 파악하기 어렵고, 제대로 들여쓰기하기도 힘듦. 예전에 HTML의 인라인 style 속성에서 벗어난 여러 이유를 떠올리게 함
      Tailwind를 싫어하는 건 아니지만, 읽기 쉬움, 유지보수성, 관심사 분리 측면에서 Web Components나 Styled Components보다 명확한 장점을 못 보겠고, 아직 답이 안 된 우려가 큼
      문서는 읽었지만 써보진 않았고, 왜 다른 선택지 대신 Tailwind를 고를지 이해하기 어렵다. 평범한 HTML 한가운데 클래스가 엄청나게 많아지는 점은 나에게 둘 다 읽기 어렵게 만듦

  • Tailwind를 유용하게 쓰고 생산적인 사람들이 있다는 건 인정하지만, 이제 Tailwind가 어디에나 있다 보니 깔끔하지만 흔한 외형이 여기저기서 보임

    • 이건 Tailwind와 TailwindUI/shadcn 등을 혼동하는 것임
      대체로 Tailwind는 일반 CSS보다 스타일에 더 큰 영향을 주지 않음. 예외는 조금 있음. 그림자 같은 건 좀 더 표준화되어 있고, indigo 색상 팔레트가 최근 외부에도 영향을 준 정도임
    • Tailwind는 합리적인 기본값을 주지만, 디자인에 큰 영향을 주지는 않음
      사람들이 특정한 방식으로 사이트를 디자인하는 경향이 있을 뿐임. 특히 ShadCn과 함께 쓸 때 그렇다
    • 오히려 좋은 일처럼 느껴짐. Tailwind의 선택지는 잘 설계되어 있고 잘 작동함
      웹사이트 글꼴로 Inter가 새로운 Helvetica처럼 쓰이는 것과 비슷하게 봄. 많은 사람이 쓰고 보기 좋다면 굳이 안 쓸 이유가 있나 싶음
    • 예전에도 Bootstrap을 두고 이런 말을 들었지만, 내가 만든 Bootstrap 사이트들은 서로 닮지 않았음
      Bootstrap은 Tailwind보다 훨씬 전부터 많은 유틸리티 클래스를 제공해서 시간을 많이 아껴줬고, 특정 외형을 강제하지 않았음
      원하는 클래스만 불러오면 됐음. 물론 Sass 소스 파일을 내려받지 않았다면 얘기가 다르지만, 그건 어리석은 선택이었을 것임
    • 이 문제에 대한 내 생각은 좋은 UI 프레임워크, 즉 Tailwind와 컴포넌트 조합이 아직 드물다는 것임
      그래서 대다수 프로젝트가 아주 적은 수의 프레임워크를 씀. 품질 좋은 UI 프로젝트가 4~5개 더 나오고, 특히 스타일 방향이 더 달라진다면 다양성이 늘어날 것임
      디자인도 많은 창작 작업처럼 놀랄 만큼 적은 수의 사람들이 흐름을 정하는 것 같음
      더 많은 사람이 이걸 알았으면 함. 재능 있는 사람들이 “내가 만들어도 아무도 듣지 않을 것”이라 생각해 만들지 않는 경우가 있을 것 같음
      하지만 그런 사람들 중 일부가 시도한다면 웹의 큰 부분에 새로운 UI를 열어줄 수 있다고 봄

  • Tailwind는 인라인 스타일의 장점, 즉 이름을 붙이지 않고 어떤 것을 스타일링하는 방식과 문자열의 보편성, 그리고 문자열의 한계를 보여주는 증거임
    그다음에 올 것이 기대되고, 그때까지는 마지못해 Tailwind를 쓸 것임

답변달기