HTMX에서 Datastar로 전환한 이유

(everydaysuperpowers.dev)

10P by GN⁺ 9달전 | ★ favorite | 댓글 2개

HTMX 사용 시 코드량을 약 70% 줄일 수 있었으나, UI 간 동기화 이슈와 더불어 프론트엔드 상태 관리의 복잡성 증가를 경험
Datastar 도입 후, 실시간 멀티유저 애플리케이션 개발 시 WebSockets 없이 간결한 코드 구성 및 유지보수가 용이해짐
HTMX가 HTML 속성을 중심으로 동작 로직을 분산시키는 반면, Datastar는 서버 주도적 업데이트 모델을 통해 로직의 일관성과 유지보수성을 높임
Datastar API는 속성이 적고 코드의 가독성 및 생산성이 증가함을 느낌
Datastar는 Server-Sent Events(SSE), Web Components, CSS View Transitions 등 웹 네이티브 기술을 적극 활용하여 실시간 협업과 재사용 가능한 컴포넌트 구조를 가능하게 함

소개 및 동기

2022년에 David Guillot가 DjangoCon Europe에서 React 기반 SaaS를 HTMX로 전환하면서 코드량을 약 70% 줄이고 기능 개선을 이룬 사례를 공유했었음
그 후에 다수의 팀들이 단일 페이지 앱(SPA)에서 멀티페이지 하이퍼미디어 앱으로 전환 시 코드 절감 및 개발∙사용자 경험 모두 향상됨을 경험함
필자 역시 HTMX에서 Datastar로 프로젝트를 전환하면서 코드가 더 짧아지고 WebSocket이나 복잡한 상태 관리 없이 실시간 멀티유저 앱 개발이 가능함을 확인

전환의 계기가 된 문제점

FlaskCon 2025 발표를 준비하던 중 HTMX와 AlpineJS를 조합하여 UI를 동기화하려 했으나, UI 동기화 문제에 직면
- 두 라이브러리는 서로 다른 개발자가 만든 별도 도구로 상호 통신이 불가능하여, 개발자가 직접 통합 작업을 담당해야 함
- 다양한 시점에 컴포넌트를 초기화하고 이벤트를 조율하는 과정에서 예상보다 많은 코드 작성과 디버깅 시간 소요
Datastar가 두 라이브러리의 기능을 통합하면서도 11KB 미만의 크기로 제공한다는 점에 주목하여 시도해 봄
- 모바일 기기 사용자의 페이지 로드 성능 개선에 유리

더 나은 Datastar의 API 설계

Datastar의 API가 HTMX보다 훨씬 가벼운 느낌을 주며, 원하는 결과를 얻기 위해 추가해야 하는 속성(attribute) 수가 적음
HTMX는 대부분의 상호작용에서 여러 속성 필요
- URL 정의, 타겟 요소 지정, 응답 처리 방식 등을 각각 별도 속성으로 설정
- 일반적으로 2~3개의 속성을 매번 사용하며, 때로는 상속 체인을 따라 올라가며 속성 동작 방식을 확인해야 함
```
<a hx-target="#rebuild-bundle-status-button"  
   hx-select="#rebuild-bundle-status-button"  
   hx-swap="outerHTML"  
   hx-trigger="click"  
   hx-get="/rebuild/status-button"></a>  
```
Datastar는 일반적으로 단 하나의 속성으로 동일한 기능 구현
```
<a data-on-click="@get('/rebuild/status-button')"></a>  
```
- 몇 개월 후 코드를 다시 봐도 동작 방식을 쉽게 이해 가능

동작 원리의 차이

