ハクソク

世界を動かす技術を、日本語で。

Datastar: インタラクティブなウェブアプリを構築するための軽量ハイパーメディアフレームワーク

227日前原文(data-star.dev)

概要

Datastar は、シンプルかつ高性能な リアクティブWebアプリ 開発のための軽量フレームワーク。 バックエンド言語 を自由に選択でき、 SSE や HTML を活用したリアルタイム通信を実現。 フロントエンドの状態管理 をバックエンド主導に移行し、複雑さを大幅に削減。 JavaScriptやSPA の複雑さを回避しつつ、 リアルタイムUI を簡単に構築可能。 非営利団体とコミュニティ が支える、 シンプル・高速・軽量 なフレームワーク。

Datastar: ハイパーメディア・リアクティブWebアプリ開発フレームワーク

  • Datastar は、 軽量（10.75 KiB） で、 シンプルなWebサイト から リアルタイム協調Webアプリ まで対応
  • サーバーサイドレンダリング のシンプルさと、 フロントエンドフレームワーク の強力さを両立
  • バックエンド言語 は自由選択（公式SDKあり）
  • text/html や text/event-stream（SSE） 形式に対応し、HTMLレスポンスやリアルタイムイベント配信が可能
  • 無駄なJavaScript を使わず、 フロントエンド開発の負担軽減 を実現

バックエンド主導のフロントエンド構築

  • 状態管理 をフロントエンドからバックエンドへ移行、 ロジックの複雑化 を防止
  • *data-属性 を利用し、フロントエンドに リアクティビティ を追加
    • 例:
      • <button data-on-click="@get('/endpoint')">Open the pod bay doors, HAL.</button>
      • <div id="hal">Waiting for an order...</div>
  • バックエンドからDOMや状態を直接操作
    • 例:
      • sse.PatchElements(<div id="hal">I’m sorry, Dave. I’m afraid I can’t do that.</div>)
      • time.Sleep(1 * time.Second)
      • sse.PatchElements(<div id="hal">Waiting for an order...</div>)

Datastarのメリット

  • JS/TSエコシステム の煩雑さから解放
  • SPAの複雑さ回避、より少ないコードで リアルタイムUI 実現
  • 仮想DOM・hooks・JavaScript不要、 マルチプレイヤー・リアルタイム 機能が標準搭載
  • どんなバックエンド言語 でも利用可能
  • ビジネスロジック開発 に集中できる環境

コミュニティとサポート

  • 非営利団体 による運営、 VC資本なし
  • コミュニティ主導 の開発
  • 手作業によるコード、 シンプル・高速・軽量 を徹底

Datastar導入のポイント

  • サーバーサイド中心 の設計思想
  • 低コストでリアルタイムWebアプリ 開発
  • 複雑なSPAやJSフレームワーク からの脱却
  • HTML・SSE ベースの 直感的な開発体験
  • 新しいフロントエンド開発のアプローチ として注目

Hackerたちの意見

もしかしたら、今の時点でReactエコシステムにどっぷり浸かりすぎてるせいかもしれないけど、ちょっと複雑なタスクをやろうとすると、これがかなり考えるのが難しくなりそうだね。それに、もし勘違いしてなければ、これはバックエンドがHTMLを返すことにかなり依存してるみたいで、バックエンドをフロントエンドとして使うってことなんだけど、過去の経験から言って、そんなのには絶対手を出したくない。特に、インターネット接続がめちゃくちゃ悪いユーザー（まだDSLや古い衛星通信、2Gを使ってる人もいる）を考えると、バックエンドに対してもっとリクエストを送って大きなHTMLの塊を返すのは、少ないリクエストでJSONを返すのに比べて、ユーザー体験がかなり悪化すると思う。

└

2G/3GでReactアプリを使った経験から言うと… HTMLの方が断然いいね。通常、HTMLだと1〜2秒でコンテンツが表示されるけど、Reactアプリは全然読み込まれないこともあるから。なんで読み込まれないの？それは、エンジニアたちがバイト毎秒で考えられないようなタイムアウトを自分たちで作っちゃうから。ソケットにはすでに1分のタイムアウトがあって、まだ受信してるかどうかは分かるけど、アプリケーションには進行状況の感覚がないんだ。もう再発明しないでほしい。

