HtmxからDatastarに切り替えました

2025年10月10日原文(everydaysuperpowers.dev)

概要

React から HTMX への変換でコード量を約70%削減した事例紹介
HTMX から Datastar への移行で更なる効率化とリアルタイム対応を実現
Datastar はWebSocketsや複雑なフロントエンド状態管理不要
APIのシンプルさ と サーバー主導の更新 が大きな特徴
Server-Sent Events や Web Components などWebネイティブ技術の活用

ReactからHTMX、そしてDatastarへ

2022年、David Guillotは DjangoCon Europe でReactからHTMXへの大胆な移行事例を発表
コードベースを約70%削減し、機能性も向上
他の多くのチームも同様に、 SPA から マルチページ・ハイパーメディアアプリ への移行で60%以上のコード削減を実現
開発者・ユーザー体験の両面で改善

HTMXからDatastarへの移行体験

HTMX と AlpineJS の連携でUI同期に苦労
異なるライブラリ間の連携でデバッグや初期化処理が複雑化
Datastar は両方の機能をカバーし、ダウンロードサイズも11KB未満
コード量・保守コストの削減、特にモバイルユーザーへのパフォーマンス向上

DatastarのAPIと使い心地

HTMX は複数属性の指定が必要で複雑化しやすい
- 例：hx-target, hx-select, hx-swap, hx-trigger, hx-getなど
Datastar はシンプルな属性指定が可能
- 例：<span data-on-click="@get('/rebuild/status-button')"></span>
保守性が高く、後から見返しても理解しやすい

ページ要素の更新方法の違い

HTMX ：フロント側で振る舞いを定義、ロジックが分散
Datastar ：サーバーが更新箇所を決定、ロジック集中管理
例：サーバーが同じIDを持つ要素のHTMLを返すだけで更新が完了
コンポーネント単位で状態管理しやすく、無効な状態遷移を防止

複数コンポーネントの同時更新

HTMX ではJavaScriptイベントとGETリクエストの連携が必要
Datastar はサーバーから複数要素を同時に更新可能
- 例：ショッピングカートの追加とカート内アイテム数の同時更新
Djangoでの実装例もシンプル

Webネイティブ技術の活用

Datastar はWebの基本技術（CSS View Transitions, Server-Sent Events, Web Components等）を積極活用
AlpineJSの複雑なコンポーネントをWeb Component化し再利用性向上
JavaScriptに頼る場面もあるが、Reactのような重厚なツールは不要
カスタムHTML要素による高いローカリティと再利用性

マルチユーザー・リアルタイム対応

Datastar は Server-Sent Events でリアルタイム更新を実現
HTMXはポーリングやWebSocket実装が必要だが、Datastarはサーバーから即時プッシュ可能
クライアント側の再接続処理も自動化
管理画面やコラボツールのライブ化も容易

シンプルな設計思想とコミュニティ

Datastarコミュニティは「複雑化しすぎない」哲学を共有
コンポーネント全体の再描画推奨、サーバー主導の状態管理
Web Componentsによるロジックのカプセル化
例：Datastar公式サイトの<ds-starfield>要素

Datastarが切り開く新たな可能性

コミュニティは既存ツールの限界を超えるプロジェクトを創出
- 例：Hypermedia活用のDBモニタリングデモ
- 例：1億個のチェックボックス実験
デモや実験を通じて、Datastarの柔軟性と拡張性を証明

このように、Datastarは コード量削減 ・ 保守性向上 ・ リアルタイム性 ・ Webネイティブ技術の最大活用 を同時に実現する、現代的なWebアプリ開発の新しい選択肢。今後もコミュニティによる新たな活用事例が期待される。

Hackerたちの意見

最近これを読んだんだけど、https://drshapeless.com/blog/posts/htmx,-datastar,-greedy-de... Datastarの基本的な（素晴らしい）機能のいくつかがDatastar Proに移行されたって書いてあったんだよね（？！）。オープンソースのプロダクトを金銭的に支援したいし、フレームワークの作者も素晴らしいと思ってるけど、これが作る前例はあまり良くないな。

└

プログラミングを趣味でやってる人の話を読む方がずっと面白いと思う。彼らは典型的な無駄話よりも、実用的な解決策にもっと焦点を当ててるからね。

