ハクソク

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

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

227日前原文(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のことは忘れてもいいかも。

└

Datastarを本気で試したことはないけど、HTMXは hype に乗って試してみたら、すぐにメンテナンス不可能になった。私の夢は、Goサーバーがハイパーメディアを生成して、フロントエンドフレームワークを使わずに済むことだったけど、書いていたGoコードが硬直していて複雑で、全然良くなかった。実際、同じ晩にコーディングセッションをして、コードが何をしているのかを忘れたのはこれが初めてだよ。今はElixirとPhoenixで全く逆の体験をしている。これは過剰な認知負荷なしで、エンドツーエンドの流れるような体験に感じる。

└

もし軽いものに戻る必要があるなら、RailsのSSRに戻るかな。今のRailsのデフォルト設定にはTurboが含まれていて、Datastarと概念的にかなり似ているみたいだね。

クリスに感謝！彼が自分の快適ゾーンに挑戦し続けて、私たちと彼の印象や学びをシェアしてくれるのは素晴らしい！私は4年間htmxでウェブアプリを書いてきたから、ちょっと偏見があるかもしれないけど、最初の感想をいくつか挙げるね。- このブログ記事の例は、htmxとDatastarの主なアーキテクチャの違いを示しているように思う。htmxはHTML主導、Datastarはサーバー主導なんだ。だから、クライアントサイドのAPIはシンプルだけど、反対側はもっと複雑でなきゃいけない。最初の例では、HTML要素がサーバーから返されたHTMLフラグメントをどこに注入するかの情報を持っていなければ、サーバーがそれを知っておく必要があるから、どこかに書かなきゃいけないんだ。個人の好みの問題かもしれないけど、アーキテクチャの観点から見ると、どちらのアプローチも一長一短だね。- 「属性が少ない」という主張は、htmxの例がデフォルト値を持つオプショナル属性を使っているときには不公平に感じる。最初の例でhx-trigger="click"を外せるから、20%属性が減るし、その主張も20%弱くなる。- 小さいけど、ブログ記事がHTMLをもっと適切に使っていたら、信頼性が増して議論が強くなると思う。要素をクリックするために存在するものがあるんだから、ぜひ使ってほしい。アクセス可能だしね。;- 結局、Datastarの主な売りはクライアントサイドの機能の統合だと思う。AlpineやStimulusの機能がhtmxにネイティブに組み込まれているかのように感じる。それは素晴らしいポイントだね！

└

PharoのSeasideフレームワークをちょっと思い出すな。前の職場でPharoでプログラムしたことは、フロントエンドとバックエンドのやり取りが多かったから、バックエンドがフロントエンドの状態を管理してたんだ。レイテンシーの要件があまりないB2Bアプリにはいいと思うけど、スケーラブルなB2Cアプリには向かないかな。

└

「AlpineやStimulusの機能がhtmxにネイティブで含まれている」って言うけど、個人プロジェクトでHTMXを使おうか考えてるんだ。AlpineやStimulusみたいな他のライブラリが必要な理由を説明してるリソースってあるかな？

└

htmxを始めたばかりなんだけど、昨日Datastarに出会ったんだ。これはすごく良い比較で、私の印象を確認してくれてありがとう！もう少し調べてみるけど、もし主なポイントがAlpineやStimulusを単純に追加してるだけなら、Datastarは私には合わないかな。

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

└

PRO機能が必要だと思う？今見たら、オープンコアで299ドルのライセンスなんだね。パスするわ。

└

でも、これらのコードを正しく理解しているなら、記事が説明している「イディオマティック」なDatastarのことは実際にはやってないってこと？個々の要素を差分化したりパッチを当てたりせずに、ページ全体を再描画してるだけ？正直、そのメンタルモデルは、サーバーからの複雑なクライアント状態追跡がある他のDatastarの例よりもずっとシンプルに思える。こんな風に複雑なアプリを作ることもあるの？このシンプルなアプローチは、描画されるUIが比較的シンプルだからこそ機能してると思うんだけど、ユーザーが異なるページを移動する際に、複雑なウィジェットの状態を追跡して正しく再描画する必要がある「イミディエイトモード」アプローチについて読めるコンテンツはあるかな？

この投稿の例が理解できない。例えば、どうやって： こうなるの？ 他の例はさらに混乱する。結局、著者がHTMXからDatastarに切り替えた理由がわからない。

└

なんでボタンやリンクじゃなくてスパンなんだろう？

└

基本的に、HTMXのコードは「このスパンがクリックされたら、/rebuild/status-buttonを取得して、返ってきたHTMLから#rebuild-bundle-status-button要素を抽出して、既存の#rebuild-bundle-status-button要素と置き換える」って言ってる。一方、Datastarのコードは「このスパンがクリックされたら、/rebuild/status-buttonを取得して、指示されたことを実行する」って言ってる。だから、/rebuild/status-buttonが「既存の#rebuild-bundle-status-button要素をこの新しいものに置き換える」って指示を提供する責任があるんだ。もし/rebuild/status-buttonがID付きの要素をたくさん返したら、Datastarはそれを「既存の要素をこの新しいものに置き換える」って指示と解釈する。これのおかげで、ターゲットやセレクト、スワップの部分を明示的に指定しなくても済むから、結果的にコードがちょっとシンプルに見えるよ。要素にIDを付けるだけで、Datastarのデフォルトの動作が期待通りに動いてくれる（この場合ね）。

└

かなりシンプルだよ。Datastarはロジックをバックエンドに保つんだ。基本的なHTMLページでリクエストをしてサーバーがHTMLを返し、ブラウザがそれをレンダリングするのと同じ感じ。Datastarを使うと、基本的にPWAみたいなことをしていて、一度ページを読み込んだら、その後はインタラクションするたびにバックエンドにリクエストを送り、必要な変更をレンダリングするんだ。ページ全体を再読み込みする代わりにね。でも、戻ってくるのはHTMLのスニペットだから、ブラウザは自分自身をレンダリングするだけで済む。これによって、状態もバックエンドに戻るから、例えばSPAとは違うんだ。だから、Datastarは昔のリクエスト-レスポンスのHTMLモデルに戻るけど、それは全然問題ないし、有効で試された方法なんだよね。でも、JavaScriptを使ったときのように動的なレンダリングもできる。つまり、フロントエンドは純粋にビジュアルで、ロジックはバックエンドサーバーに委譲されるってこと。これは基本的にスリムクライアントとスマートクライアントの話で、常にバックエンドからフロントエンドにロジックを移動させたり、その逆をしたりしてるんだ。昔はスリムクライアントから始まって、コンピュータの処理能力が不足してたから、バックエンドサーバーがほとんどの重い作業をして、スリムクライアントはほとんど何もしなかった（基本的に準備された情報をレンダリングするだけ）。でも、時が経つにつれてコンピュータがより能力を持つようになって、フロントエンドにもっとロジックを移動させるようになった。それによって、サーバーからのレスポンスを待たずに、より速いインタラクションを提供できるようになったんだ。これが今日のJavaScriptが多い理由であり、SPAやクライアント側の状態がある理由なんだ。だから、Datastarはバックエンドでデータを処理するかフロントエンドで処理するかを選ぶ良い代替手段を提供してくれるし、動的なフロントエンドも保ちながら、すべてのページが再レンダリングされる基本的なリクエスト-レスポンスではなく、リクエストが完了するのを待たずに並行して処理できるんだ。まるで「ライブ」ページの印象を持ちながらね。

「とりあえず自分で考えろ」ってスタイルのドキュメントだけど、Hotwire + Stimulus（正直オプションだけど）が低JavaScriptリアクティビティの中で一番いいと思ってる。HtmxはHTMLの中にたくさんのロジックがあるから、なんか悪い感じがする。Datastarはこの点で良さそうだけど、Hotwireがとっくに解決した制限もあるね。

└

HtmxはHTMLの中にたくさんのロジックがあるから、なんか悪い感じがする。 HTMXを書いてみれば、実際にはその逆が真実だってわかるよ。

└

HotwireからDatastarに移った者として、その制限について聞きたいな。

「コードベースの70%を削減しました」っていう主張はいつも笑っちゃう。元のコードベースで何が起こってたか全然わからないからね。話の中には、まるで月まで伸びる呪われた行があって、例えばこんなのがある：<div hx-get="{% url 'web-step-discussion-items-special-counters' object.bill_id object.pk %}?{{ request.GET.url...どれだけ文字が長いのかもわからない。アプリを最適化したのか、ノイズをたくさん削除したのか、それとも300文字のメガラインに全部統合したのか、判断が難しいよ。

└

「バックエンドに戻る」という社会運動は、クライアントサイドのアプリケーションを別のコンポーネントとして排除することに関するものだよね。もちろん、それによってコードがかなり減るはず！でも、その代わりにしっかりしたAPIや別のクライアントサイドアプリケーションが持つ能力のほとんどを完全に捨てることになるけどね。で、これが起こっているのは、過去20年ほどで、クライアントサイドの自由さがあんまり価値がないってことがわかってきたから。ほとんどのクライアントは単純なデバイス（クローラー）だし、大半の「インタラクション」は原始的な読み取り専用のものだし、速くてシンプルなサイトが美徳になってる。経済的にも、ほとんどの複雑さをサーバーサイドに押しやるのが理にかなってるし、ユーザーの近くには速くて能力の高いPoPがあるからね。

└

「コードベースの70%を削減しました」っていう主張にはいつも笑っちゃう。私のトークにも、どれだけJSの依存関係を減らしたかを示すスライドがあるけど、新しいPythonは追加してないんだ。振り返ってみると、それがはるかに印象的な成果だよ。

2015年から2018年まではフロントエンドの仕事をしてなくて、再開したときにはみんながJSフレームワークを使ってMVCやaspxを捨ててた。今はまた3年間フロントエンドの仕事をしてないけど、みんながサーバーからHTMLを送る方向に戻ってるみたい。間違ってるとは言わないけど、振り返るとちょっと面白いよね、振り子が逆に動いてるのが。

└

Hacker NewsやTwitterで見えることが、みんながやってることじゃないよ。実際は、みんなまだレガシーアプリでReactをそのまま使ってる。

HTMXの大きな約束の一つは、クライアントが返されるデータの構造を理解する必要がないことなんだけど、プレゼンテーション層に事前にコンパイルされてるからね。でも、今は呼び出しページがサーバーから返される異なる要素のIDや意味を知っておかないといけないから、これがかなり違反してる気がする。まあ、これはDatastarに対する批判ではないけど、HTMXのOOBの人気は、純粋な形が多くの現実のケースには理想主義すぎることを示してると思う。両方の良いところを活かせるデザインが考えられたらいいな。

└

呼び出しページは何も知らないんだ。クライアントでアクションをすると、サーバーがページ全体の更新ビューを返すかもしれない。それだけ。変更のたびにページ全体を送信するんだ。クライアントはただレンダリングするだけ。まるでビデオゲームの即時モードみたいだね。