└

「これはバックエンドがHTMLを返すことにかなり依存している」→ これは56kbpsモデムの時代にウェブが機能していた方法だね（さらに、レイアウトのために10段階の""があったりして）。

└

本当にオフラインなら、もちろんこれが機能するわけがないよね。でも、ほとんどのサイトは永続的な状態が必要ないから、ページをキャッシュするのは全然可能だよ。ボタンを切り替えたり、入力ボックスと別のキャプションをリンクさせたりするような一時的なものだけだからね。それに、データスターのJS SDKをサービスワーカーから実行すれば、必要な状態をブラウザストレージに同期させておけば、バックエンドもそこに置けるよ。あと、遅い接続の場合、圧縮はすごく強力だし、特に冗長な情報が送られるSSEストリームでは効果的だよ。別のコメントにはすごいデモのリンクがあって、圧縮率は90％以上だって。遅いインターネットは、遅いデバイスとも関係があって、ReactやCSS-in-JSの膨大な負荷を処理できないことが多いんだ。Datastarは機能をほとんど犠牲にすることなく、すべてを大幅に簡素化してくれるよ。

└

「フロントエンド」って広い分野だよね。自分のブログ用のサイトを作る人もいれば（Wordpressで十分な場合も）、主に静的コンテンツのショップを作る人もいるし、FigmaやDiscordみたいな本格的なソフトウェアを作る人もいる。真の達人にとっては、DOMは監獄で、GPU加速計算と組み合わせないとダメなんだ。もちろん、htmxやその仲間たちはブログやドキュメント、ショップにはいいけど、「ソフトウェア」レベルのウェブサイトは作れないよね。

ホームページには書いてないけど、Datastarは以下の機能に対して料金を取ってるよ：data-animate - 要素の属性を時間をかけてアニメーションさせる。data-custom-validity - 要素にカスタムの有効性を追加。data-on-raf - アニメーションフレームごとに式を実行。data-on-resize - 要素のリサイズ時に式を実行。data-persist - シグナルをローカルストレージに保存。data-query-string - クエリ文字列のパラメータをシグナルの値と同期。data-replace-url - ブラウザのURLを置き換える。data-scroll-into-view - 要素を表示領域にスクロール。data-view-transition - view-transition-nameスタイルを設定。価格は個人開発者が299ドル、チームが999ドル以上だよ。 https://data-star.dev/reference/datastar_pro

└

これが彼らの仕事を資金調達する良い方法かどうかはわからないけど、オープンソースを開発者にとって持続可能にするモデルを探るのは良いことだと思うよね？

└

これを含めたかったのは、Datastarの開発とメンテナンスが持続可能であるためだよ。そして、彼らは登録された501(c)(3)の非営利団体なんだ。 https://data-star.dev/star_federation#nonprofit-organization

└

なんか変なコメントだね。わざわざこんなことを持ち出す理由って、相手を悪く見せたいだけじゃないの？サイトにはいろんなところにちゃんと書いてあるし。しかも、彼らはほとんどの人やサイトにはこれらの機能が必要ないって言って、プロライセンスの購入を積極的に勧めてないんだよね。もし必要なら、機能のためには小さな代金だし、彼らの非営利団体のコストをカバーするためのちょっとした収入にもなるし。無料で提供してきた努力に対して、誰かがオプションで何かを請求することが悪いことなんて、あり得ないよね…それに、すごく便利な「インスペクター」が付いてて、すべての信号やSSEイベントが見れるし、もうすぐ超効率的なウェブコンポーネントフレームワーク（Rocket）とCSSフレームワーク（Stellar）も登場するよ。私は主に彼らをサポートするためにプロライセンスを買ったけど、インスペクターは素晴らしいし、RocketとStellarを試すのが楽しみだよ。

└

うん、なんで誰かがこれをターボ+スティミュラスより考えるのか全然わからないよ。

└

データスターを試してみたけど、すごく良かった。でも、こういう動きを見てすぐに気が引けた。これは正しいやり方じゃないと思う。プロサポートの方が良かったよ。それに、ライセンスがデータスタープロをオープンソースプロジェクトで使うことを禁止してるのも変な動きだね。

