▲

GN⁺: Htmx에 대한 온건한 비판

 (chrisdone.com)
7P by neo 2달전 | favorite | 댓글 12개
  • Htmx의 기본적이고 단순한 아이디어는 정말 마음에 들지만, 팀 전체에서 사용해 본 결과 실제로는 간단하지 않고 상당히 복잡하다는 것을 알게 되었음

Htmx 속성 상속은 확실한 실수임

  • 코드 조각에서 속성 상속이 암시적이고 놀라움
  • CSS에서처럼 상속은 값싼 해킹이지만 댓가를 치름
  • 저자의 행동 지역성 주장과 모순됨
  • 여러 속성에서 기본 상속이 다름 (예: hx-delete는 상속되지 않지만 hx-confirm과 hx-ext는 상속됨)
  • 예외를 기억해야 하고 모든 것을 명시적으로 표현하게 되어 상속이 무의미해짐

대부분의 흥미로운 웹 앱은 DOM 요소를 전체적으로 교체할 수 없음

  • DOM 요소는 거의 항상 브라우저 로컬 상태를 가짐 (예: <details> 요소의 열림/닫힘 상태, <input> 요소의 입력값, 드롭다운 요소의 열림/닫힘 상태)
  • Htmx가 outerHTML을 직접 교체하는 단순한 방식을 쓰면 이런 상태가 모두 손실됨
  • Morphdom 확장도 예상과 다르게 일부 요소를 덮어씀

DOM 요소 자체에 상태를 저장하는 것은 나쁜 생각임

  • Morphdom은 이전 제목의 고통을 해결하기 위한 것이지만, Htmx의 작동 방식은 요소를 전체적으로 교체하는 것을 기반으로 한다는 것을 발견함
  • 요청 큐를 DOM 요소 자체에 저장함
  • 요청을 시작하면 해당 요소 또는 그것을 가리키는 다른 요소에서 요청 큐를 가짐
  • DOM 요소를 전체적으로 교체하면 큐가 재설정되어 일부 나쁜 실패 모드를 피할 수 있음
  • 그러나 Morphdom에서는 요소가 유지되므로 큐도 유지됨
  • Htmx의 설계가 위반되는 일종의 정의되지 않은 동작 영역에 있게 됨

기본 큐잉 모드는 엉망임

  • 기본적으로 Htmx는 동일한 큐(요소)에서 다른 요청을 트리거하면 진행 중인 요청을 취소함
  • 이것이 기본 전략임
  • 이 사실을 나중에 발견함
  • 매우 직관적이지 않고, 작업을 잃어버리는 것을 의미함

이벤트 트리거는 지역적이지 않음

  • 이벤트 트리거는 종종 무언가 일어나게 하는 데 도움이 되지만, 지역적이지 않은 효과이며 속성 상속과 유사한 문제가 있음
  • 서버 측 언어에서 DSL 작업을 하면 이를 어느 정도 도울 수 있지만, 구식 JavaScript 콜백 기반 프로그래밍과 비슷한 느낌임
  • 이벤트가 발생하면 "구독"하고 무언가를 수행함

컴포넌트 상태를 잘 유지할 수 없음

  • DOM 요소 상태 문제와 유사한 더 광범위한 문제는 자신만의 컴포넌트에 자체 상태가 있다는 것임
    • 예를 들어, 서버에 필요한 자체 상태(예: 결과 집합의 페이지)와 React나 WebComponents에 필요한 상태를 가진 세 개의 섹션으로 구성된 페이지를 원하는 경우, 부모 컴포넌트와 자식 컴포넌트 간에 상태를 동기화하는 문제가 있음
  • Htmx는 이에 대한 좋은 방법을 제공하지 않음
    • 쿼리 매개변수, 숨겨진 폼 입력, 이벤트 트리거 등을 사용하는 아이디어가 있지만 모두 큰 주의사항이 있음
  • React와 Halogen은 이에 대한 답을 가지고 있음
    • 두 경우 모두 자식 컴포넌트는 자체 상태를 가지며, 부모는 "조언"과 같은 "props"를 제공할 수 있음
    • 또한 자체 내부 상태도 가지며, props보다 무시하거나 우선순위를 둘 수 있음
    • props는 일반적으로 서버에서 제공되거나 서버에서 파생되며, 상태는 일반적으로 클라이언트 측 상태임
  • React로 제공되는 기성품 컴포넌트나 사용해야 하는 컴포넌트에는 종종 React가 필요함
    • React와 Htmx는 잘 상호작용하지 않음
    • WebComponents로 만족스럽지 않은 작업을 했지만, 그것들은 놀라운 기괴한 제한이 있음
    • 서버 측 언어에서 사용하는 React 컴포넌트에 직접 브리지를 만들기도 했지만, 일반적으로 Htmx와 React는 상태 흐름과 DOM 요소 관리를 두고 싸움
    • Alpine을 사용해 보았는데 좋지만 또 다른 클라이언트 측 프로그래밍 라이브러리이므로 React가 이미 코드베이스에 있는 경우 중복됨