└

同じく… Datastarを数ヶ月追いかけて、1.0.0のリリースを待ってたんだけど、今はその熱意が消えちゃった。オープンソースだけど実際にはそうじゃないっていう罠に何度も引っかかってきたから。

└

プロジェクトや具体的な内容は全然違うけど、これを見た瞬間、昔のMeteor.jsを思い出した。https://news.ycombinator.com/item?id=9569799

└

例えば、無料版でdata-animateを使いたい場合、動作させるためにJS/CSSのグルーロジックを追加するだけでいいの？

└

Datastar Proについての言及がホームページに全くないのも怪しいよね。[1] もしかしたら、Datastarを自分のウェブサイトに統合する途中で、Pro版に気づくかもしれないけど、それはリファレンスページのサイドバーにしか書いてないんだよね。[2] [1]: https://data-star.dev/ [2]: https://data-star.dev/reference/datastar_pro#attributes

└

知っておいて良かった。リプレースURL機能が有料の背後にあるのは、契約破棄の原因になりそうだね。「フリーミアム」モデルがデータスターの成長を妨げるんじゃないかって思う。最悪の場合、フォークが生まれて元のプロジェクトが飲み込まれるかも。とはいえ、記事の中の彼の態度は本当におかしい。「無料で素晴らしいものをくれた人に対して、もっと無料でくれないからって『ふざけんな』って言うのは、あまりにも傲慢で、オープンソースに関わりたい他の人たちにも悪影響を与えるよね。

└

そうだね、Datastarの作者はクソだ。ほんと最悪。絶対HTMXを使うべきだよ！

Datastarは初心者で、最近の盛り上がりを見てるけど、正直あまり魅力を感じてない。サーバーからHTMLを注入するパッチステートメントって、関心の分離の観点から見ると絶対にひどいと思うし、サーバーからもっとHTMLが注入されると、どんな規模のアプリでも扱いにくい悪夢になるだろうね。

└

これだね。HTMLの断片を生成するエンドポイントを持つのは、なんか違和感がある。

もしかしたら完全に場違いかもしれないけど、彼らのウェブサイトにある「Open the pod bay doors, HAL」のクールな例を見て、全然好きじゃないんだよね。コメントを読むと、これがすごい技術だと思われてるみたいだけど、私がただ年を取ってイライラしてるだけなのかな？これは… 理解するのが非常に難しい。バラバラだし。フロントエンドにはハードコーディングされたIDがあって、あるトリガーがそのブラックボックスからエンドポイントを呼び出す。で、バックエンドでは、選んだ言語のSDKを使って、例えばpatchElements()のようなメソッドを実行する。これがSSEの「フレームワーク」で、コマンドをカスタムの「イベント」ヘッダーやメタデータに変換して、オープンなHTTPストリームで送信する。そして、フロントエンドの「エンジン」が、パイプを通して送ったものを使ってDOMをその場でパッチする。これって、すぐに全体を理解するのが難しくなるような気がする。プレゼンテーションロジックがバックエンドの小さな関数に散らばってるし、もちろんオンロードの状態を持ちたいから、クラシックなテンプレートを使ったレンダーロジックもあるだろうし。今は100%Reactを使ってるけど、すごく満足してるし、エンドツーエンドで型安全だし、想像できる一番派手なUIを作れるから、代替は必要ない。でも、もし必要になったら、軽量なものに戻らなきゃならないなら、RailsやLaravelでSSRに戻って、ちょっとAlpineJSを使うだけで済むと思う。とにかく、きっと「これをうまく機能させて、コードを十分に整理できる」とか「成功してるプロジェクトがたくさんある」とか言う人がいるだろうけど、なんでわざわざそんなことをしなきゃいけないのか理解できない。

└

あなたの気持ちわかるよ。Reactが好きで、そのトレードオフを受け入れていて、使いこなせているなら（いろんなHNの議論を見ていると、簡単なサインはフックの概念を理解していて、Reactが悪い抽象だと叫ぶ必要がないことだね :D）、DatastarやHTMAXのことは忘れてもいいかも。

Hacker Newsで議論の続きを見る

ハクソク