└

コメントを更新して、これは一回限りの生涯コストで、サブスクリプションじゃないってことをみんなに知らせた方がいいよ。Tailwind UIと同じくらいの価格で、みんなそれにお金を払うのは全然気にしてないしね。

一番下の映画、次のプロジェクトに使いたくなる！最高だね。「惑星アンコンプリカヌス」 :D

Datastarがリアルタイム/コラボレーション/マルチプレイヤーに十分じゃないと思ってる人や、PRO機能が必要だと思ってる人へ。これらの3つのデモはそれぞれ5ドルのVPSで動いてて、PRO機能は使ってないよ。全部、HNのフロントページを生き残ってる。Datastarは素晴らしいエンジニアリングの作品だよ。 - https://checkboxes.andersmurphy.com/ - https://cells.andersmurphy.com/ - https://example.andersmurphy.com/（ライフゲームのマルチプレイヤー）チェックボックスやセルの例では、適応ビューのレンダリングがあって、かなりズームアウトできるよ。バーチャルスクロールにもバックプレッシャーがかかってる。

└

彼らはHNのフロントページを生き残った。でも、スプラッシュページには「自分のバックエンドを持ってこい」って大きな文字で書いてあるよね。だから、HNを生き残ることはDatastarがやってることじゃないんだ。

この投稿やHNのフロントページにあるDatastarに関する他の投稿は、なんか不自然に感じる。特に新しく作られたアカウントがこれに関わってるのが、マーケティングの一環みたいに見えるんだよね。

└

私はHTMXを使ってて、今日までDatastarのことは全然知らなかった。最初の投稿を見た人たちが、調べて他のDatastarに関することを見つけて投稿したっていうのが結構いると思う。

└

これと他のネガティブで、でも議論のないコメントがDatastarに関して不自然に感じるんだよね…

└

あなたのコメントを見る前は私も同じことを思ってた。いくつかの投稿者は新しいアカウントか、以前のDatastarに関する投稿にもコメントしてた人たちで、妙に攻撃的なんだよね。

└

それはよくあるHNのパターンだね。「なぜxに切り替えたか」みたいな投稿があって、誰かがxのウェブサイトにリンクしたり、他の似たようなプロジェクトのウェブサイトにリンクしたりして、みんながフロントページに載るんだ。単なる共鳴現象だよ。

└

多分、協調的なものというよりは模倣やフォローアップの影響だと思うけど、詳しくは見てないんだ。スレッドを統合するかどうか、どれが「勝つ」べきか決めかねてる…

なんでコミュニティがこんなに敵対的なのか分からないな。「フェニックス使え」とか「課金する」とか「敵対的だ」とか言ってるけど、そんなことないよ。これは本当にクールなプロジェクトだし、ほとんどの部分がオープンソースで、どんな言語でも動くんだ。開発資金を得る方法を探ってるのも面白いし、彼らのプロジェクトだから、彼らがやりたいように進める権利があるのは当然だよね。見た目もかっこいいし、ゴーランでハックしてみようかな。ほんとにありがとう。ひとつだけフィードバックがあるんだけど、課金は全然気にしないけど、299ドルって、特に私の国ではかなりの金額なんだ。もし本気で取り組むなら必要になるかもしれないけど、正直言ってその一つすら手が出せない。非営利団体が、スチームみたいに国ごとに動的な価格設定をしてくれたらいいな。あとは、寄付をする人たちへの支援とか...。データスターのチームに対して全然悪意はないけど、アニメーションとかはすでにスヴェルトキットで無料で手に入るし、無料で欲しいわけじゃないけど、ここでは本当に手が出せないんだ...。もう一つの提案は、こういうものを簡単に買える企業にもっと頼るとか、もしくはチームがソロ開発者向けに価格を下げて、299ドル近くの心配をしないで試せるようにしてくれたらいいなって思う。プロジェクトには深いリスペクトを持ってるよ。ほとんどが無料のツールだから、コミュニティの反応はちょっと変だよね...。でも、正直に言うと、オンラインで何かにお金を払ったことがない私だけど、初めて5〜10ドルでこのプロジェクトを支援したいと思ってる。大した金額じゃないけど、今はそれが私が寄付できる限界なんだ。ソロレベルの価格をせめてシルクソングの価格にしてくれないかな？よく分からないけど、プロジェクトはすごくクールだから試してみるつもりだよ。

