htmx、GitHub Open Source Accelerator の第1期に選出
(htmx.org)- htmx が第1回 GitHub Open Source Accelerator に選出され、成熟したオープンソースプロジェクトと協業し、学ぶ機会を得ることになった
- 今回の参加は、hypermedia と htmx のアプローチをより広い開発者コミュニティに知らせるきっかけとなる
- htmx は Accelerator の期間を活用して htmx 2.0 の作業を開始する計画
- プロジェクトの維持と開発を継続するために、htmx の作業を フルタイムの仕事 にする方法を学ぶことも重要な課題として残っている
- ともに選出されたプロジェクトは、セキュリティ、ドキュメント、認証、通知、CMS など多様なオープンソース領域を網羅しており、GitHub Accelerator の幅広さを示している
htmx が得る機会
- htmx が第1回 GitHub Open Source Accelerator クラスに選出された
- 今回の選出により、成功している オープンソース開発者とプロジェクト から学び、協業できるようになった
- htmx はこの過程を通じて、hypermedia と htmx をより広く知らせることができると見ている
- Accelerator 参加期間の主な目標は2つ
- htmx 2.0 の作業開始
- htmx の作業を フルタイムの仕事 にする方法の習得
ともに選出されたオープンソースプロジェクト
- BoxyHQ: セキュリティとプライバシーのための API 製品群で、エンジニアリングチームが規制に準拠したクラウドアプリケーションをより迅速に構築・展開できるよう支援
- Cal.com: メールのやり取りを何度も繰り返すことなく会議日程を調整できるスケジュールツール
- Crowd.dev: コミュニティ、製品、顧客データを一元化し、どの企業がオープンソースプロジェクトに参加しているかを把握できるよう支援
- Documenso: オープンソースの DocuSign 代替であり、セルフホスティングと内部動作の検証を通じて信頼を得ることを目指す
- Erxes: オープンソースの HubSpot 代替で、単一の XOS を通じてさまざまなビジネスタイプに合った体験を作れる
- Formbricks: ユーザージャーニーのどの時点でも細分化されたユーザーグループにアンケートを送ることができ、ターゲットを絞ったマイクロアンケートで最大6倍多くのインサイトを収集できる
- Forward Email: カスタムドメイン向けの無料メール転送サービスで、6年以上にわたりクリエイター・開発者・企業に利用されてきたメールサービス
- GitWonk: 開発者体験に焦点を当てて設計・構築されたオープンソースの技術ドキュメントツール
- Hanko: パスキー時代に向けたオープンソースの認証・ユーザー管理ツールで、Web およびモバイルアプリに数分で統合可能
- Infisical: チーム、デバイス、インフラ全体でシークレットと設定を安全に管理するオープンソースのエンドツーエンド暗号化プラットフォーム
- Novu: 開発者向けのオープンソース通知インフラで、すべてのコミュニケーションチャネルを一元管理するコンポーネントと API を提供
- OpenBB: オープンソースの金融エコシステムを通じて投資リサーチを民主化し、OpenBB Terminal によってどこからでも投資リサーチを行える
- Sniffnet: インターネットトラフィックを簡単に追跡できるよう支援するネットワーク監視ツール
- Typebot: 独自のチャット体験を作るためのブロックを提供し、アプリのどこにでも埋め込んで結果を収集できる
- Webiny: データ所有権、拡張性、カスタマイズ性を重視したオープンソースのエンタープライズ級サーバーレス CMS
- Webstudio: Webflow のオープンソース代替として選出された
1件のコメント
Hacker News の意見
こんにちは。多くの方がご存じの通り、私は htmx の作者で、関連する質問に答えられます
htmx は fireship dev の動画（https://www.youtube.com/watch?v=r-GSGH2RxJs）と、人気 Twitch ストリーマー ThePrimeagen の動画シリーズをきっかけに大きく人気が高まりました
HN 読者なら、htmx とハイパーメディア全般について私が書いた記事集 https://htmx.org/essays も興味深いかもしれませんし、最近何人かの著者と出した、ハイパーメディア、htmx、モバイル向けハイパーメディア Hyperview に関する本 https://hypermedia.systems も読む価値があります
当然ながら私は htmx のファンですが、より深い核心は ハイパーメディア にあると考えています。日々の開発で htmx を使う予定がなくても、探求する価値のある概念です
37signals の Hotwire や、htmx の次に私が好きな https://unpoly.com のような、優れたハイパーメディア指向ライブラリもたくさんあります
多くの Django 開発者 にとって大きな助けになります
数か月前に記事の「いいね」機能を作ったとき、htmx 以前なら jQuery で JSON API サーバーを呼び出して「いいね」数を更新する必要がありましたが、HTMX を使うと Django のロジックと一緒に、ただ普通の HTML を書いているような感覚でした
これまで見つけた中でも最高レベルのもので、フォーム処理 も非常に簡単です。HTMX はユーザー体験と開発者体験の両方を大きく改善してくれます
非常に人気のあるプロジェクトでも、通常は既存のコントリビューターがコードの大半を担うことを考えると、これは強い成長シグナルです
https://devboard.gitsense.com/bigskysoftware/htmx
ちなみに、これは私が作ったツールです
Web サイトと例を少し見たところ、サーバーの HTTP レスポンスが完全なマークアップを含み、それを基にクライアントの状態を更新する方式、つまり DOM の書き換えに重きが置かれているようです
htmx がクライアント専用のトリガーや、クライアント生成コンテンツにも折衷案を提供しているのか気になります
現在の JavaScript 中心のクライアントフレームワークの利点は、できるだけ多くの仕事をブラウザに渡して、サーバーのデータ・CPU 使用量を減らせる点にあります。Web 規模のアプリでは大きな違いです
HTMX がこうしたエンジニアリング上の目標も満たせるのか、それともまったく別の目的のプロジェクトなのか気になります。Facebook のようなクライアントがハイパーメディア指向ではないことは理解していますが、それでも比較は避けにくいでしょう
自然で、自己文書化されているように感じられ、よく設計されています。本当に HTML の自然な拡張のように感じます
私にとって htmx に唯一欠けているピースは コンポーネントモデル ですが、そういうものを探している人には Astro[1] と非常に相性が良さそうです。Astro は Vue や React のようなランタイム負荷なしに、HTML コンポーネントを定義して使えるようにしてくれます
[1] http://astro.build
Htmx は Tailwind を思い起こさせます。実行時に1つのライブラリが読み取る属性名と値を作った、ということだからです
フロントエンドのビルドが不要であることは、npm や webpack に触りたくなく、触る必要もない大半の開発者にとって 非常に大きな利点 です
ページサイズの限界点は小さなシングルページアプリ程度に見え、大きくなりすぎたらまた別のシングルページアプリに分ければよさそうです
React/Vue 開発者が特に物足りなく感じる部分は、グローバル状態を表す単一のオブジェクトがあり、それをコンポーネントコードベースに階層的に定義された1つの関数が UI にレンダリングする、という見方でしょう
ただし、この見方自体も負担が大きく、多くの見解の違いや感情的な消耗を生み、フロントエンドのビルドとその混乱したバリエーションまで一緒についてきます
私はまだ使っていませんが、すでに大ファンです
良いニュースです
この1年間 htmx を使って、良い成果とやりがいのある経験を得られました。Clojure で hiccup を使ってサーバーサイドレンダリングする場合は特に素晴らしかったです
htmx は一度理解すると、そのシンプルさと柔軟さにほとんど驚かされます。HTML がなぜハイパーメディアとしてこのように進化しなかったのか、信じがたいほどです
Web 開発は本来このように進化すべきだったのだ、ということが非常にはっきりします。いつか htmx が JavaScript で行っていることが、そのまま HTML とブラウザクライアントに組み込まれることを願っています
htmx を Angular の派生物程度に誤解していたり、ハイパーメディアアーキテクチャを発展させた意味を理解していなかったりするなら、サイトにある素晴らしい記事をぜひ読んでみることをおすすめします。そうすれば REST とは何か、本当の HATEOAS がなぜ重要なのかが理解できます: https://htmx.org/essays/
無料の本もあります: https://hypermedia.systems/
10〜15年前、私たちは初期の Web の新しく強力なアイデアだったハイパーメディアを拡張し豊かにする代わりに、JSON API アーキテクチャで Web の上に厚いクライアントを作り直そうとして、コストの大きい誤った道に入ってしまいました
htmx が存在し、多くの人にうまく合っているのはうれしいですが、私の仕事ではそれが最善である場合は多くありませんでした。それでも問題ありません
Web がさまざまな形で成長できたのは素晴らしいことで、Web が必ず何か一つの方向へ進化すべきだったと見る必要はありません
ここ10年ほどの Web 開発における最大の失敗は、唯一の正解があるはずだという考えでした
次の Gmail を作るにせよ静的ブログを作るにせよ、業界のカーゴカルトはすべて同じやり方でやるべきだと言いますが、常識的に考えればそうではありません
Web の98%以上には十分なはずです。残りの1.9%には小さな JavaScript ライブラリを使えばよいでしょう
残りの0.1%だけが純粋な JavaScript Web アプリです
HTML に属性を少し散りばめて、簡単なケースを動的にするという同じアイデアに見えます
Angular 1、Vue など多くのフレームワークはこのように始まり、ある程度人気を得た後、より難しいケースに対する実際の需要によって、完全なシングルページアプリフレームワークへと大きくなりました
「Angular 1 のような」フレームワークを選ぶなら、境界を明確にドキュメント化し、その境界を越える必要があるときに成熟したシングルページアプリフレームワークを使う道筋をはっきり提供しているものを選びます。そういうフレームワークを知っている方がいれば共有してください
私は HTMX が「かっこよくなる前から」のファンでした
最近の注目と成功はとても喜ばしく、Web は2013年に発明され、自分たちがその街を作ったと信じているフロントエンド方面から出てくる冗談交じりの嘲笑や反発も、かなり楽しんでいます
Backbone.js の時代から偏見はあって、当時も苦痛の一部は理解していましたが、ある程度は懐疑的でした
その後 React が登場し、若くエネルギッシュな人たちが5ページ程度のごく単純なWebサイトを、フロントエンドフレームワークのルーブ・ゴールドバーグ・マシンに仕立て始めたので、私は技術チップを現金化して、そういうものには触れませんでした
実装の詳細はかなり違いますが、ハイパーメディアベースのアプリケーションというアイデアが、私たちのやっていたすべての中核でした
残念ながら長期的には人々の心をつかめず、ブログ駆動開発、つまりカーゴカルトが私たちの努力に取って代わりました
今 HTMX の人気が高まっているようで、ある程度報われた気持ちです。こうした概念で考えていたのが私たちだけではなかったと分かるのはうれしいです
もちろん、概念が強かったのだとすれば、私の実行が足りなかったという意味かもしれないので、あまり喜びすぎないほうがいいのかもしれません
バンドがギターを売ってターンテーブルを買ったという話も聞きました
HTTP エンドポイントが JSON を返すように書き直したら、それが REST だったという話も聞きました
バンドがターンテーブルを売ってギターを買ったという話も聞きました
HTTP エンドポイントがテンプレート化された HTML 断片を返すように書き直したら、それが HATEOAS だったという話も聞きました
私は勘を失い、取り戻し、また失い、また取り戻しているところです
ただ Backbone は少し緩く、Angular が出てくるまでは、あまりエンタープライズ向けっぽくはありませんでした
ともあれ、このようなWebアプリケーションの流れが私の周囲で人気を得た理由は、バックエンドとフロントエンドを分離し、1つのバックエンド、たいていは REST/JSON がモバイルとWebクライアントをそれぞれ支えられたからです
それが私たちがシングルページアプリを作った理由でしたが、今ではまた忘れられているようです
私の世界では、ログインの背後にあるアプリなら理にかなっていました。ところが「彼ら」は、Webショップのようなインターネットに公開されたサイトまでシングルページアプリにしたがりました
それも理解はできます。Gatsby でいくつかWebサイトを作ってみましたが、ナビゲーションは信じられないほど速いのに、検索エンジンにもインデックスされます
ただ、場合によってはますます複雑になり、サーバーサイド React のようなものまで出てきました。幸い、私はそれに触る必要はありませんでした
一方で、htmx、より一般にはハイパーメディアがツールとして受け入れられることを望んでいます。有用ですが、結局はツールにすぎません
しばらくハイパーメディアについて深く考えてこなかったフロントエンドの人たちにも、そう受け止めてもらえればと思います
2つのアプローチが互いに排他的だとは見ておらず、Rich Harris の Transitional Web Applications という概念、つまり2つのアプローチを混ぜるやり方に賛成しています
ただ、ハイパーメディアを捨てて、より精巧なクライアント側のアプローチへ移る線引きについては、私と彼とで位置が違うだけです
私は確かにそう思っています
1996年にPerlから始め、PHP、jQuery、Drupal、Backbone、Node、Angular、ClojureScript、React、GraphQL、NextJSに至るまで、ほぼすべての潮流を経験してきました。
Htmxはその流れから外れた分岐のように感じられ、考えてみる価値があります。
Htmxは良い問いを投げかけます。「あなたの作業の複雑さは、本質的にサーバー側にあるのか、クライアント側にあるのか？」
ほとんどのWebサイトでは、複雑さは本質的にサーバー側にあります。私たちはたいてい、FigmaやGoogle Sheetsを作っているわけではありません。多くのWebサイトは、インタラクションが多くても、見栄えの良いインターフェースを備えたCRUDアプリにすぎません。
NextJSのようなフレームワークは、Reactをサーバーへ移すことで過度に複雑なクライアント側の問題を正そうとしますが、複雑さを減らすよりも増やしてしまうことがよくあります。
それなら、スタックからReactを外すのが正しいのではないでしょうか？ 複雑なクライアントなら、DOMとJavaScriptを飛ばしてcanvasとコンパイル済みWebAssemblyを使えばよいのです。複雑なサーバーなら、サーバー主導の細かなDOM更新を使えばよいのです。
このアプローチで見えてくる問題は、ほとんどのWebサイトの複雑さがサーバー側にあるとしても、ほぼ必ずクライアント側に置くべき高複雑度の処理がいくつかあるという点です。画像編集、リアルタイムのソート・フィルタリング・計算、ドラッグやタッチジェスチャーなどがそれに当たります。
ハイブリッドアプローチが必要です。単に互換性があるだけでは不十分です。htmxとReactを同じWebページで使うことはできますが、互いに分離しなければなりません。私が望むのは分離ではなく、根本的な統合です。
理想的なフレームワークは、DOMに対するリアクティブで細かな更新をサポートしつつ、複雑なクライアント側処理を担うコンパイル済みWebAssemblyと緊密に統合されているべきです。
私はすべてのコードを、JavaScriptではない強力な言語で書きたいです。デバッガーはサーバーとクライアントの両方を扱えるべきで、その違いは消えるべきです。本当のフルスタック開発、つまり単一スタックアプリケーションであるべきです。
Clojure + ClojureScriptは単一スタックアプリケーションに近く見えますが、表面的にそう見えるだけです。
Common Lispにキラーフレームワークが登場するなら、単一スタックアプリケーションにぴったりだと思います。
ハイブリッドアプローチは、Astroが主張するアイランドアプローチです: https://docs.astro.build/en/concepts/islands/
このアプローチはhtmxやその仲間たちと相性がよく、私たちはhtmxプロジェクトで、インタラクションが必要な部分にシンプルなバニラJavaScriptを添えて使っています。
小〜中規模のプロジェクトや小さなチームには、この程度で十分かもしれません。開発者ツールを開いてページの一部を指し示し、HTMLと小さなJS片だけを見ればその部分をすべて理解できるというのは、本当に新鮮です。
サーバーでもクライアントでも、C#で同じやり方でコーディングします。最初のページ読み込み時にはすべてサーバーサイドでレンダリングし、その後WebAssemblyが段階的に引き継ぎ、サーバーデータを必要としないUIインタラクションを高速化するために、クライアントへC#コードをロードし始めます。
うまく動作しますが、現在の課題はWebAssemblyファイルのサイズを小さくすることです。今は数MB規模です。
https://visualstudiomagazine.com/articles/2023/04/20/blazor-...
おめでとうございます。Htmxで小さなプロジェクトを作るのは楽しかったのですが、結局openlayersを多用することになり、別のものを選びました。
地図ライブラリはクライアント側JavaScriptが重いことで知られており、その作業にはSvelteのほうが優れたツールでした。
今後Golangプロジェクトでまた使う予定で、発展を見守りたいと思っています。
アプリに単純または中程度の複雑さのフロントエンドが必要で、特にすでにテンプレートフラグメント[0]を使っているなら、HTMXをぜひ試してみることをおすすめします。JavaScriptの世界から来た立場でも、作業はかなり楽しいです。
それにTwitterアカウント[1]の運営者が本当に面白いです。
[0] https://htmx.org/essays/template-fragments/
[1] https://twitter.com/htmx_org
htmx を現代的な Web アプリやサイト構築ツールとして真剣に受け止めるのは難しいです。ユーザーが期待するようになった機能を作るのを不可能にしているように感じます
たとえば、日付を「以前・間・以後」でフィルタリングしつつ、ユーザーが望むときだけフィルターを表示する ファセット検索や、結果画面を別のカラム、地図、チャートのように canvas に描画するビューへ切り替える機能などです
htmx でも一部はできるでしょうが、どこかの時点で結局 JSON が必要になるはずです
Angular でもこうしたことはできますし、SolidJS のようなものを使えば実際かなり楽しく作れます
JSON API は他のアプリでも再利用できますが、htmx は誰かが Thymeleaf を再発明したように感じます
私も同じ考えでしたが、この動画では ファセット検索を htmx でどう実装したのかを具体的に扱っています
2つ目の部分は、おそらく JavaScript を直接書くか、hyperscript で処理することになるでしょう
実際に作って本格的に使ってみないと良い方法かどうかは分かりませんが、確かに相性のよいシナリオも思い浮かびます
JSON API に関する指摘は妥当です。公開 API が必要なら意思決定に反映すべきです。ただし、すべてのプロジェクトがその制約を持つわけではありません
スマートフォンでも千行のテーブル検索にはまったく問題ありません
このような場合は、htmx でユーザーに広い範囲のデータを渡し、その後のより細かなリアルタイムフィルタリングは JS で許可するでしょう
最初に表示されないデータまで検索可能にしたいなら、非表示用の CSS クラスを付けて一緒に返し、検索にヒットしたらそのクラスを外せばよいです
htmx も他の技術と同じく、特定の問題群に非常によく合います。苦手な曲芸を無理にさせなければ大丈夫です
こういうものは、全面的なスクリプティングがある程度必要になるほど複雑ですが、私はそれ自体に反対していません
https://htmx.org/essays/hypermedia-friendly-scripting/
私のキャリアの紆余曲折のおかげで、フロントエンド JavaScript フレームワーク戦争をほぼ飛び越えてきたのですが、そのため 昔ながらの普通の HTML が強化されて戻ってくるのを見るのはうれしいです
これは グレースフルデグラデーションの観点では後退です
htmx で作られた印象的な事例が必要だと思います。新しい種類の Web 体験を切り開く「made with htmx」の例があるとよいです
人々は htmx を「本格的な武器」を持ち出すほどではない単純なユースケース向けだと固定観念で見ています
ある程度は一理ありますが、限定的です。htmx に関連する サーバーへ戻るアプローチは、さまざまな理由でこれまで十分に探究されてこなかった別のカテゴリーです
HTMX はバックエンドに依存しない形で 古いアプリのカテゴリーを復活させるものです
新しいことや「新しいアプリのカテゴリー」を正当化するようなことをしているわけではありません
ショッピングカタログ、フォーラム、管理画面フロントエンド、ブログのようなハイパーメディア、つまりコンテンツ中心のサイトを作る方法です
jquery/liveview/turbolinks と似ていますが、バックエンドに依存せず、フロントエンドの JS ロジックを多く、あるいはまったく保守する必要がありません
Google Docs や Figma のような重いインタラクションが必要になると、htmx がもたらす利点は大きく減ります
https://htmx.org/essays/a-real-world-react-to-htmx-port/
HTMX と Hyperscript で書かれた EC フロントエンドです
https://www.makaron.cz/
TodoMVC の HTMX フロントエンドは作れるでしょうが、バックエンドには何を使うのでしょうか？ Go、C#、Rust などいくつかの選択肢は自然に見えますが、常に状況次第です
C# に言及するのは、ASP.Net MVC + Razor が HTMX パラダイムにとてもきれいに合っているように見えるからです
彼らとは何の関係もありませんが、htmx と、より複雑な機能のための一部 JS で作られています
htmx が明示的に古き良きアプローチを拡張することを目標にしている点を考えると、「新しい種類の Web 体験」を提供できるかどうかはよく分かりません
最初は htmx が良さそうに見えますが、ドロップダウンボタンのように、普通なら JavaScript（バニラでもフレームワークでも）で作るようなものを作ろうとすると、結局 hyperscript を検討することになります
そうして例を見ると、コードの中に文章のようなものが入っている見た目が気に入らず、別のものへ移ってしまいます
htmx を hyperscript なしで 使ってみるべきなのかもしれませんし、hyperscript にもう少し時間をかけるべきなのかもしれません
ただ、数年間保守することを考えるとあまりにも馴染みがなく、後で二度と使わなくなった場合にそこへ縛られたくはありません
htmx 側は、どのクライアント側インタラクション用ツールを使うかをまったく気にしないので、htmx が有用かどうかとは別の問題です
個人的には JS ビルドツールなどを避けようとするなら、htmx + Alpine.js を選びます
規模が大きくなり複雑になったら、どうやって対処するのでしょうか？
htmx を使っているアプリケーションを手伝ったことがありますが、問題が2つありました。同じような経験があるのか、技術の使い方を間違えたせいで起きた問題なのか、それともこれを解決する取り組みが進んでいるのか気になります
1つ目は、エンドポイントがページ全体の HTML を返すべきか、htmx が必要とする断片だけを返すべきかを判断するために、コントローラーにカスタムミドルウェアが大量に必要だったことです
htmx 側では単純に見えますが、おそらく htmx を使うすべてのプロジェクトが作り直さなければならない部分でしょう
2つ目は、
hx-trigger周りの帳簿管理が必要だったことです。UI が複雑になると、多くの要素が外部の変化に反応する必要があります何らかの状態を読み取ってフレームワークが更新をスケジュールしてくれることを期待する代わりに、反応すべきイベントのリストを自分で管理しなければなりませんでした
同じように感じた方はいますか？