Hacker News 의견들

• 나는 htmx의 창시자임. 과장된 기사 덕분에 주목받는 건 고맙지만, 이런 식의 하이프는 별로 좋아하지 않음
  웹앱을 만드는 방식은 다양하고 각각 장단점이 있음. htmx의 강점과 약점을 이 글에서 정리했음
  또 다른 훌륭한 hypermedia 지향 라이브러리인 Unpoly도 꼭 써보길 추천함
  (추가) 기사 내용을 다시 보니 생각보다 괜찮았음. 그래도 htmx는 좀 더 차분한 분위기로 다뤄지길 바람

  • 1999년대 초 웹앱을 만들던 방식에 익숙하다면, HTMX는 적은 노력으로 인터랙티브한 기능을 쉽게 추가할 수 있음
    드롭다운으로 필드 업데이트, 모달 생성, 자동완성 검색창 등 모두 간단함
    다만 RIA 프론트엔드의 복잡성은 데이터 변경 시 프론트엔드를 어떻게 업데이트하느냐에 있음.
    백엔드에서 일부 조정이 필요하고, 여러 partial 업데이트를 함께 처리할 수 있는 구조가 있으면 더 좋음
  • HTMX Sucks라는 글도 있음. 흥미로운 관점임
  • Unpoly가 정말 멋져 보임. 아직 HTMX는 안 써봤지만, Django나 Rails 같은 프레임워크의 UX 문제를 가볍게 해결해주는 점이 마음에 듦
    현재 Rails + Stimulus로 사이드 프로젝트를 하는데, Stimulus가 오히려 과한 느낌임. Inertia나 Stimulus를 언제 선택해야 하는지 궁금함
  • 참고로 나는 htmx의 CEO인데, 이런 과장된 기사들 정말 좋아함
  • Unpoly의 문서도 훌륭하지만 약간 복잡하다고 느낌. 더 단순한 경우엔 Alpine AJAX를 씀.
    Alpine.js 플러그인으로 링크와 폼에 기본적인 AJAX 기능을 추가해줌

• “Hello World” 예제로 React보다 낫다고 주장하는 글들에 지침
  단순 예제에서는 뭐든 잘 돌아감. 하지만 실제로는 의존성이 많은 백엔드와 복잡한 UI가 대부분임

  • 초간단 프레임워크에 대한 개발자들의 두려움은 결국 확장성의 한계에 부딪힐 때임
    기본 데모는 좋지만, 더 복잡한 기능을 추가할 때 어떻게 확장할 수 있는지 보여줘야 함
    JS를 어디에 추가할지, 빌드 스텝이 필요한지, htmx의 패러다임에 얼마나 묶이는지 궁금함
  • Fizzy처럼 37signals가 Hotwire로 만든 앱도 있음.
    React보다 낫다기보단 또 다른 접근 방식일 뿐임
  • 우리 인트라넷은 Python + HTMX 조합으로 돌아감. 아직까지 못 한 게 없음
    DOM 일부를 교체하는 패러다임이 매우 단순하고 직관적임
  • 반대로, 너무 복잡한 기술이 “Hello World”부터 어렵다는 경우도 있음
    예: effect-ts는 강력하지만, 단순 출력조차 복잡함
  • Go + Htmx로 만든 실시간 플래닝 포커 앱이 있음. 약 500줄 코드로 구현됨

• 우리 스타트업은 HTMX를 도입했다가 결국 React로 전환 중임
  HTMX는 응답 처리 복잡도가 높고, 각 엔드포인트가 여러 HTML 조각을 반환해야 함
  문서와 사례가 부족하고, 대규모 베스트 프랙티스도 없음.
  React는 성숙하고, AI 코딩과의 궁합도 좋음. HTMX는 단순 프로젝트엔 적합하지만 그 이상은 어려움

  • 나는 HTMX로 매끄러운 아키텍처 패턴을 찾았음
    각 엔드포인트는 하나의 역할만 수행하고, Optimistic UI로 즉시 반응함
    에러 처리는 단순하게, hx-swap-oob는 최소 사용
    기술 선택의 핵심은 트레이드오프를 최소화하는 것임
  • 프론트와 백엔드가 모든 시나리오에 합의해야 한다는 건 당연함.
    그래서 나는 백엔드 검증 중심으로 두고, 프론트는 단순히 표시만 하게 함
  • Hypermedia Systems 책이 통합적인 설명을 더 잘 해줌
  • 이해하지 못한 틈새 솔루션을 선택했다가, 또 다른 복잡한 걸로 옮기는 건 트레이드오프를 반복하는 일임
  • “AI 코딩에 좋다”는 이유로 기술을 선택하는 건 좀 슬픈 일임

