htmx 2.0은 영구적으로 지원될 예정이라, 업그레이드 압박이 전혀 없다고 함
요즘처럼 API 변경이 잦은 시대에 이런 접근은 칭찬할 만함
안정성을 추구하는 사람들이 종종 잘못된 교훈을 얻는다고 느낌
Python 3.0처럼 한 번에 큰 변화를 몰아넣기보다, 점진적 릴리스 전략이 낫다고 주장함
예를 들어 2.1, 4.0, 5.0 등으로 나누어 변경을 도입하면 관리가 훨씬 쉬움
Django처럼 여러 버전에 걸쳐 호환 단계를 유지하는 방식을 추천함
hx-target 속성의 설명이 헷갈린다고 느낌
“inherited”보다는 “inheritable” 혹은 “inherit”이 더 자연스러워 보임
자신은 “자식이 상속받는다”는 의미로 읽었다며, “pass-down” 같은 표현이 더 명확할 수도 있다고 제안함
“inherited”는 잘못된 단어라며 “inherit”이 짧고 좋다고 함
농담으로 “bequeath”도 가능하다고 덧붙임
여러 표현을 고민 중이라며 의견을 수용할 의향이 있다고 함
“heritable”이나 “cascade” 같은 대안도 제시됨
HTMX의 아이디어와 Hypermedia 철학은 멋지다고 생각함
SPA 환경에서 벗어나 Datastar를 선택했는데, 학습 투자 대비 확장성이 더 크다고 느낌
서버에서 브라우저로 신호를 직접 푸시하면서 폴링 코드를 제거했고, 복잡도가 크게 줄었음
Alpine.js 의존성도 없애서 코드가 단순해졌고, 스트리밍 기반 전체 뷰 갱신도 압축 덕분에 효율적으로 작동함
SPA에서 왔다면 Datastar와 HTMX 둘 다 시도해보길 권함
fetch()로 전환해 Readable Stream을 활용하는 부분이 흥미로움
HTMX를 많이 써봤지만, Datastar의 SSE 기반 스트리밍이 더 매력적이라 요즘은 그쪽을 선호함
HTMX의 발전이 반갑다고 하면서도, Datastar가 더 표준 친화적이고 유연한 API를 제공한다고 느낌
작은 패키지에 Fetch, SSE, declarative signals, DOM morphing 등 다양한 기능이 들어있다고 함
그래서 “왜 HTMX를 써야 하지?”라는 의문을 던짐
Datastar Pro는 오픈소스가 아니기 때문에 신뢰성 리스크가 있다고 지적함
Datastar 제작자가 예전에 HTMX에 이런 기능을 넣으려 했다는 아이러니를 언급함
HTMX는 요청/응답 패러다임에 최적화된 단순한 인터페이스가 강점이라고 설명함
Datastar는 이벤트 스트림 중심이라 실시간 대시보드나 게임에는 적합하지만, 대부분의 웹앱은 HTMX의 단순함이 더 유리함
관련 참고: Datastar 에세이, Less HTMX is More
HTMX는 브라우저의 URL 히스토리 관리를 쉽게 지원하지만, Datastar는 이 기능을 유료(Pro)로 제한했다고 함
“완벽해서 더 이상 메이저 버전이 없다”던 말에서 결국 진화의 필요성을 인정한 점을 꼬집음
“이제 이벤트 네이밍 표준을 바꾼다”는 부분을 인용하며, 자바스크립트를 피하려는 시도로 풍자함
“결국 자바스크립트를 안 쓰려다 커스텀 문법을 JS로 해석하게 됐다”며 비꼼
그래도 HTML로 의도를 표현할 수 있다는 점은 인정함
“이번이 진짜 마지막 버전일 것”이라는 농담을 던짐
“그래도 자바스크립트 직접 쓰는 것보단 낫다”고 긍정적으로 받아들임
“저자의 생각이 바뀐 게 뭐가 문제냐”며 비판적인 어조를 지적함
글이 매우 명확하고 API 설계 철학을 잘 배울 수 있었다고 함
fetch와 HTMX를 함께 쓰기 위해 xhr-fetch-proxy를 만들었는데,
이번 변경으로 더 많은 가능성이 열릴 것 같다고 함 프로젝트 링크
4.0에서는 요청 사이클이 완전히 열려 있어서, 요청마다 fetch 구현을 교체할 수 있다고 함
이 아이디어는 fixi.js에서 배웠다고 덧붙임
Hacker News 의견
결국 마음을 바꿔서 htmx의 새로운 메이저 버전을 내기로 했음
단, “3.0은 없을 것”이라는 약속을 지키기 위해 다음 버전은 htmx 4.0으로 명명함
기술적으로는 맞는 표현이라며 농담 섞인 반응을 보임
차라리 솔직히 3.0으로 내는 게 낫지 않았을까 생각함
htmx 2.0은 영구적으로 지원될 예정이라, 업그레이드 압박이 전혀 없다고 함
요즘처럼 API 변경이 잦은 시대에 이런 접근은 칭찬할 만함
안정성을 추구하는 사람들이 종종 잘못된 교훈을 얻는다고 느낌
Python 3.0처럼 한 번에 큰 변화를 몰아넣기보다, 점진적 릴리스 전략이 낫다고 주장함
예를 들어 2.1, 4.0, 5.0 등으로 나누어 변경을 도입하면 관리가 훨씬 쉬움
Django처럼 여러 버전에 걸쳐 호환 단계를 유지하는 방식을 추천함
hx-target속성의 설명이 헷갈린다고 느낌“inherited”보다는 “inheritable” 혹은 “inherit”이 더 자연스러워 보임
농담으로 “bequeath”도 가능하다고 덧붙임
HTMX의 아이디어와 Hypermedia 철학은 멋지다고 생각함
SPA 환경에서 벗어나 Datastar를 선택했는데, 학습 투자 대비 확장성이 더 크다고 느낌
서버에서 브라우저로 신호를 직접 푸시하면서 폴링 코드를 제거했고, 복잡도가 크게 줄었음
Alpine.js 의존성도 없애서 코드가 단순해졌고, 스트리밍 기반 전체 뷰 갱신도 압축 덕분에 효율적으로 작동함
SPA에서 왔다면 Datastar와 HTMX 둘 다 시도해보길 권함
fetch()로 전환해 Readable Stream을 활용하는 부분이 흥미로움HTMX를 많이 써봤지만, Datastar의 SSE 기반 스트리밍이 더 매력적이라 요즘은 그쪽을 선호함
HTMX의 발전이 반갑다고 하면서도, Datastar가 더 표준 친화적이고 유연한 API를 제공한다고 느낌
작은 패키지에 Fetch, SSE, declarative signals, DOM morphing 등 다양한 기능이 들어있다고 함
그래서 “왜 HTMX를 써야 하지?”라는 의문을 던짐
Datastar는 이벤트 스트림 중심이라 실시간 대시보드나 게임에는 적합하지만, 대부분의 웹앱은 HTMX의 단순함이 더 유리함
관련 참고: Datastar 에세이, Less HTMX is More
“완벽해서 더 이상 메이저 버전이 없다”던 말에서 결국 진화의 필요성을 인정한 점을 꼬집음
“이제 이벤트 네이밍 표준을 바꾼다”는 부분을 인용하며, 자바스크립트를 피하려는 시도로 풍자함
그래도 HTML로 의도를 표현할 수 있다는 점은 인정함
글이 매우 명확하고 API 설계 철학을 잘 배울 수 있었다고 함
fetch와 HTMX를 함께 쓰기 위해 xhr-fetch-proxy를 만들었는데,이번 변경으로 더 많은 가능성이 열릴 것 같다고 함
프로젝트 링크
이 아이디어는 fixi.js에서 배웠다고 덧붙임