└

問題は、小さな会社が自分たちの高い生活費の国からサポートを提供しなきゃいけないことなんだ。5ドルじゃ、サポートチケット一つを出すのにも足りないよ。

└

これが今まで見た中で唯一の妥当で合理的な批判だね、君に拍手。299ドルは確かに多くの人にとって手が届かない金額だ。でも、開発者たちは物価が高い場所に住んでいるから、彼らが提供する相対的な価値に比べれば小さな価格なんだと思う。地理的に相対的な価格設定を検討する価値はあると思うけど、そんなのどうやって実装するの？「ただ動く」何かがあるのかな？多分ないだろうね。それに、開発者たちはすでにたくさんの時間を費やしているから、彼らが得られるのはほんのわずかだろうから、こんな価格システムを設計するためにさらに時間を投資するのはあまり意味がないと思う。もしかしたら、君がこの問題に取り組むべきかも？とにかく、開発者たちはほとんどの人がプロライセンスを必要としないってことをはっきり言ってるよ。95%以上の機能と価値はオープンソースライブラリで無料で利用できる。使って楽しんで、学んで、利益を得て！

└

コミュニティがこんなに敵対的なのはなぜかわからない 他の人の代わりには話せないけど、私の考えはこうだ: - ホームページにはProのことが全く触れられていない。ドキュメントをめくって初めてProのことを知った。これって、なんかズルい感じがする。「私たちのクールなオープンソースプロジェクトを見て！」って言って、ハマったら「全部欲しいならProを買ってね」って。 - Proは本物の機能をロックしていて、サポートやビデオチュートリアル、コード例だけじゃない。 - これはベンダーロックインだ。Proの機能を頼りにしたいなら、メンテナに振り回されることになる。 - ベンダーロックインが特に問題なのは、Datastarがないとあなたのウェブサイトが動かないこと。CIサービスやテストプラットフォームが動かないのは確かに困るけど、コードをコンパイルしてデプロイできれば生き残れるし、手作業でもなんとかなる。ライブラリはそうはいかない。 - 何を買っているのかの例がない。少なくとも非Pro機能は、無料で試せるから、Proに関しては何が自分の欲しいものか全く見当がつかない。AlpineのProの例と比べてみて。[1] それに、ソースコードがもらえるかどうかわからないけど、たとえもらえたとしても、自分の改善を誰かと共有できない。ちなみに、価格については一切触れてない。価値は人それぞれだから、ある人には手が届かない価格でも、他の人にはお得に感じることもある（例えば、フリーランスの人は一回の仕事で元が取れる）。1年前に雇い主にAlpineをスポンサーしてもらったけど、彼らはDatastarがProで請求している額以上をAlpineに寄付してくれた。参考までに、非問題のProバージョンを持つプロジェクトはAlpine.js[2]とReact Flow[3]だ。React FlowはホームページにProページへのリンクもあるし。[1] https://alpinejs.dev/components [2] https://alpinejs.dev/components [3] https://reactflow.dev/pro

このパターンは新しいわけじゃないよ。業界はDHTMLからXHRに移行したときにすでに経験していて、（ほとんど）良い理由で放棄されたんだ。現代のDOMパッチ技術は新しいバリエーションを生み出したけど、結局は同じ古いトレードオフを抱えてる。タイトなカップリングや脆弱性といったエンジニアリングの問題や、レイテンシや大きなペイロードボリュームといったネットワークの問題を解決するわけじゃない。だから、私にとっては、これは小規模・中規模の企業向けにエンジニアリングコストを抑えた解決策を提供しようとする努力に感じる。技術の境界を広げようとする動きではなくて、悪いことじゃないけど、歴史がまた繰り返されるのを見るのはちょっと残念だね。

└

アストロはこれをすでに解決してるんじゃない？