• 나는 SSR을 원하지 않음. 백엔드는 JSON API만 제공하고, 프론트는 그걸 소비함
  SSR은 과대홍보된 개념이라 생각함. 클라우드 서비스 판매를 위한 유도 전략 같음

• Demo 3 Live Search 예제는 스크롤 지연(jank) 문제가 심함.
  결과가 문서 내에 직접 삽입되어 레이아웃이 계속 재계산되는 듯함

• React는 충분히 괜찮음. 단순한 프로젝트라도 굳이 다른 패러다임을 배울 이유가 없음

  • React도 결국 HTML로 렌더링되므로, HTML/CSS를 배워야 함. 단지 추상화가 있을 뿐임
  • React 생태계는 너무 넓어 계속 배우고 잊어야 하는 피로감이 있음
    반면 HTMX는 15분이면 개념을 익히고, 10년은 써먹을 수 있음
  • React나 Angular는 MVC 위에 또 다른 MVC를 얹은 구조임. 불필요하게 복잡함
  • 무거운 솔루션을 모든 곳에 쓰는 건 비효율적임.
    역사적으로 가벼운 패러다임이 시장에서 이김. React도 한때 그런 존재였음
  • 이유는 단순함 — 성능

• 나는 HTMX가 아니라 Alpine.js에 완전히 반했음
  서버 렌더링된 HTML을 강화(enhance) 하는 개념이 클릭됐음
  드롭다운, show/hide 등 모두 직관적이고 빌드 스텝이 필요 없음

  • Alpine에도 Alpine AJAX 플러그인이 있어 HTMX와 유사한 기능을 제공함
  • 나도 Alpine.js를 쓰며 프론트엔드가 다시 즐거워졌음
    직관적이고 대규모 프로젝트에서도 관리가 쉬움
  • 하지만 상용 프로젝트에서는 Alpine이 악몽이 될 수 있음
    JS를 HTML에 인라인으로 넣다 보면 유지보수가 어렵고, 상태 관리도 암묵적임
    Hotwire나 Stimulus가 조직 규모에서는 훨씬 낫다고 느낌
  • 선언적 접근이 정답임

• 대규모 앱에서 HTMX를 쓴다면 서버 부하와 비용이 궁금함
  HTML을 서버에서 렌더링하니 JSON보다 처리량이 많을 것 같음

  • 하지만 꼭 그렇진 않음. 템플릿 렌더링은 매우 빠름
    JSON 직렬화보다 효율적일 때도 많고, 클라이언트에서도 역직렬화 비용이 있음
    HTMX는 Alpine.js 같은 도구와 함께 쓰면 복잡한 상태도 쉽게 처리 가능함
    모든 상황에 맞진 않지만, 많은 경우에 매우 잘 작동함

• 프레임워크 전도는 웹 생태계의 최악의 문화임
  좋은 솔루션이라면 결국 채택될 것임. 굳이 전도사처럼 굴 필요 없음
  npm 공격도 과장임. htmx도 결국 npm을 쓸 수밖에 없음

  • htmx는 의존성 없는 단일 파일이라 npm이 꼭 필요하진 않음
  • “좋은 솔루션은 자연히 채택된다”는 말은 틀림.
    세상엔 마케팅과 인지도로 채택된 나쁜 솔루션이 많음
  • 인기와 예산, 관성이 기술 채택을 좌우함.
    진짜 장인정신을 지키려면 이런 편향에 맞서야 함

• HTMX는 양쪽 세계의 단점만 합친 것처럼 보임
  SSR은 응집력 있고, CSR은 분리된 구조인데, HTMX는 둘 다 섞여 암묵적 결합이 생김
  같은 데이터를 다른 형식으로 보여주려면 백엔드에서 두 엔드포인트를 만들어야 하는지 의문임

  • 프론트엔드 상태가 꼭 필요하다는 생각에서 벗어나야 함
    대부분의 앱은 백엔드 상태만으로 충분하고, UX 향상 외엔 큰 이득이 없음
  • Splitting Your APIs 글을 보면 오히려 좋은 점임
  • Jinja 같은 서버 템플릿을 쓰면 한 번의 렌더링으로 여러 표현 형식을 처리할 수 있음
    전체 페이지를 서버에서 구성하면 데이터는 이미 그 안에 있음