HTMX, 진짜 쓸만한 건지 직접 써봤다

JavaScript 프레임워크 없이 웹을 만든다고?

HTMX를 처음 봤을 때 "이게 진짜 되나?" 싶었다. HTML 속성만으로 AJAX 요청을 보내고, DOM을 업데이트하고, 서버에서 HTML을 받아서 교체한다. React도 Vue도 필요 없다.

솔직히 반신반의하면서 사이드 프로젝트를 하나 만들어봤다. 간단한 할 일 관리 앱. HTMX + Express + EJS 조합으로.

첫인상: 미친 듯이 간단하다

버튼 하나에 hx-post="/todos" hx-target="#todo-list" hx-swap="beforeend" 이 세 줄을 넣으면 클릭 시 서버에 POST 요청을 보내고, 응답으로 받은 HTML을 #todo-list에 추가한다. 끝이다.

React로 이걸 하려면 state 관리, 이벤트 핸들러, fetch 호출, 응답 처리, 리렌더링... 코드가 최소 30줄이다. HTMX는 HTML 속성 3개로 같은 결과를 낸다.

빌드 스텝이 없다는 것도 좋았다. webpack도 없고 번들링도 없다. CDN에서 HTMX 스크립트 하나 로드하면 끝이다. 개발 서버 실행하고 바로 코딩.

여기서부터 현실이 보이기 시작했다

간단한 CRUD는 정말 빠르게 만들 수 있었다. 근데 조금만 복잡해지면 한계가 보인다.

검색 필터 3개를 동시에 적용해야 하는 화면에서 막혔다. 카테고리, 날짜 범위, 키워드 세 가지 필터가 있는데, 하나를 바꾸면 다른 필터 상태도 유지하면서 결과를 갱신해야 한다. React에서는 state로 관리하면 되는데, HTMX에서는 URL 파라미터로 전부 넘겨야 해서 코드가 지저분해졌다.

(이때 "아, React가 왜 필요한지 알겠다"라는 생각이 들었다.)

서버 부하 이야기

HTMX의 원리가 서버에서 HTML을 만들어서 보내는 거다. React는 초기 로드 이후 클라이언트에서 렌더링하니까 서버 부하가 적은데, HTMX는 매 요청마다 서버에서 HTML을 생성한다.

사이드 프로젝트 수준에서는 문제없었다. 근데 동시 사용자가 많은 서비스라면 서버 비용이 올라갈 수 있다. 이건 SSR과 같은 트레이드오프다.

HTMX가 빛나는 곳

관리자 페이지, 내부 도구, MVP 프로토타입. 복잡한 상태 관리가 필요 없고, CRUD 위주이고, 빠르게 만들어야 할 때. 이런 경우에는 React 세팅하는 시간에 HTMX로 기능을 다 만들 수 있다.

기존 서버 렌더링 앱(Django, Rails, Spring)에 인터랙티브 요소를 추가할 때도 좋다. 프론트엔드를 분리하지 않고 기존 아키텍처에 HTMX를 얹으면 된다.

결론은

HTMX는 하이프가 아니라 실용적인 도구다. 근데 React를 대체하는 게 아니라, React가 과한 상황에서 쓰는 대안이다. 복잡한 SPA를 HTMX로 만들겠다는 건 삽을 갖고 포클레인 할 일을 하겠다는 거다.

써보길 잘했다고 생각한다. 다음에 간단한 내부 도구를 만들 일이 있으면 HTMX를 쓸 거다. 근데 메인 프로덕트를 HTMX로 만들 생각은 없다. 아마도.