HTMX는 프론트엔드 라이브러리로 HTML 스펙을 확장하는 것을 목표로 하는 반면, Datastar는 서버 주도 라이브러리로 고성능 웹 네이티브 실시간 업데이트 애플리케이션 구축을 목표로 함
HTMX는 요청을 트리거하는 요소에 속성을 추가하여 동작을 정의하며, 페이지의 멀리 떨어진 요소를 업데이트하더라도 로직이 여러 레이어에 분산됨
Datastar는 서버가 무엇을 변경할지 결정하여 모든 업데이트 로직을 한 곳에 집중
HTMX 예제
```
<div>  
  <div id="alert"></div>  
    <button hx-get="/info"   
            hx-select="#info-details"   
            hx-swap="outerHTML"  
            hx-select-oob="#alert">  
        Get Info!  
    </button>  
</div>  
```
- 버튼을 누르면 /info로 GET 요청을 보내고, 응답의 'info-details' ID 요소로 버튼을 교체하며, 응답의 'alert' ID 요소로 페이지의 동일 ID 요소를 교체
- 버튼 요소가 알아야 할 정보가 너무 많으며, 서버에서 반환할 정보를 미리 알아야 하므로 HTMX의 "행동의 지역성(locality of behavior)" 원칙이 약화됨

Datastar의 개선된 접근

<div>  
    <div id="alert"></div>  
    <button id="info-details"  
    data-on-click="@get('/info')">  
        Get Info!  
    </button>  
</div>

서버가 동일한 ID를 가진 두 개의 루트 요소를 포함한 HTML 문자열 반환

<p id="info-details">These are the details you are looking for…</p>  
<div id="alert">Alert! This is a test.</div>

간단하고 성능이 우수한 옵션

컴포넌트 레벨에서 사고하기

더 나은 접근 방식은 HTML을 컴포넌트로 취급하는 것
해당 컴포넌트의 본질 파악
- 사용자가 특정 항목에 대한 추가 정보를 얻는 방법
- 사용자가 버튼을 클릭하면 정보가 나타나거나 정보가 없어 오류가 렌더링되며, 어느 쪽이든 컴포넌트는 정적 상태가 됨

상태별 컴포넌트 분리

플레이스홀더 상태:

<!-- info-component-placeholder.html -->  
<div id="info-component">  
    <button data-on-click="@get('/product/{{product.id}}/info')">  
        Get Info!  
    </button>  
</div>

정보 표시 상태:

<!-- info-component-get.html -->  
<div id="info-component">  
    {% if alert %}<div id="alert">{{ alert }}</div>{% endif %}  
    <p>{{product.additional_information}}</p>  
</div>

서버가 HTML을 렌더링하면 Datastar가 페이지를 자동으로 업데이트
컴포넌트 레벨 사고는 잘못된 상태에 진입하거나 사용자 상태를 잃어버리는 것을 방지

여러 컴포넌트 동시 업데이트

David Guillot의 발표에서 인상적이었던 점은 앱이 선호 항목 수를 업데이트할 때, 변경된 컴포넌트와 매우 멀리 떨어진 카운트 요소도 함께 업데이트되었다는 것
- HTMX는 JavaScript 이벤트를 트리거하고, 이것이 다시 원격 컴포넌트에 GET 요청을 발행하도록 트리거
Datastar는 동기 함수 내에서도 여러 컴포넌트를 동시에 업데이트 가능

쇼핑 카트 예

장바구니 추가 컴포넌트:

<form id="purchase-item"  
      data-on-submit="@post('/add-item', {contentType: 'form'})">"  
>  
  <input type=hidden name="cart-id" value="{{cart.id}}">  
  <input type=hidden name="item-id" value="{{item.id}}">  
  <fieldset>  
    <button data-on-click="$quantity -= 1">-</button>  
    <label>Quantity  
      <input name=quantity type=number data-bind-quantity value=1>  
    </label>  
    <button data-on-click="$quantity += 1">+</button>  
  </fieldset>  
  <button type=submit>Add to cart</button>  
  {% if msg %}  
    <p class=message>{{msg}}</p>  
  {% endif %}  
</form>

장바구니 카운트 표시 컴포넌트:

<div id="cart-count">  
    <svg viewBox="0 0 10 10" xmlns="http://www.w3.org/2000/svg">;  
        <use href="#shoppingCart">  
    </svg>  
    {{count}}  
</div>

Django에서 두 컴포넌트를 동일한 요청으로 업데이트:

