Hacker News 의견
  • <el-dialog-panel> 처럼 길고 계층적인 Tailwind class 네이밍을 보면, 이제는 CSS뿐 아니라 또 다른 계층 구조 시스템도 익혀야 하는 상황임을 느끼게 됨

    • 대규모 Tailwind 프로젝트를 열 때마다, 한 줄에 엄청나게 긴 class 속성 리스트가 나오는 걸 보면 항상 감탄하게 됨

      <div class="group relative w-full max-w-md mx-auto bg-white dark:bg-gray-900 border border-gray-200 dark:border-gray-800 rounded-2xl shadow-lg p-6 md:p-8 transition-all duration-300 hover:shadow-xl hover:border-blue-500 dark:hover:border-blue-400">
      ...
      </div>
      
    • Tailwind 이전에는 만나는 모든 웹 디자이너가 이런 식의 시스템을 자기 방식대로 만들곤 했음
      CSS가 이론적으로는 충분히 강력하고 Tailwind 없이도 충분히 가능함
      하지만 실제로는 CSS의 큰 단점이 있음: 전력을 발휘하려면 의미론적 모델을 별도로 설계해야 하는데, 디자이너들은 문서 구조나 정보 설계 이상으로 분위기와 감정 출력에 집중하는 경우가 많음
      이런 감정적인 개념을 논리적 규칙으로 마크업하는 게 매우 어렵거나 불가능함
      Tailwind는 기존에 모두가 하던 것, 즉 “의미”에 대한 추상적 모델링 대신 그냥 bold, red처럼 바로 적용 가능한 규칙을 공식화한 것에 불과함

    • 이런 코드를 보고 ‘와, 이게 정말 깔끔한 코드군!’ 이라고 말할 수 있는 사람이 어떻게 생기는지 의문이 듦
      Tailwind가 어쩌다 이렇게 인기 많아졌는지 모르겠고, 순수 CSS를 배우는 게 진짜 좋다고 생각함
      요즘 CSS는 정말 훨씬 더 좋아짐

    • 실제 프로젝트에서는 class들을 읽기 쉽게 그룹핑해서 쓰게 됨
      예를 들면,

      <div class={tw(
      "block",
      "transform transition-all",
      "bg-white ring-1 ring-black/5 rounded-xl shadow-2xl",
      "max-w-3xl mx-auto overflow-hidden",
      "group-data-closed/dialog:opacity-0",
      "group-data-closed/dialog:scale-95",
      "group-data-enter/dialog:duration-300",
      "group-data-enter/dialog:ease-out",
      "group-data-leave/dialog:duration-200",
      "group-data-leave/dialog:ease-in"
      )}>
      

      이런 식으로 코딩함
      현재는 수동으로 분류하지만, 이런 포맷을 자동화해주는 툴이 있었으면 좋겠음

    • Tailwind는 원래 utility class 스타일 CSS 프레임워크, 일명 “Bourbon on Steroids(강화 버전의 Bourbon)” 같은 개념에서 시작한 듯 함
      그런데 사람들이 예제 코드를 생각보다 훨씬 더 흔쾌히 받아들였고, 그냥 그대로 쌓아서 쓰게 됨
      2018년에 새로운 대규모 프로젝트에 Tailwind를 적용해봤는데, 예전엔 .button, .button-primary 처럼 Tailwind utility를 기반으로 클래스를 쌓으면 유지보수도 쉽고 HTML도 깔끔했음
      하지만 팀이 직접 써보니 기본적으로 제공되는 유틸리티 클래스를 그냥 쌓는 게 훨씬 빠르고 쉬웠음
      코드의 우아함을 신경 쓰지 않으면 디자인도 일관되고 Photoshop에서 본 대로 똑같이 구현 가능했음
      Bourbon 참고

  • 웹 표준 기반 Web Components를 사용한 방식임
    브라우저 기본 지원이라 JS 프레임워크 없이도 작동함
    개발자가 Web Components를 많이 활용하게 된 점이 반가움
    Web Components란? (MDN)

    • 오랫동안 기다려온 변화임
      예전에는 호환성 신경 안 쓸 때 개인 프로젝트에서 Web Components를 가지고 놀았는데, 이제 메인스트림 라이브러리에서도 도입하는 것이 정말 반가움

    • 12년간 Web Components의 필요성을 말해왔지만 React, Angular, Svelte 등 프레임워크 진영에서는 반응이 시큰둥했음
      웹 컴포넌트와 범위 지정 JS/TS와 번들러(vite 또는 rollup 정도)면 충분하고, Shadow DOM이나 전체 리렌더링처럼 쓸데없는 오버헤드는 필요 없음

    • 2014년쯤 Polymer를 가지고 놀았을 때 “transclusion”이라는 용어가 인상적이었음
      그 때는 뭔가 신기했는데 지금은 뜻도 잘 기억 안 남

    • 회사 광고 코드용 hook에서 Web Components를 적용해봤는데, 개인적으로는 좀 실망스러웠음
      코드 실행 트리거는 쉽지만, API 자체는 별로 좋지 않음

  • 인기 UI 컴포넌트 세계를 보면 왜 베이스가 모두 ‘headless’가 아니었는지 궁금했음
    오래전부터 Web Components가 있었는데 이런 접근이 흔하지 않았던 게 의아했음
    프레임워크 별(SHADCN 등) 라이브러리들은 버전 호환에 따라 각자 따로 문서도 만들고, 특정 환경에만 얽매여 실제로는 완성도도 낮음
    Headless UI를 베이스로 만들어 두고, 필요하다면 프레임워크별 래퍼를 만드는 방식이 더 나을 듯 함
    물론 더 복잡한 사정이 많은 걸 알지만, 이런 세상을 꿈꿔봄

    • React, Vue, Svelte 등 인기 프레임워크에서는 Web Components가 번들 사이즈나 런타임 부담 측면에서 그냥 오버헤드임
      특히 React에서는 세계관의 불일치 때문에 기능이나 사용성에서 손해를 감수하거나, 아니면 정교한 바인딩을 만들어야 해서 애초에 Web Components 쓸 이유가 사라짐
      SSR 같은 고급 기능에서도 문제 생기는 경우 많음
      React가 지배적인 상황에서 굳이 Web Components를 쓰고 싶지는 않음
      그리고 Headless 방식은 종종 실 구현이 복잡하거나 오버헤드가 큼
  • 누군가 Tailwind 팀에 충분한 자금을 지원해줄 수 있다면, 돈 걱정 없이 모든 Tailwind 생태계를 무료로 제공받을 수 있어서 세상이 훨씬 좋아질 거라는 상상을 해봄
    Tailwind Plus 같은 다양한 곳과의 깊은 통합 기회가 너무 많이 사라진 게 아쉬움
    예전 37signals가 Jeff Bezos에게 투자받아 VC 걱정에서 자유로워졌던 사례가 떠오름

    • Tailwind 팀은 이미 상상 이상으로 성공적인 상태임
      더 많은 걸 만들고 확장하려는 건 돈이 필요해서가 아니라 자연스러운 야망 때문임
      내 인상으로는 Tailwind(오픈소스)가 전체 비즈니스의 일부이고, 매출이 나는 또다른 프로젝트도 만들어가고 싶어함
      Laravel과도 비교될 만함

    • 솔직히 요즘은 AI로 Tailwind 컴포넌트를 쉽게 제너레이션할 수 있어서 Tailwind Plus 같은 유료 컴포넌트를 굳이 사고 싶은 마음이 덜함
      예전 Tailwind UI 시절엔 실제로 돈 내고 샀지만, 요즘은 차라리 Claude 같은 AI에게 직접 UI를 만들어달라고 하면 라이센스 고민도 없어서 편함
      앞으로 어떤 비즈니스 모델이 통할지 궁금함

    • 37signals 관련해서, 개인적으로는 창업자가 누군가에게 보고하면서 일하는 게 오히려 더 나았을지도 모른다는 생각이 듦

    • 사실 “Tailwind의 모든 경험”은 이미 무료로 제공되고 있음
      부족한 깊은 통합이란 게 뭔지 의문임
      Tailwind Plus(상업 제품)는 그냥 오프더셸프(ready-made) 템플릿과 프리빌트 컴포넌트 세트임
      빠르게 시작하려는 개발자에게 편리하지만, 결국 모든 건 Tailwind만 있으면 충분히 직접 만들 수 있음

    • 구체적으로 어떤 통합을 의미하는 건지 궁금함

  • 지금 너무 흥분하지 않는 게 좋을 듯 함
    예전에는 Vue도 지원했는데 이제는 사실상 버려진 모양임

    • 이게 바로 Vue 지원임
      프레임워크가 워낙 많아서 모두에 맞는 커스텀 래퍼를 만드는 것은 불가능에 가까움
      Web Components를 사용하면 한 번 개발해서 모든 환경에서 돌아가고, 결국 프레임워크가 Web Components 지원(곧 HTML 지원)을 잘하면 충분함

    • Vue의 Web Components 지원은 매우 좋고, React 19도 마침내 잘 지원하기 시작함
      Web Components 생태계가 엉망인 건 사실이지만, 이런 식으로 “모든 프레임워크에서 재사용 가능한 컴포넌트”를 제공하는 게 Web Components의 진정한 킬러앱임
      이걸 “바닐라 자바스크립트용”이 아니라 “이제 모든 프레임워크 지원”이라고 홍보하지 않는 게 놀라움

    • 그들은 Figma 디자인 라이브러리도 운영했는데 지금은 없어짐
      디자이너와 협업하려면 참 아쉬운 사례임

    • 이름 그대로 tailwindcss를 지향함

  • 커스텀 엘리먼트의 이런 활용 사례가 흥미롭다고 생각했는데, Tailwind에서는 이게 유료 기능이라 좀 황당함
    감각적으로는 커스텀 엘리먼트는 무료고 프레임워크 연동만 유료가 더 자연스러울 거라 기대함
    Tailwind Plus 가격정책

    • 약 $250,000 들여 이 라이브러리를 개발했기 때문에 유료임
      그냥 무료로 제공하고 유지보수하려면 불가능했을 것이고, 실력 있는 엔지니어들이 정당한 보상을 받아야 함

    • Tailwind Plus는 UI 컴포넌트 및 템플릿 모음 유료 컬렉션임
      TailwindCSS 본체는 Bootstrap처럼 스타일링 도구에 불과함

    • 또다른 유료 기능으로 SSO 같은 것도 유명함
      왜 유료인지 직관적으로 납득이 안 가지만, 의도적으로 도입 의사 결정 시기를 늦추려는 전략임

    • 이런 걸 유료로 파는 게 좀 이상함
      무료가 기본인 웹 개발 세계에서 프레임워크를 평생 사용하려면 구독료를 내야 하는 구조면 이상할 수 있음
      마치 Postgres가 월 별 사용료를 요구하는 상황 같음
      하지만 가격 정책을 보니 평생 한 번 구매하는 구조이긴 함
      이 방식이 얼마나 잘 통할지 궁금함

  • Alpine.js가 tailwindcss plus의 custom block elements에서 사라진 것 같음
    코드 예시에 더 이상 alpinejs가 안 나오는 걸 보고 실망임
    이제는

    <!-- <script src="https://cdn.jsdelivr.net/npm/@tailwindplus/elements@1"; type="module"></script> -->
    

    이런 식으로 대체됨
    알파인 썼던 입장에서 복붙 예제를 사용할 수 없게 되어 아쉬움

  • 이 기능은 tailwind 무료 사용자에게도 꼭 열려 있으면 좋겠음
    매우 흥미롭고 한 번 써보고 싶은데 무료로는 체험조차 안 되는 게 아쉬움
    그래도 오픈소스는 항상 후원이 쉽지 않다는 걸 알기 때문에 tailwind에 감사를 표함
    언젠가는 오픈소스에 기부하고, 기여하는 사람이 되고 싶음

  • <el-command-palette>처럼 Elements에 고급 명령 팔레트 같은 걸 만들 수 있다고 하는데, 실제로 저 기능을 그 컴포넌트로 직접 추가한 것이어서 가능해진 것임

  • 최근 Tailwind를 더 많이 사용해 보면서 편의성과 디자인 시스템 설계의 번거로움을 추상화해주는 강점이 있다는 걸 인정하게 됨
    하지만 장기적으로 볼 때, 직접 디자인 시스템과 컴포넌트 라이브러리에 투자하는 것이 DX, 유연성, 미적 언어, 의존성 측면에서 훨씬 더 충실한 솔루션이 됨