- 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를 재구현하는 것도 흥미로운 방향이 될 수 있음