from datastar_py.consts import ElementPatchMode  
from datastar_py.django import (  
    DatastarResponse,  
    ServerSentEventGenerator as SSE,  
)  

def add_item(request):  
    # 중요한 상태 업데이트 생략  
    return DatastarResponse([  
        SSE.patch_elements(  
            render_to_string('purchase-item.html', context=dict(cart=cart, item=item, msg='Item added!'))  
        ),  
        SSE.patch_elements(  
            render_to_string('cart-count.html', context=dict(count=item_count))  
        ),  
    ])

웹 네이티브 철학

Datastar Discord 커뮤니티를 통해 Datastar가 단순한 헬퍼 스크립트가 아니라 웹의 기본 프리미티브를 활용한 앱 구축 철학임을 이해
HTMX가 HTML 스펙을 발전시키려는 반면, Datastar는 웹 네이티브 기능의 채택을 촉진하는 데 더 관심
- CSS view transitions
- Server-Sent Events
- 웹 컴포넌트 등
복잡한 AlpineJS 컴포넌트를 리팩토링하여 간단한 웹 컴포넌트를 추출하고 여러 곳에서 재사용하는 큰 성과 달성
React 같은 도구 없이도 커스텀 HTML 요소 생성으로 높은 행동 지역성과 재사용성을 달성할 수 있는 훌륭한 패턴

다중 사용자 앱을 위한 실시간 업데이트

협업을 일급 기능으로 갖춘 앱은 다른 앱과 차별화되며, Datastar는 이 과제를 해결
대부분의 HTMX 개발자는 폴링 방식으로 서버에서 정보를 가져오거나 커스텀 WebSocket 코드를 작성하여 복잡도를 증가시킴
Datastar는 Server-Sent Events(SSE) 라는 간단한 웹 기술을 사용하여 서버가 연결된 클라이언트에 업데이트를 "푸시"
- 사용자가 댓글을 추가하거나 상태가 변경되면 서버가 즉시 브라우저를 업데이트하며, 추가 코드가 최소화됨
- 커스텀 JavaScript 없이도 실시간 대시보드, 관리 패널, 협업 도구 구축 가능
클라이언트 연결이 중단되면 브라우저가 자동으로 재연결 시도하며, 추가 코드 불필요
- 서버에 "마지막으로 받은 이벤트"를 알릴 수도 있음

과도한 복잡성 피하기

Datastar Discord 커뮤니티는 웹 앱 제작에 대한 Datastar의 비전을 이해하는 데 도움
- 푸시 기반 UI 업데이트
- 복잡성 감소
- 웹 컴포넌트 같은 도구를 활용한 로컬 복잡한 상황 처리
커뮤니티는 신규 사용자가 과도하게 복잡하게 접근하고 있음을 깨닫도록 도움

주요 팁

전체 컴포넌트를 다시 렌더링하여 전송하는 것을 두려워하지 말 것
- 더 쉬우며 성능에 큰 영향을 주지 않음
- 더 나은 압축률을 얻을 수 있고, 브라우저가 HTML 문자열을 파싱하는 속도가 매우 빠름
서버가 진실의 상태이며 브라우저보다 강력함
- 대부분의 상태를 서버가 처리하도록 하고, 생각보다 반응형 시그널이 필요하지 않을 수 있음
웹 컴포넌트는 높은 행동 지역성을 가진 커스텀 요소에 로직을 캡슐화하는 데 탁월
- Datastar 웹사이트 헤더의 별 필드 애니메이션이 좋은 예시
- <ds-starfield> 요소가 별 필드 애니메이션의 모든 코드를 캡슐화하고 내부 상태를 변경할 세 가지 속성을 노출
- Datastar가 범위 입력이 변경되거나 마우스가 요소 위를 움직일 때 속성을 구동

한계를 뛰어넘는 가능성

Datastar가 가능하게 하는 잠재력이 가장 흥미로움
커뮤니티는 다른 도구를 사용하는 개발자가 경험하는 한계를 훨씬 뛰어넘는 프로젝트를 정기적으로 생성

주목할 만한 사례

