Gumroad가 htmx를 선택하지 않은 이유

 (htmx.org)
6P by GN⁺ | ★ favorite | 댓글 1개
  • Gumroad는 새 프로젝트 Helper에서 가벼운 프런트엔드를 기대하며 htmx를 검토했지만, 복잡한 UX 요구가 커지면서 React/Next.js로 전환함
  • 단순 상호작용에는 htmx가 유망했지만, 동적 검증과 조건부 필드가 있는 폼에서는 서버 측 로직이 장황해져 개발 흐름이 부자연스러웠음
  • 워크플로 빌더의 드래그앤드롭, 실시간 협업, 복잡한 상태 관리, 동적 폼 생성은 React 생태계와 컴포넌트 모델에서 더 직접적으로 구현됨
  • 문제 해결 자료와 AI 도구 지원은 Next.js와 React 쪽이 더 풍부했고, htmx는 오픈소스 학습 데이터 부족 때문에 개발 속도에서 불리했음
  • htmx는 기존 서버 렌더링 앱이나 단순한 상호작용 모델에는 적합할 수 있지만, Helper처럼 상태가 많은 인터페이스에는 React와 Next.js가 더 잘 맞았음

Helper에서 htmx를 검토한 배경

  • Gumroad는 새 프로젝트 Helper를 시작하면서 htmx를 프런트엔드 후보로 검토함
  • 초기 기대는 React가 필요 이상으로 무겁다는 기존 경험에서 나왔고, htmx가 단순한 상호작용을 가볍게 추가하는 방법이 될 수 있다고 봄
  • 팀 내부에서는 htmx가 복잡해진 JavaScript 생태계를 풍자하는 밈과 비슷하다는 평가도 있었음
    • Tailwind가 인라인 CSS의 다른 문법처럼 보이듯, htmx도 인라인 JavaScript의 다른 문법에 가깝다는 시각이 있었음
  • Tailwind는 Gumroad의 도구 체계에 자리 잡았지만, htmx는 Helper의 목적에 맞게 확장되지 않았고 고객에게 가장 좋은 사용자 경험으로 이어지지 않았음

React/Next.js가 더 자연스러웠던 지점

  • 개발 경험과 폼 처리

    • htmx로도 올바른 구현은 가능했지만, Gumroad는 Next.js에서 기능을 동작시키는 과정이 더 직관적이라고 느꼈음
    • 동적 검증과 조건부 필드가 있는 복잡한 폼에서는 React의 클라이언트 측 작업이 더 단순했고, htmx에서는 서버 측 로직이 길어짐

  • UX와 상호작용 제약

    • htmx는 앱을 Rails/CRUD 방식으로 밀어가는 경향이 있어, 기본 경험이 평범하거나 일반적인 형태가 되기 쉬웠음
    • 워크플로 빌더의 드래그앤드롭 인터페이스는 htmx에서 우회 구현이 필요했고, React 라이브러리로 얻는 매끄러운 경험보다 투박하게 느껴졌음

  • AI 도구와 문제 해결 속도

    • AI 도구는 Next.js에는 익숙하지만 htmx에는 덜 익숙했으며, 그 이유로 오픈소스 학습 데이터 부족이 꼽힘
    • React/Next.js 쪽 자료가 풍부해 문제가 생겼을 때 해결책을 찾는 속도가 더 빨랐음

  • 복잡도와 확장성

    • 프로젝트가 복잡해질수록 htmx의 단순함은 장점보다 제약에 가까워짐
    • 실시간 협업과 복잡한 데이터 시각화가 추가되면서, htmx의 서버 중심 접근에서는 여러 컴포넌트 사이의 상태 관리가 점점 어려워졌음