그럼에도 불구하고 장점은 있음

  • 서버 측 언어를 사용할 수 있다는 것은 엄청나게 명백하고 논란의 여지가 없는 이점
  • 팀 내 누구도 이 모든 비즈니스 로직을 TypeScript로 다시 작성하고 싶어하지 않을 것임
  • DB 유형에서 프런트엔드 유형으로의 직렬화가 필요하지 않음
    • 데이터 누출이 없고 GraphQL도 필요하지 않음
  • 서버 측 언어의 더 강력한 추상화 기능을 사용할 수 있음
  • 동일한 유효성 검사에 대해 프런트엔드와 백엔드 구현을 모두 하는 대신 서버 측 언어의 폼 빌더를 사용할 수 있음
  • 그러나 위의 단점들도 사실임

Htmx-in-React?

  • 매력적인 미래 방향은 React에서 Htmx를 재구현하는 것일 수 있음
    • 서버가 JSON 블롭을 보내면 React가 가상 DOM 컴포넌트로 변환함
    • 그러면 컴포넌트 상태 문제가 해결될 것임
    • React 컴포넌트를 사용하기 위해 특별한 브리지가 필요하지 않을 것임
    • React 연결 웹 페칭 라이브러리를 사용할 수 있고, Htmx에서 한 큐잉 선택을 주의 깊게 피할 수 있음
    • Morphdom 문제와 브라우저 DOM 입력 요소 문제도 해결될 것인데, 이는 React에서 거의 해결된 문제임
  • 이런 식으로 Htmx 종속성은 제거하면서 아이디어의 이점은 유지할 수 있음. 단, 그렇게 큰 작업을 시작할 수 있는 예산이 주어져야 함

GN⁺의 의견

  • Htmx의 기본 아이디어는 매력적이지만, 실제 사용 시 여러 복잡한 문제에 직면할 수 있음
  • 속성 상속, DOM 요소 교체, 큐잉 모드 등 Htmx의 일부 설계는 직관적이지 않고 예상치 못한 동작을 유발할 수 있음
  • React나 WebComponents와의 통합도 쉽지 않은 것으로 보임
  • 그럼에도 서버 측 언어를 사용할 수 있다는 것은 큰 장점
  • 향후 React 기반으로 Htmx를 재구현하는 것도 흥미로운 방향이 될 수 있음
▲
felizgeek 2달전  [-]

관심이 무관심보다 낫죠~ 저는 HTMX 좋아합니다. 철학과 함께.
SQLite과도 굉장히 결이 비슷해요ㅋㅋ

답변달기
▲
aer0700 1달전  [-]

Sqlite랑 비슷?

답변달기
▲
savvykang 1달전  [-]

SQLite와 HTMX가 어떤 점에서 비슷한가요?

답변달기
▲
halfenif 1달전  [-]

댓글이 심오합니다. 철학이라..

답변달기
▲
composite 2달전  [-]

아니 왜 한국에서 유별나게 더 그렇고 해외도 그렇고 자꾸 사람들이 htmx 를 react와 비교하려 하는지 이해를 못하겠네요. 애초에 목적과 목표가 완전히 다른 기술인데... 이정도면 누가 보면 react 가 프론트엔드 표준인줄 알겠네요...

답변달기
▲
heycalmdown 2달전  [-]

이 글은 한국에서 쓰여진 글은 아닌 것 같은데 말이에요.

답변달기
▲
savvykang 2달전  [-]

SPA 나오기 전 서버사이드 렌더링 & jQuery로 웹개발을 해본 경험이 있다면 그 쪽 기술인 걸 단번에 이해할텐데요. 아마 SPA로 웹개발에 입문하신 분들이 새로운 것을 추구하다가 착각하시는 것 같습니다

답변달기
▲
ndrgrd 2달전  [-]