예시 페이지의 데이터베이스 모니터링 데모
- Hypermedia를 활용하여 JavaScript 컨퍼런스에서 발표된 데모의 속도와 메모리 사용량을 크게 개선
Anders Murphy의 10억 개 체크박스
- 100만 개 체크박스 실험이 서버 용량을 초과하자, Datastar를 사용하여 저렴한 서버에서 10억 개 구현
미국의 모든 레이더 스테이션 데이터를 표시하는 웹 앱
- 레이더의 신호가 변경되면 UI의 해당 점이 100밀리초 이내에 변경
- 초당 80만 개 이상의 포인트가 업데이트되며, 사용자는 최대 1시간 전으로 스크럽 가능(700밀리초 미만의 지연)
- Hypermedia 앱으로서 이것이 가능하다는 것이 Datastar가 가능하게 하는 것

현재 사용 경험

여전히 Datastar의 탐색 단계에 있으며, 표준 HTMX 기능의 UI 업데이트 AJAX 처리를 빠르고 쉽게 구현
Datastar를 사용하여 더 많은 것을 달성하기 위한 다양한 패턴을 학습하고 실험 중
수십 년 동안 실시간 업데이트로 더 나은 사용자 경험을 제공하는 방법에 관심이 있었으며, Datastar가 동기 코드에서도 푸시 기반 업데이트를 가능하게 하는 것이 좋음
HTMX를 사용하기 시작했을 때 큰 기쁨을 느꼈지만, Datastar로 전환한 이후 잃은 것이 없다고 느끼며, 오히려 훨씬 더 많은 것을 얻었다고 느낌
HTMX를 사용하면서 기쁨을 느꼈다면, Datastar에서도 동일한 도약을 다시 느낄 것이며, 이는 웹이 원래 해야 할 일을 발견하는 것과 같음

GeekNews Weekly에 포함된 글입니다. 에디터 코멘트 보기

xguru 9달전 [-]

Datastar - 인터랙티브 웹 앱 구축을 위한 경량 하이퍼미디어 프레임워크

답변달기

GN⁺ 9달전 [-]

Hacker News 의견

