14P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • Datastar는 간단한 정적 웹사이트부터 실시간 협업 웹앱까지 구축할 수 있는 경량 프레임워크로, HTML에 하나의 스크립트 태그만 추가해 시작 가능
  • 백엔드 중심 인터랙티브 UI를 만들 수 있도록 HTML을 확장하는 하이퍼미디어 퍼스트(hypermedia-first) 접근 방식을 채택함
  • htmx처럼 백엔드 반응성을 제공하면서도, Alpine.js처럼 프론트엔드 반응성도 지원하며 npm 패키지나 의존성 없이 동작
  • 프론트엔드에서는 표준 data-* 속성으로 반응형 동작을 구현하고, 백엔드에서는 이벤트로 DOM 수정 및 상태 변경을 수행함
  • SSE(Server-Sent Events) 기반의 실시간 업데이트와 다양한 언어용 SDK 제공으로, 백엔드 주도형 리액티브 웹앱 개발의 단순화를 목표로 함

Datastar 개요

  • Datastar는 HTML을 확장하는 하이퍼미디어 기반 프레임워크로, 백엔드에서 직접 DOM을 조작해 실시간 인터랙티브 웹앱을 구현할 수 있는 구조임
  • 브라우저 측에서는 단 10.7KB짜리 스크립트를 로드하는 것으로 모든 기능이 활성화되며, 빌드 도구나 프레임워크 설치가 불필요함
  • Hypermedia Systems의 원칙을 계승하여 서버가 UI의 상태를 주도하고, 클라이언트는 이를 반응적으로 반영함
  • 데이터 갱신, 상태 변경, DOM 패칭(patching) 을 백엔드 이벤트로 처리함으로써 프론트엔드 로직을 최소화함

설치 방법

  • 가장 간단한 방법은 CDN을 통해 다음과 같이 스크립트를 추가하는 것임
  • 또는 직접 파일을 다운로드하거나 Datastar bundler를 사용해 자체 번들을 생성할 수도 있음
  • npm 설치나 Node 환경 설정이 전혀 필요하지 않음

data-* 속성과 반응성

  • 핵심은 HTML의 data-* 속성을 통해 선언적으로 동작을 정의하는 것
    • 예: data-on-click="alert('Hello!')"
  • data-on 속성은 특정 이벤트 발생 시 실행할 Datastar 표현식을 지정하며, 여기서 일반 JavaScript도 사용 가능함
  • 전용 VSCode 확장IntelliJ 플러그인을 통해 자동완성과 문법 지원 기능을 제공함

백엔드 주도형 DOM 패칭

  • Datastar는 서버가 프론트엔드를 주도하는 방식으로 동작함
    • 서버가 HTML 조각을 전송하면 Datastar가 이를 morphing 전략으로 DOM에 병합함
    • morphing은 변경된 부분만 업데이트하여 상태를 유지하고 성능을 개선함
  • 예시:
    <button data-on-click="@get('/endpoint')">Open the pod bay doors, HAL.</button>  
    <div id="hal"></div>  
    
    서버에서 HTML 조각을 응답하면 Datastar가 자동으로 id="hal" 요소를 교체함

Server-Sent Events (SSE) 기반 스트리밍

  • 서버는 datastar-patch-elements 이벤트를 전송하여 실시간으로 DOM을 갱신할 수 있음

  • 다음 예시는 HAL의 대사를 출력 후 1초 뒤에 다시 초기화하는 예임

    event: datastar-patch-elements  
    data: elements <div id="hal">I’m sorry, Dave. I’m afraid I can’t do that.</div>  
    
    event: datastar-patch-elements  
    data: elements <div id="hal">Waiting for an order...</div>  
    
  • 이를 지원하기 위해 Datastar는 다양한 언어용 SDK를 제공함:

    • Clojure, C#, Go, Java, Kotlin, PHP, Python, Ruby, Rust, Node.js
    • 각 SDK는 PatchElementsServerSentEventGenerator 클래스를 통해 DOM 패칭 이벤트를 송출함

Datastar Inspector 및 도구

  • 브라우저의 개발자 도구 외에도 Datastar Inspector를 이용해 SSE 이벤트를 시각적으로 확인할 수 있음
  • 공식 문서 외에도 AI 생성 딥위키, LLM용 코드 샘플, 단일 페이지 문서 등 풍부한 자료 제공