└

データスターの作者だよ。そう、新しいことは何もない、そこがポイントなんだ。君はjQueryで道を見失ったように見えるけど、ただページにスプリンクルしていただけだった。でも、SPAはリアクティビティのアプローチとして面白くなかったし、バックエンドがほとんどの状態を制御しているポイントを見逃していた。私は革新的になろうとしているわけじゃなくて、ただ普通の状態に戻そうとしているだけなんだ。

Datastarのアイデアは素晴らしいと思うし、自分でも取り入れようかなって考えたけど、オープンソース版をプロ版と競合しないように制限するのは、早々にハードフォークに繋がる気がする。彼らが切り替えに抵抗するような広大なエコシステムを持っているわけじゃないしね。[編集: オープンコアといくつかのクローズドプラグインのモデルがうまくいくかもしれない。そうでなければ、みんな選択肢があるし。D*の開発者とユーザーの成功を願ってるよ。]

└

早々にハードフォークに繋がる気がする。 ほんとそれ！みんなのために、プレプロプラグインをフォークして、現在のd* proと互換性を持たせてくれない？だって、どれも50行くらいのコードだし、簡単だと思うよ。

└

ぜひやってほしい！めっちゃおすすめだから、お願いフォークして！

└

「制限する」って言葉は強すぎるかも。Proにしかない属性やイベントはほんの少しだけで、ほとんどのサイトの運営には基本的に必要ないと思う。[1] 実際、サーバーから送るちょっとしたカスタムJSで代替できるかもしれないし。[1] https://data-star.dev/reference/datastar_pro

関連スレッド: HtmxからDatastarに切り替えた - https://news.ycombinator.com/item?id=45536000 - 2025年10月（223コメント） それに、https://news.ycombinator.com/item?id=45537372もあって、どうしようか考え中（もう少し待って… 編集: うまく統合する場所を見つけた: https://news.ycombinator.com/item?id=45536535） 前回: Datastar: 未来のWebフレームワーク？ - https://news.ycombinator.com/item?id=43655914 - 2025年4月（155コメント）

ここ数ヶ月、Go、Templ、Datastarを使ってフロントエンドを作ってるんだけど、@actionsがすごく好きだし、レスポンスでページが更新されるのもいい感じ。ただ、signalsについてはちょっと迷ってる。個別のテキストフォームフィールドやドロップダウンの開閉みたいなシンプルなことには問題ないけど、バックエンドがKubernetesスタイルのAPIサーバーだから、JSONのKubernetesスタイルのリソースをsignalに保存するのはうまくいかないんだ。Datastarが構造を子signalにパースする実装のせいで。これをオフにできる方がいいかな。K8sのラベルが壊れる例もあるし、これがmap[string]stringで、キーはホスト名がプレフィックスになってることが多い。例えば、example.com/label-keyみたいな感じ。Datastarはこれらのキーを全く扱えなくて、結果的にsignalがめちゃくちゃになっちゃう。多分、signalsを意図した使い方じゃないかもしれないけど、data-signals-resource="k8sJson"みたいにして、data-bind="resource.metadata.name"ってやるのはすごくいい方法だと思う。メタデータ名にはうまくいくけど、パスのどこかがリストのインデックスやホスト名スタイルのラベルキーになる必要があるときはダメなんだ。あと、Datastarのsignalsで痛いのは、HTMLで書いたsomething-somethingがJSではsomethingSomethingになる魔法みたいなやつと、スネークやキャメルなどの__modifiersがあること。扱うのがエラーを引き起こしやすくて、あんまりいい体験じゃないな。でも、全体的には今のところ頑張って使ってるし、HTMXとAlpineの機能が一つに実装されて、ハイパーメディアを一般的なアプローチとして使うのはいいと思ってる。NodeJSエコシステムを避けられるなら何でもいいかな。数回前のRCでワイヤーフォーマットが変わったときは、Fiberを使ってるからGo SDKが使えなくて、自分で実装したから結構大変だったけど、ワイヤーフォーマットは明らかに良くなったから、やる価値はあったと思う。開発者たちは何かいいものを掴んでると思うし、どんどん改善していくべきだね。