Chris가 자신의 안전 영역을 벗어나 도전하고, 그 경험을 우리와 나누는 부분에 대해 감사함을 느낌. 나는 htmx로 4년째 웹앱을 만들어온 입장이기에 약간 편향이 있을 수 있지만, Datastar와 htmx의 주요 아키텍처 차이점이 드러난다고 생각함: htmx는 HTML 주도, Datastar는 서버 주도 방식임. 클라이언트 쪽 API가 단순한 것이 사실이지만, 이는 서버 측 로직이 더 복잡해지기 때문임. 예를 들어, HTML 요소가 서버에서 반환된 fragment를 어디에 넣을지 정보가 없다면, 그 정보를 서버 쪽에 기록해야 하므로 어느 한 쪽의 복잡성이 반드시 존재함. 아키텍처 선택은 취향 문제 같음. 예시에서 ‘less attributes’(속성 줄이기) 논리는 htmx에서 선택적으로 달 수 있는 속성까지 예시로 든 것이라 100% 공정하다고 보긴 어려움; 예를 들어 hx-trigger="click"을 빼면 20% 속성이 줄어듦. 그리고 <span> 대신 <button>을 사용하는 등 더 접근성 높게 HTML을 짜면 신뢰도가 높아질 것 같음. 결국 Datastar의 강점은 Alpine이나 Stimulus의 기능이 내장된 상태로 나온 것 같다는 점이라, 이게 정말 인상 깊음
- Datastar를 쓰면 페이지 다른 부분을 실시간으로 갱신하기 위해 이벤트 기능(eventing)을 따로 구현할 필요 없이 한 번에 전부 내려받아 갱신할 수 있다는 점에서 복잡도가 훨씬 줄어들지 않나 생각함. 물론, 상황에 따라선 이벤트 기반 방식이나, 나중에 불러오는 것이 더 나을 수도 있다고 봄
- “Alpine이나 Stimulus 기능이 HTMX에 기본 내장된 셈”이라는 의견을 보고 HTMX로 개인 프로젝트를 할까 고민 중임. 꼭 AlpineJS나 Stimulus 같은 추가 라이브러리도 필요하다고 설명해주는 자료가 있는지 궁금함
- 만약 HTML 요소에 어느 위치에 fragment를 삽입할지 정보가 없다면 서버가 알아야 한다는 논의가 있었는데, 프론트엔드는 이럴 때 더 가볍고 빠르지 않을까 생각도 해 봄. 특히 수많은 요소가 있다면 더욱 그렇지 않겠음?
- 이 구조가 Pharo의 Seaside 프레임워크와 좀 닮았음. 우리 회사에서 Pharo로 B2B 앱을 만들 때 UI 상태를 백엔드에서 관리하다 보니 프론트-백엔드 간 오가는 일이 많았음. 실시간·지연이 중요하지 않은 B2B라면 괜찮은데, 확장성 높은 B2C 앱에선 맞지 않음
Datastar와 HTMX를 직접 써 본 입장에서, Datastar로 앱을 짤 때 어떤 큰 차이가 있을지 아직 잘 모르겠음. FastAPI, HTMX, Alpine.js, 그리고 SSE를 함께 써서 로그 실시간 표시, 배포 상태 갱신 같은 일을 하고 있음. Datastar 예시를 봤을 때 이 구조보다 더 간편한 부분이 잘 안 보임. (코드 참고: devpush SSE partial). Web Components도 예전에 Basecoat 개발할 때 시도해 봤지만, 스타일 문제와 상태 관리 등 다양한 이유로 결국 전통적인 HTML/CSS/JS로 돌아옴. devpu.sh, basecoatui.com
- HTMX에서도 Datastar처럼 기능적 확장성을 고려할 때, 그냥 리스트 전체를 통째로 갱신하는 게 더 간단해지는 경우가 많음. 개별 배포 상태를 갱신하려고 하는 것보다 리스트 전체를 업데이트하면 페이징 같은 엣지 케이스도 걱정할 필요가 없어서 훨씬 단순하고 코드도 가벼워짐
Datastar가 실시간/공동작업/멀티플레이에 불충분하다고 생각하는 분들이라면, PRO 기능 없이도 동작하고 심지어 5달러 VPS에서 HN 메인에 올라온 3가지 데모를 소개하고 싶음. Datastar가 얼마나 잘 만들어진 기술인지 보여줌: Checkboxes, Cells, Game of Life Example. 체크박스와 셀 예제는 뷰(화면) 렌더링이 유동적으로 동작해서 꽤 많이 줌아웃 할 수 있고, 가상 스크롤에 백프레셔 기능도 있음
- 내가 코드 구조를 제대로 이해했다면, 실제로는 datastar에서 권장하는 패치(diff/patch) 방식은 안 쓰고 전체 페이지를 매번 다시 랜더한다는 것 같음. 사실 이런 멘탈 모델이 서버에서 클라이언트 상태를 정교하게 추적하는 예시보다 훨씬 단순해 보여서 오히려 끌림. 일반적인 복잡한 앱도 이런 방식으로 지을 수 있을지 궁금함. 유저가 서로 다른 페이지로 이동할 때 다양한 위젯 상태까지 트래킹해가며 즉각적으로 재랜더하려면 어떤 식으로 해야 하는지 참고할 만한 텍스트가 있으면 알려주면 좋겠음
- 체크박스/셀 예제에서 ‘줌아웃’이 된다고 했는데 구체적으로 어떻게 하는지 궁금함. 그리고 해당 좌표(x=123&y=456 등)로 현재 뷰의 URL이 자동 갱신되는 data-replace-url같은 옵션이 있으면 더 좋았을 것 같음
- PRO 기능 관련 언급을 보고 오픈코어 모델(일부는 오픈소스, 나머진 유료, 299달러 라이선스)이라는 걸 알게 됐음. 나는 패스하고 싶음
최근 이런 글(htmx, datastar, greedy developer)을 읽었는데, Datastar의 좋은 핵심 기능들이 유료(Pro)로 옮겨갔다고 들었음. 오픈 소스든 유료든 재정적으로 프레임워크를 지원하고 싶지만, 이런 선례는 좀 우려됨
- 나도 Datastar를 몇 달 동안 팔로업하면서 1.0.0 릴리스를 기다렸는데, 이제는 기대가 완전히 식어버림. ‘오픈소스지만 실제로는 아닌’ 경우에 번번이 당해서 더 신뢰가 안 생김
- 사실 Datastar를 별로 안 좋아한다고 썼던 입장이었지만, 이번에는 Datastar를 좀 옹호하고 싶어짐. 프레임워크 제작자가 자기 코드를 MIT 라이선스로 무료로 공개한 것이니, 과거에 무료로 공개했던 기능도 여전히 MIT로 쓸 수 있음. 기여하지 않고 사용만 해 온 입장에서 과거 버전에 의존하는 것은 본인 선택임. 이제부터 유료 모델로 바꾸는 건 제품 소유주의 자유이고, 필요하면 그냥 포크(Fork)하면 된다고 생각함
- PRO 라이센스 299달러를 한 번 내고 구매했지만, 아직 PRO 기능을 실제로 쓴 적이 없음. 구글시트 클론을 만들려고 했지만 PRO 없이도 충분히 구현 가능했음. (cells 데모 참고)
- Datastar 쪽이 늘 HTMX 디스코드에서 Datastar가 얼마나 좋은지 계속 홍보하는 걸 넘어 약간 공격적으로 느껴진 적이 있음. reddit에서도 “필요한 기능 다 있으면 베타 forever 써라, 오픈소스는 누구에게도 빚진 게 없다”는 뉘앙스의 코멘트를 남긴 것을 본 적 있음
- Datastar를 쓰면서 떠오른 예전 Meteor.js 사례가 바로 생각났음. (Meteor.js HN 토론)
이 포스트에 나온 예시 코드들이 이해가 잘 가지 않음. 예를 들어 아래와 같은 htmx 예시가 <span hx-target="#rebuild-bundle-status-button" hx-select="#rebuild-bundle-status-button" hx-swap="outerHTML" hx-trigger="click" hx-get="/rebuild/status-button"></span> 이런 datastar 코드로 바뀌는 것 같은데: <span data-on-click="@get('/rebuild/status-button')"></span> 더 나아가, 다른 예시들은 더 혼란스러움. 결국 왜 htmx에서 Datastar로 옮겨가는지 이유를 모르겠음
- 기본적으로 HTMX는 “이 span을 클릭하면 /rebuild/status-button에서 HTML을 받아와서, 반환된 HTML에서 #rebuild-bundle-status-button 요소를 추출 후 기존 요소를 교체”라는 의미임. 반면 Datastar는 “스팬 클릭시 /rebuild/status-button의 명령을 그대로 따름”이 됨. 서버에서 여러 ID가 달린 엘리먼트를 리턴하면 Datastar는 알아서 해당 요소를 전부 인식해서 교체해줌. 즉 target, select, swap을 다 쓰지 않아도 ID만 넣으면 의도대로 동작함
- Datastar의 구조는 백엔드에 논리를 몰아둔 셈임. 예전 전통 HTML처럼 요청하면 HTML 받고 바로 브라우저가 랜더하는 식이지만, Datastar는 PWA처럼 한번 페이지를 불러오고 나면 상호작용이 있을 때마다 백엔드에 요청을 보내고 변경분만 받아서 반영함. 프론트에서 로직 없이 백엔드가 모든 상태를 관리하는 SPA(싱글페이지앱) 반대 구조임. 본질적으로 백엔드/프론트 로직 배분문제가 반복되고 있는데, Datastar는 서버(백엔드)에 논리를 몰아도 동적인 인터페이스는 유지할 수 있게 해줌
- 그런데 왜 span 태그를 클릭용으로 쓰는지 의문임. button이나 링크 태그가 더 적절하지 않겠나 생각임
아이러니하게도 이 글에서 하이퍼미디어가 주제인데 정작 Datastar 공식 사이트 링크가 없음. 여기에 공식 사이트 있음: https://data-star.dev/
HTMX의 큰 장점 중 하나는 클라이언트가 서버에서 반환된 데이터 구조를 몰라도 된다는 점인데, 만약 개별 요소의 ID나 의미까지 클라이언트가 알아야 하면 이 약속이 깨지는 것 같음. 물론 실제로 많은 프로젝트에서 OOB(Out of Band)가 쓰일 정도라, 완벽하게 구조 분리를 하는 것은 현실과 좀 멀기도 하다고 생각함. 두 세계의 장점을 모두 취할 수 있는 방안이 나오면 좋겠음
- 사실상 클라이언트는 아무 것도 몰라도 됨. 클라이언트에서 액션을 실행하면 서버가 페이지 전체 뷰를 내려줄 수 있음. 클라이언트는 즉시 전체를 렌더함. 비디오 게임의 immediate mode 모델과 비슷함
Datastar가 이렇게 서버에서 HTML을 패치해주는 구조가 작용분리(Separation of concerns) 면에서 좋지 않고, 규모가 큰 앱일수록 서버에서 HTML 부분을 계속 주입하는 것은 관리가 매우 번거로울 것 같음
- 그렇다고 JS가 여기저기서 fragment로 HTML을 주입하게 하면 더 나은 것은 아니겠음
- 서버에서 HTML 조각을 뿌리는 엔드포인트 설계 방식은 왠지 꺼림칙함
Datastar는 htmx보다 더 완성도 높은 느낌임. htmx로 몇 개 프로젝트를 성공적으로 만들었지만 이벤트 처리 때문에 JS 글루코드(특히 AlpineJS 등)를 추가로 써야 했던 부분이 늘 아쉬웠음. Datastar가 이런 필요까지 줄여줄 수 있다면 정말 기대됨
- Datastar 사이트의 grugs around the fire 에세이를 읽어보기를 추천함
나는 하이퍼미디어 트렌드에 비교적 늦게 합류했는데, Datastar를 먼저 쓰다 요즘엔 HTMX로 옮겨갔음. Datastar API가 좀 더 낫긴 하지만, htmx 2.0에서 OOB(Out-Of-Band) 업데이트가 지원되니 그 뒤로는 대부분 htmx의 손을 들어줌
- “하이퍼미디어에 늦었다”는 말이 인상 깊음. Ted Nelson이 1965년에 처음 이 용어를 쓴 것이며, 당시 “hyperfilm— a browsable or vari-sequenced movie— is only one of the possible hypermedia that require our attention”라고 했다는 사실을 참고하면 흥미로움. 관련 논문 보기
- HTMX에서 OOB 요소를 다룰 때 아쉬운 점: 1. OOB면 htmx-swap-oob="true"가 꼭 필요, 이 속성이 없으면 기대와 다르게 작동함 2. 반대로 OOB가 아니면 htmx-swap-oob="true"가 있으면 무시되거나 오동작. 이렇다 보니 같은 컴포넌트를 OOB/비OOB로 재사용할 때 서버에서 isOob 플래그를 매번 내려줘야 해서 참 번거로움
- 나는 alpine-ajax의 API가 더 맘에 듦. 여러 타겟 지정만 하면 JS 없이도 각 요소를 일관되게 교체함. Datastar의 signal/state 개념은 오히려 복잡도를 높여서 별로라고 느낌

답변달기

HTMX에서 Datastar로 전환한 이유

소개 및 동기

전환의 계기가 된 문제점

더 나은 Datastar의 API 설계

동작 원리의 차이

HTMX 예제

Datastar의 개선된 접근

컴포넌트 레벨에서 사고하기

상태별 컴포넌트 분리

여러 컴포넌트 동시 업데이트

쇼핑 카트 예

웹 네이티브 철학

다중 사용자 앱을 위한 실시간 업데이트

과도한 복잡성 피하기

주요 팁

한계를 뛰어넘는 가능성

주목할 만한 사례

현재 사용 경험

함께 보면 좋은 글 β

댓글과 토론

Hacker News 의견