결론

  • Datastar는 HTML 중심의 하이퍼미디어 애플리케이션 개발을 단순화하는 최신 접근법
  • 기존의 SPA 프레임워크보다 가볍고, 백엔드와 프론트엔드의 균형 잡힌 반응형 개발 경험을 제공
  • 실시간 스트리밍, 서버 중심 UI 제어, 의존성 없는 배포가 필요한 프로젝트에 적합
Hacker News 의견
  • Datastar 운영진은 신념과 철학이 뚜렷하고 신입에게도 아낌 없는 시간을 내주는 멋진 분들임, Pro 버전을 둘러싼 논란 속에 잊히고 있지만, 이건 결코 수익화 전략이 아니고 회사는 비영리 등록임, 소수에게만 필요한 기능들만 Pro로 빼 이 기능을 원하는 소규모 그룹이 주로 문의를 하면서 지원 부담이 커지는 걸 효율적으로 통제하는 방식임, 오히려 혁신적이고 공정한 접근법으로 (a) 조심해야 할 '발목잡기' 기능임을 신호 주고, (b) 가장 많은 지원이 필요한 사용자나 Datastar의 많은 가치를 누리는 사람이 약간의 비용을 내게 하고, (c) 커뮤니티 전체에 더 많은 시간을 쏟을 수 있어 긍정적인 효과임

    • data-animate, data-on-resize, data-scroll-into-view 같은 기능이 만약 '발목잡기'라면 제대로 설계가 안 된 것임, 이런 기능이 소수에게만 필요하다고 생각하지도 않음, 그들이 원하는 걸 유료로 하는 건 상관 없지만 굳이 핑계를 만들 필요까지는 없다고 생각함

    • copy-to-clipboard 기능이 정말 지원 부담이 큰 기능인지 궁금함, Datastar 수준이 정말 그렇게 형편 없다면 심지어 간단한 기능도 제대로 작동하려면 지원이 많이 필요하다는 건데 동의하기 어려움

  • Datastar가 실시간/협업/멀티플레이어에 충분하지 않다고 생각하거나 Pro 기능이 반드시 필요하다고 생각한다면, 5달러 VPS에서 돌아가면서 Pro 기능 없이도 HN 메인에 버틴 데모 3개를 참고하면 Datastar가 정말 대단한 엔지니어링임을 알 수 있음

  • 진행 중인 관련 HN 토론 쓰레드 안내:

  • 왜 커뮤니티가 이렇게 적대적인지 잘 모르겠음, Datastar는 오픈소스가 대부분이고 어떤 언어에서도 동작하며 개발 자금 마련을 고민하는 점도 흥미로운 프로젝트임, 자기 프로젝트를 자기 식대로 밀고 나가는 것이 당연하다고 생각함, golang으로 해킹도 해볼 생각이고 수고에 감사함, 단 한 가지 피드백이 있는데, 내 나라 기준 299달러는 정말 큰돈이고 일부 Pro 기능이 꼭 필요할 수도 있어서 가격이 너무 부담됨, Steam처럼 나라별 동적 가격 정책 또는 기부 형태의 지원도 고려해줬으면 좋겠음, 애니메이션 등은 sveltekit에서 무료로 제공되고, 무료로 받고 싶은 게 아니라 정말 감당이 안 될 뿐임, 기업 위주로 더 높은 가격을 매기고 솔로 개발자에겐 더 저렴하게 해줬으면 좋겠음, 나는 그동안 온라인 커뮤니티나 프로젝트에 돈 낸 적 없지만 Datastar는 5~10달러 정도라면 후원하고 싶음, 솔로 티어 가격을 switch 게임(silksong) 정도 수준으로만 낮춰주면 좋겠다는 바람임, 정말 멋진 프로젝트임에도 커뮤니티 반응이 이상할 정도로 비판적이라 아쉬움

    • 위 의견이 여기까지의 논의 중 유일하게 합리적 비판 같음, 299달러는 정말 많은 사람들에게 접근 불가능한 금액임, 그러나 개발자들이 물가 비싼 나라에서 살아 더 높은 가치를 제공하는 것에 비하면 작은 금액일 수도 있음, 국가별 가격 체계를 도입하길 바라는 건 좋은 생각이지만 실현 방법이 난해하고 실 이익도 미미할 수 있음, 이미 무료 오픈소스 기능이 95% 이상의 가치와 기능을 주고 있으니 Pro 라이선스가 굳이 필요 없는 대부분은 그냥 무료로 마음껏 사용하고 배워가거나 이익을 얻어갔으면 함

    • 내 비판의 출발점은 다음과 같음

      • 홈페이지에는 Pro에 대한 언급이 전혀 없고 문서 뒤적이다가 알게 됨. 유인책 같은 느낌임
      • Pro는 지원이나 예제뿐 아니라 실제 기능을 묶고 있음
      • Pro 기능에 의존하면 Datastar에 종속되어 유지보수권한이 벤더에 묶임
      • Pro 없이 사이트가 아예 동작하지 않으니 벤더 락인이 더 크게 문제임
      • Pro에서 뭘 사는지 체험 예제가 없음, Alpine.js나 React Flow Pro처럼 브라우저에서 시험해볼 수 있는 게 없음
      • 소스코드를 제공받더라도 개선사항을 공유할 수도 없음
      • 가격이 아니라 구조와 가치에 대한 문제임, 누군가에겐 저렴, 누군가에겐 비쌀 수 있음
      • 참고할 만한 나쁘지 않은 Pro 모델 예: Alpine.js Pro, React Flow Pro
    • 작은 회사도 자체적으로 지원해야 하므로 물가 비싼 나라에서는 5달러면 지원 티켓 한 건도 처리 불가임

  • Datastar로 Go, Templ 기반 프론트엔드를 몇 달째 개발 중임, @actions 기능과 응답에 따라 페이지가 업데이트되는 방식이 매우 만족스러움, 단 signals 기능은 개인적으로 고민 중임. 단일 필드나 드롭다운 등엔 괜찮지만 내 백엔드가 Kubernetes 스타일 API라 JSON 리소스를 signal에 저장하려 하면 Datastar가 구조를 서브 시그널로 파싱하는 방식 때문에 잘 안 맞음, 특히 Kubernetes의 label처럼 key에 hostname prefix가 붙는 구조는 전혀 다루지 못하고 signals가 엉망이 됨, 데이터 바인딩이 단순 키 경로는 잘 되지만 인덱스나 hostname key가 필요한 경로에선 안 됨, 또 HTML 속성이 JS에서 자동으로 변환되는 규칙(snake→camel 등)과 modifier 처리도 오류 유발이 많아서 복잡함, 그래도 HTMX/Alpine 기능을 하나로 통합해 hypermedia 방식으로 구현한다는 점에 만족함, NodeJS 생태계 회피가 가능해지는 것도 만족임, RC에서 wire format이 바뀐 적 있는데 Fiber를 써서 Go SDK 없이 직접 구현하다보니 업데이트가 힘들었음, 하지만 포맷 변화는 좋은 변화였다고 생각함, 개발진이 좋은 방향으로 가고 있으니 계속 발전하길 바람

  • Datastar의 아이디어가 매우 훌륭해 보여서 적용도 고민했던 적 있음, 다만 오픈소스 버전이 Pro와 기능 경쟁 안 하려고 제한 둔 것은 하드포크 빠른 길이 될 수도 있다는 우려임, 대규모 생태계를 가진 것도 아니라 갈아탈 이유가 충분하다고 봄
    [edit: 오픈코어에 일부 플러그인을 닫아두는 모델은 매우 합리적일 수도 있고, 그렇지 않더라도 선택지는 많음, Datastar 개발자와 사용자 모두 성공하길 바람]

    • 하드포크 걱정을 한다면 pre-pro 시절의 플러그인을 포크해서 현 Datastar pro 버전에 맞게 만들어주면 모두에게 도움이 될 것임, 50줄 정도의 작은 코드로 되어있으니 아주 쉬움

    • "제한을 둔다"는 표현은 과하고, Pro에만 들어가는 속성/이벤트는 소수이고 핵심적인 기능들은 아님, 오히려 약간의 JS로 서버에서 보내면 다 대체 가능한 수준임, 구체적인 리스트 참고: https://data-star.dev/reference/datastar_pro

    • 포크를 정말 추천함, 누구든 해주길 바람

  • 나는 리액트 생태계에 너무 익숙해져서 그런지, 일정 수준 이상으로 복잡한 일을 하려면 이 방식이 논리적으로 훨씬 더 힘들게 다가옴, 설명을 잘못 이해한 게 아니라면 Datastar는 백엔드가 HTML을 반환하는 백엔드-프론트엔드 패턴인데 예전에 해봤던 바로는 정말 다시 하고 싶지 않은 방식임, 특히 연결이 느린 사용자는(아직도 dsl, 옛 위성, 2G 등 많음) 작은 양의 JSON 여러 번 받는 것보다 HTML을 여러 번 크게 받는 식이어서 체감 성능이 대폭 하락할 것임

    • 내 경험상 2G/3G에서 react app을 사용하면 애초에 절대로 안 뜨는 경우가 많았고, 오히려 HTML로 한 번에 받으면 대부분 1~2초 안엔 컨텐츠가 뜸, 엔지니어가 임의로 time out을 다시 만드는 경우가 많으니, 진척도를 감지하는 건 소켓에서 하고 있는데 앱에선 감각이 없음, 굳이 '휙휙' 하려 하지 말았으면 함

    • "백엔드가 html을 반환한다"는 패턴은 56k 모뎀 시절 웹사이트가 이랬고, 그 때는 테이블 태그 수십 겹으로 레이아웃 짰던 기억이 남

    • 프론트엔드는 매우 광범위함, 개인 블로그나 상점처럼 정적 내용이 많고 빠른 로딩만 필요하며 상호작용 적은 곳엔 htmx 계열 도구가 좋지만, Figma나 Discord급 앱을 만들려면 이 방식으론 부족함, 극한의 마스터는 DOM은 감옥일 뿐이고 canvas와 GPU 계산 조합만 만족함

    • 완전 오프라인이라면 당연히 이 방식 말고는 답이 없음, 하지만 대다수 사이트는 영속적인 상태를 굳이 필요로 하지 않으니 페이지 캐싱이나 이벤트 상태만으로도 충분히 쓸 만함, datastar js sdk를 서비스 워커에서 돌리고 필수 상태만 브라우저 스토리지로 동기화하면 백엔드 역할도 가능함, 느린 연결이라도 sse 스트림에서 압축을 세게 쓰면 중복 정보 전송이 많아져도 압축률 90% 넘게 나옴, 느린 인터넷은 대체로 느린 디바이스 사용과 연결되니 react, css-in-js 등 무거운 것보다 Datastar가 훨씬 가벼움, 기능적으로도 거의 손해 없이 엄청 단순해짐

  • 특별히 새롭진 않은 패턴임, DHTML에서 XHR로 넘어가던 시절 한 번 이 방식을 거쳤고 각종 트레이드오프 때문에 거의 버려졌던 적 있음, DOM 패칭 등 신기술도 결국 같은 문제(긴밀 결합, 불안정, 대용량, 지연 이슈)를 안고 옴, Datastar도 소규모 회사가 개발 비용을 절감하는 솔루션에 가까울 뿐, 기술의 새로운 한계를 뚫는 건 아님, 나쁘지는 않지만 결국 역사가 반복되는 느낌임

    • Datastar 저자로서, 아무 것도 새롭지 않음이 오히려 의도임, jQuery가 원래 페이지에 살짝만 영향 주던 좋은 시절을 지나 spa가 모든 걸 프론트에서 하려고 하면서 백엔드가 상태를 쥐고 있다는 본질이 사라진 게 아쉬웠음, 내가 하고 싶은 건 혁신이 아니라 정상화임

    • Astro가 이미 이 문제를 해결한 것 아닐까 하는 생각임

  • 페이지 하단의 동영상(영화)이 너무 좋아서 다음 프로젝트에 꼭 쓰고 싶게 만드는 느낌임, 'The planet uncomplicanus'라는 부분이 특히 인상적임

  • https://www.zjax.dev/가 한 결과도 마음에 듦