htmx 4.0 출시, fetch 전환과 명시적 속성 상속으로 2.x 업그레이드 경로 제시

이미지가 Omarchy Quattro와 같은 것 같은데 우연인가 했음. 만든 쪽에서 트위터에서 만든 이미지였고 Omarchy 출처인 줄 몰랐다며 바로 내렸다고 함.

Go, htmx, SQLite로 실험을 시작하면 단순하면서도 반응성 있는 앱을 빨리 만들기 좋더라. 이 조합을 HUGS 스택이라고 부르는 사람도 있음.

나는 Django와 Postgres가 htmx에 더 잘 맞는다고 보지만, Go 스택도 개발 속도가 크게 밀리지 않고 더 빠름. AI가 htmx와 템플릿용 JS를 꽤 잘 작성해서 프로덕션 앱도 만들 만하다고 봄.

프로토타입을 빨리 만들 목적이면 LLM을 쓰게 될 텐데, 그럼 왜 더 단순한 프레임워크부터 시작하는지 궁금함.

버전 3을 건너뛴 건 농담임. 2가 나왔을 때 3은 절대 없다고 했는데 호환성 깨지는 변경이 필요해지자 4로 가야 약속을 지킬 수 있었던 셈임.

htmx를 100년짜리 웹 서비스의 토대로 삼는다는 말에는 회의적임. 그래도 정적 HTML 외에 더 나은 장기 해법을 바로 떠올리긴 어렵고, 목표 자체는 괜찮다고 봄.

100년 뒤 구조까지 따지는 건 쓸데없는 설계 논쟁 같음. 지금 유용하면 나중에 고치면 되고, GitHub처럼 초기에 잘못 고른 구조가 오래 발목을 잡는 사례도 있긴 함.

LLM이 JavaScript를 쉽게 만들어주니, 예전처럼 JS를 직접 쓰기 싫어서 htmx를 택할 이유는 약해진 느낌임. AlpineJS와 섞다가 결국 순수 JS로 갔고 지금은 htmx 없이도 잘 지냄.

브라우저는 원래 서버 렌더링 HTML을 다루도록 만들어졌음.

LLM이 htmx 같은 작은 웹 라이브러리 채택을 줄일 거라는 예상은 이해함. 그래도 BSD 0 라이선스 프로젝트고, 아이디어를 좋아하는 사람이 쓰면 된다고 봄.

htmx는 JS를 피하려는 도구라기보다 서버가 보내는 문서를 다루는 앱 구조를 택하는 도구임. LLM이 JS를 빨리 써준다는 사실은 두 접근 중 어느 쪽을 택할지와는 별개라고 봄.

LLM이 기본적으로 만드는 JS는 테스트하기 어려운 뒤엉킨 코드가 되기 쉬움. TDD와 Playwright 테스트를 붙이면 나아지지만, htmx도 DOM 중심이라 상태 동기화나 테스트 측면에서 만능은 아니더라.

LLM이 JS를 대신 써준다는 건 유지보수하기 어려운 JS를 대신 생성한다는 뜻일 때가 많음.

Angular와 달리 htmx는 서버 렌더링 HTML 위에 얹어서, 독립형 SPA를 만들지 않고도 SPA에 가까운 상호작용을 주려는 층임. 복잡도 면에서는 Angular와 정반대에 가깝다고 봄.