그러게요. 간단한 페이지를 위해 만들어진 도구인 것 같은데 이상한 예시나 use case를 가져와서 그것에 알맞지 않다거나 하는 토론은 왜 벌어지는지 모르겠습니다.

답변달기
▲
roxie 1달전  [-]

htmx 의 대문 페이지에서 알 수 있듯이, htmx 은 (자기들만 있다면) react 를 포함한 모던 프론트엔드 기술이 필요없다는 입장에 가깝습니다

답변달기
▲
rlrsbtm80879 2달전  [-]

그건 htmx 가 주목받는 이유와 관련이 있죠. 이 글도 외국 기고글을 번역한 것인데 외국에서는 react 의 온갖 상태 관리에 지쳐있거든요. 그래서 react 와 비슷한 기능을 제공하면서도 react 와 달리 상태 관리가 필요 없는 htmx 를 react 대체재로 보았습니다. 그래서 계속 htmx 를 react 와 비교하는 거죠.

답변달기
▲
ndrgrd 2달전  [-]

글쎄요. 그런 이유면 react를 대체할 수 있다고 주장하는 것을 가져와서 비교하는 것이 맞는 것 아닌가요?

이 페이지에 나열된 특징만 봐도 HTMX가 복잡한 페이지에 들어갈만한 물건이 아니고 전혀 react를 대체할 수 있는 무언가가 아닌데요.

답변달기
▲
neo 2달전  [-]
Hacker News 의견

  • 속성 상속에 대한 의견이 엇갈림. htmx.config.disableInheritance 옵션으로 비활성화 가능함

    • 클라이언트 측 상태와 htmx 교체가 항상 잘 맞지 않음. 특히 간단한 경우에 그러함
    • 이벤트는 강력하지만 복잡하고 디버깅이 어려움. 이벤트 기반 프로그래밍의 특성임
    • 기본 대기 모드에 동의하지 않음. 기존 요청을 취소하고 교체하는 것이 아니라, 현재 요청을 유지하고 추가 요청을 하나만 대기시킴
    • htmx를 싫어하는 사람들을 위한 머그컵 홍보

  • 프론트엔드에 뛰어들지 않은 이유는 선택지가 많고 비판이 많으며, 기술 트렌드가 자주 변하기 때문임

    • 백엔드와 시스템 프로그래밍도 의견 충돌이 있지만, 프론트엔드보다는 덜 혼란스러움

  • HTMX를 사용하여 성능이 좋은 스토어프론트를 구축하고 있으며, 결과가 만족스러움

    • 브라질의 대형 의류 소매업체에서 HTMX와 부분 렌더링 전략을 사용 중임

  • "HTMX in React" 아이디어는 React Server Components를 재발명한 것과 같음

    • 서버가 JSON을 보내면 React가 이를 가상 DOM 컴포넌트로 변환함
    • 컴포넌트 상태 문제를 해결하고, 특별한 브리지 없이 React 컴포넌트를 사용할 수 있음
    • React와 연결된 웹 페칭 라이브러리를 사용할 수 있으며, HTMX의 대기 선택을 피할 수 있음
    • morphdom 문제와 브라우저 DOM 입력 요소 문제를 해결할 수 있음
    • RSC는 아직 실험적이며, 기본 구현은 서버에서 JS를 실행한다고 가정함

  • 기본 대기 모드가 비합리적이라는 의견에 동의하지 않음

    • 사용자가 입력을 제출하고 중간에 변경한 후 다시 제출하면 요청이 취소되어야 함
    • 응답이 다른 ID로 콘텐츠를 교체하면 두 번째 응답을 동일하게 교체할 수 없음

  • HTMX를 처음 사용해본 결과, 간단한 작업에서 쉽게 적용할 수 있었고 재미있었음

    • 복잡한 프로젝트에 사용할지는 아직 확신이 없음

  • 상태에 대한 불만을 읽고, 작성자가 React 이전에 웹사이트를 만들어본 적이 없다고 생각함

    • 예시가 이해되지 않으며, htmx를 React처럼 사용하려다 기대와 달라 실망한 것 같음

  • HTMX에 Turbo Mount와 같은 기능이 있는지 궁금함

    • Hotwire/Turbo를 사용하는 가장 좋은 방법 중 하나라고 생각함

  • morphdom이 예상치 않게 일부 요소를 덮어쓰는 문제에 대해 더 알고 싶음

    • 입력 요소와 세부 요소의 상태를 유지하는 것이 morphdom과 같은 라이브러리의 주요 기능임
답변달기