Helper 기능별로 드러난 차이

  • 드래그앤드롭: React 생태계의 react-beautiful-dnd는 적은 설정으로 매끄럽고 접근성 있는 드래그앤드롭을 제공함
  • 복잡한 상태 관리: 각 워크플로 단계의 설정과 조건 로직을 실시간으로 UI에 반영하는 데 useState나 Redux 같은 React 상태 관리 방식이 더 직접적이었음
  • 동적 폼 생성: 단계 유형마다 다른 설정 폼을 만들고 사용자 입력에 따라 바꾸는 작업은 React 컴포넌트 모델에서 더 직관적으로 처리됨
  • 실시간 협업: 여러 사용자가 동시에 워크플로를 편집하는 기능은 WebSockets와 React로 비교적 직접 구현됐고, htmx에서는 더 복잡한 서버 측 로직과 커스텀 JavaScript가 필요했음
  • 성능 최적화: 워크플로가 커지고 복잡해질수록 React의 virtual DOM, useMemo, useCallback 같은 훅으로 렌더링을 세밀하게 최적화할 수 있었음

생태계와 최종 판단

  • React/Next.js 생태계는 크고 성숙해 Gumroad가 마주친 거의 모든 문제에 대한 해법을 제공함
  • htmx에서는 기능을 타협하거나 직접 다시 만드는 상황이 많았고, 서드파티 서비스와 라이브러리 통합에서도 React 바인딩은 있지만 htmx 대응물이 없는 경우가 있었음
  • React/Next.js로 옮긴 뒤 Gumroad는 복잡한 UX를 구축하는 데 더 잘 맞는 선택이었다고 평가함
    • 더 빠르게 움직일 수 있었고, 더 몰입감 있는 사용자 경험을 만들 수 있었으며, 기존 도구와 라이브러리를 활용할 수 있었음
    • Helper의 핵심 고객을 위한 앱 사용자 경험도 크게 개선할 수 있었음
  • htmx의 한계가 극복 불가능한 것은 아니지만, 해결 과정이 htmx의 강점에서 벗어나 JavaScript 중심 환경에 더 자연스러운 해법으로 이동하게 만들었음
  • htmx는 단순한 상호작용 모델이나 기존 서버 렌더링 앱 위에 구축된 프로젝트에는 좋은 선택이 될 수 있음
  • Helper처럼 복잡하고 상태가 많은 인터페이스에서는 React와 Next.js가 더 적합했으며, Gumroad는 필요 변화와 새 기술에 따라 기술 스택을 계속 다시 평가할 수 있다고 봄

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 다른 스레드에서 남겼던 내용인데, Gumroad CEO가 Twitter에서 어떤 프로젝트에 htmx를 써봤지만 결국 NextJS를 선택했다고 말했음
    htmx 웹사이트에 올릴 만한 사려 깊은 부정적 경험담을 찾고 있어서, 경험을 글로 써줄 수 있냐고 물었고 흔쾌히 동의해줘서 고마웠음

    • htmx가 항상 최선이 아닐 수 있는 지점을 직접 드러내는 태도 때문에 프로젝트를 더 존중하게 됨
      모든 것에 최선의 해법이라고 주장하는 다른 프로젝트들과 비교하면 신선함
      특히 드래그 앤 드롭 관련 지적이 궁금한데, htmx에서 정말 어렵다고 보는지, 그렇다면 해결할 계획이 있는지도 궁금함
    • Gumroad CEO는 Rails 자체가 기술 부채라고도 했고, 이유를 묻자 React가 훨씬 낫다고만 답했음
      Rails와 React를 같이 쓸 수 없는 것도 아닌데 그렇게 말한 셈임
      글 자체는 htmx에 대한 부정적 경험이라기보다, 드래그 앤 드롭과 실시간 협업이 등장하는 순간 애초에 htmx를 실험한 선택이 잘못이었을 수 있다고 봄
      스크린샷이 무엇을 보여주려는지도 잘 모르겠지만, 그래도 htmx 웹사이트에 올리기에는 좋은 글이라고 생각함
    • htmx가 다른 도구보다 덜 적합할 수 있는 지점을 보여주는 건 존중할 만함
      내게 htmx는 React 대체재라기보다 jQuery 대체재에 가까움
      htmx와 jQuery는 문서에 상호작용을 더하고, React는 문서 전체가 되려고 함
      작업에 따라 도구가 달라져야 함
    • 링크된 글과 https://htmx.org/essays/htmx-sucks/를 보고 나니, htmx를 쓰거나 남에게 추천하지 않겠다고 마음먹게 됨
    • 다른 스레드는 https://news.ycombinator.com/item?id=41727315임

  • “AI와 도구 지원: AI 도구는 Next.js에는 매우 익숙하지만 htmx에는 그다지 익숙하지 않다는 점도 worth noting”이라는 부분이 단점처럼 담담하게 쓰였지만, 개발 도구·라이브러리·프레임워크·언어의 미래에는 꽤 섬뜩한 징조임
    예측하자면 대규모 언어 모델은 기존의 승자독식과 선점 효과를 더 키울 것이고, 더 많고 좋은 학습 데이터 덕분에 오픈소스 도구 사용도 더 장려하게 될 것임

    • AI와 도구 지원 문제는 사실 커뮤니티와 생태계 문제의 연장선임
      대규모 언어 모델 이전에도 React는 질문 대부분이 StackOverflow에 이미 있고, 거의 모든 용도에 성숙한 라이브러리가 있다는 장점이 있었음
      이제는 예전에 StackOverflow에 물어봤을 질문을 대규모 언어 모델에 묻는 사람이 생겼을 뿐이고, 결과는 같음
      남들이 많이 쓰는 걸 쓰면 장점이 생김
    • 대규모 언어 모델이 개발 도구의 승자독식과 선점 효과를 키운다는 건, 코딩을 대규모 언어 모델에 의존하는 사람에게는 맞을 것임
      다만 소프트웨어 엔지니어 경력의 장기 전략으로는 별로 좋은 베팅이 아니라고 강하게 봄
    • AI 도구는 특정 시점에 갇혀 있고, 새 자료로 학습시켜도 학습할 정보량에는 한계가 있음
      오히려 이게 좋은 일일 수도 있다고 생각해봤음
      소프트웨어 업계는 최신 도구, 언어 기능, 프레임워크를 쫓느라 너무 많은 시간을 씀
      조금 정체돼서 6개월마다 새 망치를 만들기보다 이미 가진 도구로 일을 끝내는 쪽이 긍정적일 수도 있음
    • 개발자가 자기 코드를 대신 써주는 무언가 없이는 일할 수 없다면, 애초에 왜 채용하는 건지 모르겠음
    • 이 점은 크게 걱정하지 않고, Gumroad의 우려도 과장됐을 가능성이 큼
      실제로 AI가 HTMX를 잘 못 다뤘다는 경험인지, 아니면 다른 자료 부족 이야기로 넘어간 건지 댓글만으로는 알 수 없음
      대규모 언어 모델은 종종 범용 번역기처럼 매우 잘 작동함
      인기 프레임워크의 일반 패턴과 개념을 익히고, 더 작은 프레임워크의 문법을 어느 정도 알면, 경험상 꽤 좋은 틈새 프레임워크 코드도 생성함
      해적들이 학습 데이터에서 말한 적 없는 주제도 해적 말투로 이야기할 수 있는 것과 비슷함

  • “동적 검증과 조건부 필드가 있는 복잡한 폼을 만들 때, React에서는 간단한 클라이언트 측 작업일 일을 처리하려고 복잡한 서버 측 로직을 작성하게 됐다”는 부분을 보면 Anakin Padme 밈이 떠오름
    “그래도 서버 측 검증도 구현하는 거 맞지… 맞지?”

    • 웹 폼이 종이 양식보다 복잡하다면, 그 웹 폼 자체를 다시 생각해봐야 하지 않을까 싶음
      React에서는 쉽지만 htmx에서는 어려운 폼은, React식 전역 애플리케이션 상태를 꽂아 넣고 라이브러리로 90% 끝내고 싶은 경우 말고는 잘 떠오르지 않음
    • 서버에서도 검증은 함
      다만 페이지마다가 아니라 제출 시 한 번 하는 것임

  • “프런트엔드를 아주 가볍게 유지하는 데 htmx가 좋은 해법일 수 있다고 생각했다”는 말과 달리, 가벼운 프런트엔드를 포기하자마자 htmx가 맞지 않게 된 것처럼 보임
    복잡한 UI/UX와 상태 관리를 렌더링하려고 서드파티 라이브러리를 쓰기 시작했음
    또한 “React에서 X를 하기가 더 쉬웠다”고 말하는 건 그걸 서드파티 라이브러리로 했다면 공정한 비교가 아님
    누군가 대신 해줬기 때문에 직접 하지 않아도 된 것뿐임
    글에는 많이 공감하지만, 복잡한 상태와 렌더링이 필요하다는 걸 알고 있었다면 htmx는 처음부터 좋은 해법이 아니었다고 봄

    • 정확히 그렇다고 봄
      htmx를 좋아하지만, 이 글은 작성자가 기술적 이해가 꽤 부족했다는 걸 보여줌
      웹 플랫폼과 htmx.org 문서를 조금만 알아도 드러날 장단점이 아니라, 분위기만 보고 HTMX를 써보고 싶었던 것에 가까워 보임
    • 애초에 React를 쓰지 말았어야 할 사람들이 “React 앱을 htmx로 바꾸니 모든 게 훨씬 좋아졌다”는 글을 쓰는 것과 좋은 대칭을 이룸
    • htmx 대 JavaScript 구도는 behave의 행동 주도 개발 테스트와 pytest 테스트를 떠올리게 함
      Gherkin 언어는 단순한 경우에는 좋아 보이고 원칙적으로 복잡한 경우에도 확장할 수 있지만, 추상화 수준을 여러 겹 관리해야 할수록 순수 Python인 pytest가 더 편해짐
    • 나도 똑같이 생각했음
      프로젝트 범위가 전혀 “단순”하지 않았고, 내 경우라면 바로 React로 갔을 것임
    • 원하는 기능 설명만 봐도 무거운 JavaScript가 필요할 수밖에 없어 보였음

  • “워크플로 빌더용 드래그 앤 드롭 인터페이스 구현은 htmx에서 큰 도전이었고, React 라이브러리로 얻을 수 있는 매끄러운 경험에 비해 투박한 우회가 필요했다”는 부분에 대해, HTMX는 프런트엔드 번들이 필요한 만큼만 하고 그 이상은 하지 않을 때 더 좋음
    htmx.onLoad 이벤트에 연결한 뒤 로드된 콘텐츠 안에서 속성이 붙은 마크업, 예컨대 columns, cards, tasks 등을 찾아 붙이면 됨
    예를 들어 렌더링된 마크업에 sortable.js를 바인딩하고, sortable 이벤트를 HTMX를 통한 상태 업데이트에 연결할 수 있음
    꽤 간단하고, 문서에도 정확히 이런 예제가 있음: https://htmx.org/docs/#3rd-party

    • HTMX를 UIKit 컴포넌트와 함께 쓰고 있음
      현대적이고 상태를 가지며 동적인 웹사이트는 HTMX와 전혀 양립 불가능하지 않음

  • 글을 읽어보면 팀이 백엔드 개발보다 프런트엔드 개발에 더 익숙해 보임
    오래된 방식의 개발자 입장에서 보면, 프런트엔드 개발자가 생각하는 방식에 작은 두려움과 오해가 보일 때가 있음
    솔직히 이런 방식이 어떻게 작동하는지 이해하려면 사고를 조금만 조정하면 된다고 보지만, 많은 사람이 경력 내내 일반적인 클라이언트/서버 접근을 본 적이 없다는 점도 이해함
    그렇다고 해도 기성 React 컴포넌트의 가치와 문서·도움말을 찾기 쉬운 장점은 무시할 수 없음

    • 개발자뿐 아니라 UX 디자이너가 React식으로 생각하는 것도 htmx 도입의 가장 큰 장벽이라고 봄
      한 세대의 디자이너들이 모바일과 웹을 매우 비슷하게 설계하고, 그 구현 복잡도를 개발자에게 떠넘겨왔음
      하지만 웹은 가능하면 모바일과 달라야 하고, 달라도 됨
      글에서는 CRUD 앱처럼 디자인이 너무 “generic”했다고 말하지만, 그게 정말 나쁜가?
      모든 사이트에서 예측 가능한 사용자 경험을 만들 수 있도록 보편적으로 채택된 문서 모델이라는 대단한 성과가 있는데, 우리는 그걸 “지루하다”고만 봄
      지루함 자체에 본질적으로 문제가 있는 것처럼 여김
      모바일 앱처럼 느껴지는 독특하고 브랜드화된 경험을 요구하는 시장 압력은 이해하지만, 디자이너들이 React식 사고만큼 WWW식 사고도 할 수 있다면 어떨지 상상하게 됨

  • HTMX가 이런 글과 비슷한 글들을 자기 사이트에 올리는 점이 좋음
    HTMX만으로는 잘 맞지 않았던 합당한 이유가 꽤 있어 보임
    프런트엔드 전문가는 아니지만 몇 가지 생각이 있음
    첫째, 어차피 백엔드에서도 폼 검증을 해야 하지 않나?
    백엔드 시스템이 프런트엔드에 결과를 전달하는 게 왜 그렇게 어려웠는지 궁금함
    많은 경우 프런트엔드와 백엔드 양쪽에서 폼 검증을 해야 할 훌륭한 이유가 있으니 그럴 때는 HTMX만으로 부족하겠지만, 이 문제의 표현은 조금 혼란스러움
    둘째, HTMX만 쓰면 앱이 이런 방향으로 어느 정도 밀릴 수 있고, 어떤 경우에는 좋은 일이지만 이들은 고객을 위해 다른 방식이 필요하다고 판단한 듯함
    셋째, AI 도구 의존이 주요 문제가 될 만큼 이 팀이 어떻게 AI 도구를 쓰고 있었는지 더 알고 싶음
    앞으로 AI 개발 도구가 중요해지면 새 프레임워크나 프로그래밍 언어가 도입될 만큼 충분한 도구와 통합을 확보하기 위한 기준이 너무 높아질지도 흥미로운 질문임
    넷째, HTMX에 대한 흔한 불만처럼 어떤 프로젝트는 HTMX가 제공하는 것 이상을 요구함
    다섯째, Django와 Python을 좋아하는 이유 중 하나도 깊은 커뮤니티와 통합, 애드온 생태계임
    개념은 비슷하면서 HTMX보다 기능이 더 많은 https://unpoly.com/ 같은 것이 이들에게 더 잘 맞았을 수도 있음

  • “Next.js의 개발 과정이 자연스럽게 느껴졌다”는 말에 대해, 이 ReactJS 문법의 어느 부분이 자연스러운지 모르겠음
    익숙할 수는 있어도 자연스럽지는 않음
    useEffect(() => { const timer = setInterval(() => { setCount((prevCount) => prevCount + 1); }, 1000); return () => clearInterval(timer); }, []);

    • 내가 알기로 HTMX에는 타이머와 인터벌에 대한 우아한 해법이 없음
      결국 JavaScript로 어색하게 연결해야 할 것임
    • 이 코드 예시는 꽤 관대한 편임
      가변 타임아웃이 있는 커스텀 훅을 원하면 훨씬 복잡해질 수 있음
      Dan도 이 주제로 긴 글을 써야 했음: https://overreacted.io/making-setinterval-declarative-with-r...
    • 이 사용 사례에서 자연스럽게 보이는 코드는 무엇인지 궁금함
      코드를 써볼 수 있나?

  • htmx.org가 이 글을 호스팅한 건 칭찬할 만함

    • 어떤 서비스나 도구가 왜 써야 하는지뿐 아니라 왜 쓰지 말아야 하는지도 설명해주면 정말 가치 있다고 봄
    • 이런 글을 올린 건 정말 겸손하고 정직한 태도임
      결국 누군가 htmx를 집어 들었다가 자기 요구를 충족하지 못한다고 화내면 이제 가리킬 수 있는 자료도 생김
    • https://htmx.org/essays/의 “On The Other Hand…” 아래에 링크돼 있음
    • 처음에는 약간의 rant나 비꼬는 글을 예상했는데, 실제로는 좋은 포인트가 있는 좋은 글이라 반가웠음
      내 프로젝트 몇 개에서 htmx를 쓰고 있고 꽤 좋았음
      이런 글은 htmx가 잘하는 곳과 부족한 곳을 드물게 보여주기 때문에 오히려 htmx 사용에 더 확신을 줌

  • 세 번째 포인트가 무섭게 느껴짐
    회사들이 자기 프레임워크가 모델 학습 세트에 과대표집되도록 돈을 내고, 그걸 바탕으로 계약을 파는 세상을 상상하게 됨
    검색 엔진 최적화가 개발 도구 안에 baked in 된 것과 비슷함

답변달기