16 ポイント 投稿者 GN⁺ 2025-10-12 | 1件のコメント | WhatsAppで共有
  • Datastar は、シンプルな静的Webサイトから リアルタイム共同作業Webアプリ まで構築できる 軽量フレームワーク で、HTMLにスクリプトタグを1つ追加するだけで始められる
  • バックエンド中心のインタラクティブUI を作るためにHTMLを拡張する ハイパーメディアファースト(hypermedia-first) アプローチを採用
  • htmx のようなバックエンドの応答性を提供しつつ、Alpine.js のようなフロントエンドの応答性もサポートし、npmパッケージや依存関係なしで動作 する
  • フロントエンドでは標準の data-* 属性でリアクティブな動作を実装し、バックエンドではイベントによって DOMの修正と状態変更 を行う
  • SSE(Server-Sent Events) ベースのリアルタイム更新と多言語向けSDKの提供により、バックエンド主導の リアクティブWebアプリ開発の簡素化 を目指す

Datastar 概要

  • Datastarは HTMLを拡張するハイパーメディアベースのフレームワーク で、バックエンドから直接DOMを操作してリアルタイムなインタラクティブWebアプリを実現できる構造
  • ブラウザ側ではわずか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生成DeepWikiLLM向けコードサンプル単一ページのドキュメント など豊富な資料を提供

結論

  • Datastarは、HTML中心の ハイパーメディアアプリケーション開発を簡素化 する最新のアプローチ
  • 従来のSPAフレームワークより軽量で、バックエンドとフロントエンドのバランスが取れたリアクティブな開発体験 を提供する
  • リアルタイムストリーミングサーバー中心のUI制御依存関係のないデプロイ が必要なプロジェクトに適している

1件のコメント

 
GN⁺ 2025-10-12
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 が本当にすごいエンジニアリングだと分かるはずだ

    • https://checkboxes.andersmurphy.com/

    • https://cells.andersmurphy.com/

    • https://example.andersmurphy.com/(マルチプレイヤー版 Game of Life)
      checkboxes/cells の例ではビュー描画が適応的に行われるためかなりズームアウトでき、仮想スクロールにも back pressure がかかっている

    • HN のトップに耐えたとはいえ、最初の画面に巨大な文字で "bring your own backend" と書いてあるので、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 ProReact Flow Pro
    • 小さな会社でも自前でサポートしなければならないので、物価の高い国では 5ドルではサポートチケット1件も処理できない

  • Datastar で Go、Templ ベースのフロントエンドをここ数か月開発している。@actions 機能と、レスポンスに応じてページが更新される方式にはとても満足している。ただ、signals 機能については個人的に悩んでいる。単一フィールドやドロップダウンなどには良いが、私のバックエンドは Kubernetes スタイルの API なので、JSON リソースを signal に保存しようとすると、Datastar が構造をサブシグナルとして解析するやり方とうまく噛み合わない。特に Kubernetes の label のようにキーに hostname prefix が付く構造はまったく扱えず、signals がめちゃくちゃになる。データバインディングは単純なキーパスではうまくいくが、インデックスや hostname キーが必要なパスではだめだ。さらに、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

    • 本当にフォークを勧める。誰でもいいからやってほしい

  • 私は React エコシステムに慣れすぎているせいか、ある程度以上に複雑なことをやろうとすると、この方式は論理的にはるかに難しく感じる。説明を誤解していないなら、Datastar はバックエンドが HTML を返すバックエンド-フロントエンドのパターンだが、以前やった経験では本当にもう二度とやりたくない方式だ。特に接続の遅いユーザーは(今でも dsl、古い衛星回線、2G などが多い)、少量の JSON を何度も受け取るより、HTML を何度も大きく受け取る形になるので、体感性能が大きく落ちるはずだ

    • 私の経験では、2G/3G で react app を使うと、そもそもまったく表示されないことが多かった。むしろ HTML で一度に受け取るほうが、たいてい 1〜2秒以内にはコンテンツが出る。エンジニアが勝手に time out を作り直してしまうことが多く、進捗検知はソケット側でしていてもアプリ側には感覚がない。無理に「シュッ」とした体験を狙わないでほしい

    • 「バックエンドが html を返す」というパターンは 56k モデム時代のウェブサイトがそうだったし、その頃は table タグを何十重にも使ってレイアウトしていた記憶がある

    • フロントエンドは非常に広い。個人ブログやショップのように静的コンテンツが多く、速い読み込みだけが必要で、インタラクションが少ないところには 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/ がやっていることも気に入っている