예전에는 반사적으로 Vue.js를 선택하곤 했습니다. 모든 프로젝트가 똑같은 방식으로 시작되었습니다. CLI를 설치하고, 라우터를 설정하고, 스토어를 구성한 뒤, 이 모든 것을 싱글 페이지 애플리케이션(SPA) 셸로 감싸는 식이었죠. 실시간 대시보드를 만들든 단순한 연락처 양식을 만들든 상관없었습니다. Vue는 저의 기본값이었고, 이보다 가벼운 것은 퇴보라고 생각했습니다.
이런 습관은 흔합니다. React나 Vue 생태계에서 수년간 시간을 보냈다면, SPA 모델이 당연하게 느껴지기 시작합니다. 그렇게 많은 메커니즘이 정말 필요한지 묻는 것을 멈추게 됩니다. 그냥 습관적으로 그것을 찾게 되죠. 시간이 흐르면서 저는 한 가지 우려스러운 점을 발견했습니다. 상태를 토글하고 테이블을 새로고침하기만 하면 되는 관리자 화면을 위해 Vuex 스토어를 연결하고 있었습니다. 이메일 주소만 제출하면 되는 랜딩 페이지를 위해 fetch 로직을 구성하고 있었습니다. 복잡함은 문제 자체에서 오는 것이 아니었습니다. 제가 선택한 도구에서 오고 있었습니다.
그러다 HTMX를 사용하기 시작했습니다. 그 변화는 예상보다 조용히 찾아왔지만, 제가 기술 스택을 선택하는 방식을 완전히 바꾸어 놓았습니다.
HTMX가 실제로 하는 일
대부분의 온라인 토론은 이 부분을 잘못 짚고 있습니다. 사람들은 이를 Vue 대 React 대 HTMX의 대결 구도로 몰아갑니다. 하지만 그런 비교는 핵심을 완전히 놓치고 있습니다. HTMX는 SPA 프레임워크가 아닙니다. Vue를 대체하려는 것도 아닙니다. HTMX는 브라우저가 기본적으로 제공하는 것보다 HTML이 더 많은 일을 할 수 있게 해주는 라이브러리입니다.
컴포넌트를 작성하여 마운트하고, JSON을 가져오고, 이를 로컬 상태로 파싱한 뒤 리스트를 다시 렌더링하는 대신, 버튼에 속성 하나를 추가하면 됩니다. 서버는 데이터 페이로드가 아닌 HTML 조각을 반환합니다. 브라우저는 그 콘텐츠를 제자리에 교체합니다. 여전히 서버 사이드 렌더링 페이지를 다루고 있지만, 사람들이 보통 무거운 JavaScript 프런트엔드와 연관 짓는 상호작용성을 얻을 수 있습니다.
이것은 성능 저하가 아닙니다. 다른 모델일 뿐입니다. Vue는 클라이언트 사이드 애플리케이션을 구축하고 브라우저에서 상태를 관리할 것을 요구합니다. 반면 HTMX는 상태를 서버에 유지하고 HTML을 네트워크를 통해 전송할 것을 요구합니다. 두 도구는 서로 다른 종류의 문제를 해결하기 때문에, 한 프로젝트 내에서 충돌 없이 공존할 수 있습니다.
Vue가 여전히 정답인 경우
복잡한 인터페이스에는 Vue가 필요합니다. 드래그 앤 드롭 위젯, 중첩 필터링, 그리고 여러 뷰에서 데이터를 공유하는 라이브 차트가 포함된 실시간 분석 대시보드를 구축한다면 반응형 프레임워크가 필요합니다. 브라우저가 해당 상태를 소유해야 합니다. 사용자가 차트를 드래그하거나 필터 그룹을 토글할 때마다 서버와 매번 왕복 통신을 하고 싶지는 않을 것입니다. Vue의 컴포넌트 모델, 반응성 시스템, 그리고 생태계는 바로 이런 작업을 위해 만들어졌습니다.
상호작용이 매우 활발한 소비자용 애플리케이션도 마찬가지입니다. 디자인 도구, 협업 화이트보드, 또는 음악 시퀀서를 생각해 보세요. 이것들은 단순히 버튼이 있는 문서가 아닙니다. 브라우저 내에서 살아 움직이는 애플리케이션입니다. 그런 작업에는 여전히 Vue가 저의 첫 번째 선택입니다.
HTMX가 빛을 발하는 곳
가장 확실한 승리는 프로젝트의 지루한 부분들을 살펴볼 때 나타났습니다. 관리자 패널이 가장 먼저 바뀌었습니다. 관리자 백엔드는 보통 레코드 테이블, 몇 개의 액션 버튼, 페이지네이션이 적용된 필터, 그리고 한두 개의 양식만 있으면 됩니다. 이 중 그 어떤 것도 가상 DOM을 필요로 하지 않습니다. 필요한 것은 빠른 부분 업데이트입니다.
HTMX를 사용하면 삭제 버튼은 hx-delete와 hx-target 속성을 가진 태그가 됩니다. 클릭하면 브라우저가 요청을 보내고, 서버는 새로고침된 테이블 행으로 응답합니다