HTMX를 React와 비교하려는 이유가 뭐냐

참고로 내 첫 웹 개발 환경은 지랄맞는 IE 5.5 였다. 넷스케이프 호환은 덤(하지만 정작 쓰지도 않았다).

길게 말하기도 귀찮다. 벨로그 가나 어느 개발자 블로그 가도 htmx 소개하는 것까지는 좋은데 react와 비교하는 짓거리들 더이상 못봐주겠다.

대체 무슨 목적으로 비교하는지 눈에 다 보인다.
사실 jQuery 초창기부터 사이트 개발해온 프론트엔드라면 react와 비교하는 것 자체가 어색하다면 정상이다.
근데, 해외에서도 react 와 비교하는 글들을 쉽게 볼 수 있었다. 이정도면 내게는 뇌절 그 자체다.

그럼 왜 내가 이렇게 비교하는 것을 거부하는지, 왜 비교하게 됐는지 간단하게 서술하도록 하겠다.
어금니 꽉 깨물도록. 특히 리액트로 실무 개발하는 너 말야.

가깝고도 먼 프론트엔드

애초에 리액트는 풍부한 웹 어플리케이션을 만들기 위한 일종의 기술이다. 비록 웹 컴포넌트 표준을 따르지는 않지만(조만간 호환은 되네), 웹 컴포넌트에서 마크업보다는 자바스크립트에 집중할 수 있는 효과 때문에 많은 프론트엔드 개발자들이 선택한 기술이기도 하다. 자바스크립트를 최대한 활용하기 때문에 나는 "자바스크립트의 정점" 으로 평가할 수 있겠다.
근데... RIA 라고 하면 너나 나나 어자피 발작 일으킬 거 알잖아. 마이플랫폼 엑스플... 됐다 관두자.

그에 반해 htmx 의 소개문을 공식 사이트에서 발췌해 보자.

htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext

htmx 는 속성을 활용하여 직접 HTML을 통한 Ajax, CSS 변화, 웹소켓, SSE 등을 접근할 수 있게 해준다. 그래서 당신의 풍부한 문서에서 제공하는 인터페이스의 상호 작용을 더 쉽게 제작할 수 있다.

즉, React 는 자바스크립트에 치중한 반면, htmx 는 HTML에 치중한, 누가 봐도 극명한 차이를 보여주는 웹 기반 기술이라고 볼 수 있겠다.

상태관리

애초에 htmx 는 상태관리가 없다. 주 기능이 바로 HTML 만으로도 서버를 통해 동적 문서를 만드는 기능에 집중했기 때문이다.
물론 불가능한 것은 아니지만, htmx 을 사용하는 주요 타겟층을 좀 생각해 보도록 하자 프론트엔드 개발자들아.

htmx 개발진 또한 서버 개발자들을 대상으로 손쉽게 서버로부터 컨텐츠를 가져와 쉽게 동적 문서를 만들어 내는데에 목적이 있다고 말했다.
특히 자바스크립트와 거리가 먼 Python, Ruby, Rust 등... 심지어 타입없는 자바스크립트를 싫어하는 강타입 객체지향 덕후 자바 말이다.

React 는 상태관리를 지원한다. 지원... 한다... 근데... 왜 몇몇 리액트 개발자들이 클래스 컴포넌트 시절을 그리워하는지 새삼 이해도 간다... 그에 반해 Vue는 옵션 API 잘 안 쓰게 된다.

힙한 기술이 불러낸 참극?

하지만, 이렇게 자꾸 신규 프론트엔드 기술이 나올때마다 react 와 비교하는 건 알고보니 어제오늘 일이 아니었다.
JSX 기반의 프론트엔드 대안 기술(Preact, Solid, Qwik...)이 나올 때마다 React 와 비교하는 건 흔한 일이지.
Lit 도, Alpine.js 또한 react 비교는 피할 수 없었고 말이지.

근데 미국에서 이젠 하다하다 React 를 틀딱기술로 부르기 시작했다. 마치 Java처럼.
그러다가 최근에 들어서 띄우는 게 바로 htmx다. 이게 무슨 참극이란 말인가...

물론 실무에서는 씨알도 안먹히는 개소리에 불과하지만, 이게 해커뉴스까지 가서 병림픽까지 벌인 재밌는 광경도 봤다.
하지만 점점 비교의 성숙도가 올라가기 시작했는데, 결국 React의 맹점을 건드려서 최근 프론트엔드 기술을 띄우고 있다.
그게 바로 뭐냐,

모든것의 원흉은 상태관리

React 16부터 함수 컴포넌트가 제시되어 상태관리 시스템이 바뀌어 많은 혼란이 있었고, 지금은 조용해 졌지만...
리액트가 항상 답은 아니었고, 항상 만능은 아니었다.
상태관리의 오남용은 웹 어플리케이션 품질이 더러워졌고, 그지같은 사용자 경험을 만들어낸다. 브라우저가 뻗는 건 덤.
그래서 상태관리를 사용할 때 주의해야 할 점이 많이 공유된 상태다. 구더기 무서워서 장 못 담그듯 메모이제이션을 남용하는 경우도 흔하다.

예전에도 리액트 상태관리를 쓰다보니 그지같고 최적화도 어렵고 참 어쨌든 그지같아서 시그날 방식에 대한 기대감에 한껏 부풀었고,
이젠 커뮤니티 프로젝트인 million 으로 React 컴포넌트 최적화 방안을 꾀한 적도 있었다.

그러다가 뭔가 대안을 찾다가 나온 게 이 뜬금없는 htmx가 주목받고 있는 것이다...
아...

서버 컴포넌트, 얄미운 Vercel

그것 뿐만 아니다. 예전에 설명했듯 <Suspense/> 컴포넌트의 통수까지 겹쳐저 React 로 SPA 만들던 개발자들이 이제 더 이상 React의 회의감을 비치는 개발자들 또한 늘어났다. 특히 그렇게 만든 원흉은 Vercel은 SPA의 주적이 되었고 말이지.
React 19가 나와 서버 기능이 강력하다 한들, 우린 18 쓰든가 딴거 쓰든가 하겠다는 취지다.

하지만, 서버 컴포넌트... 결국 쓰게 될 거다.

어쨌든 결론

사정이 이러한 것은 알겠지만, 더 이상 아무리 같은 프론트엔드하고 목적도, 목표도 완전히 다른 htmx 와 react 와의 비교는

그만했으면 좋겠다. 원론적으로 가면 결국 현타 오게 되어 있다. 왜냐면 htmx 기능은 서버와의 상호 작용이 끝이거든.

사실 Python 생태계는 이런 프론트엔드 이슈에 관심도 없을 텐데, Streamlit 이라든가 Reflex 라든가 해서 HTML 문서에 상호작용까지 죄다 파이썬으로 끌어들이는 세삼 무서운 생태계를 보여주고 있으니 말이지.

다 적재적소에 프론트엔드 쓰게 되어 있다. 잘라빠진 단순 홈페이지를 React로 만드는 미친놈이 있는가? 있는게 이상하다.

오히려, 순수 HTML, CSS, JS로 만들어 봐라. 가장 빠르고, 가장 정확하며, 가장 모던하고, 가장 경제적인 데다가, 가장 힙하다.

결론은 위 링크다. 위 링크 꼭 봐라. 두번 봐라. 프론트엔드 개발자라면 특히 말이다.
내가 이거 소개하려고 뻘글 썼나 싶네.

끗.