HN紹介: ブラウザで100%実装されたHTMX Playground

 (lassebomh.github.io)
6 ポイント 投稿者 GN⁺ 2024-01-09 | 1件のコメント | WhatsAppで共有
  • インストールやローカル設定なしで、ブラウザ内でHTMXの実験をすぐに始められるコードサンドボックス
  • server.jsでエンドポイントとテンプレートレンダリングを扱い、HTMXのリクエストはブラウザ内のモックサーバーが横取りする
  • リクエスト処理とテンプレート方式はDjangoユーザーになじみがあり、HTMX以外のライブラリ実験にも活用できる
  • 共有は「Copy as JSON」で書き出した後、Gistのraw URLを「Load Playground」に入れる方式で行う
  • ページナビゲーションの不在、限定的なモバイル対応、初期iframe読み込みによる on.get("/") の状態更新の消失に注意が必要

ブラウザ内で動作するHTMXサンドボックス

  • HTMX Playgroundは、HTMXをインストールなしで試せるシンプルなコードサンドボックス
  • 元の htmx.org examples をアレンジしたサンプルを提供する
  • ブラウザ内でバックエンドに近い流れでコードを書ける
    • server.js 内で エンドポイント を定義する
    • テンプレートを直接レンダリングできる
    • HTMXから出るリクエストを横取りするモックサーバーが動作する
  • リクエスト処理とテンプレートエンジンはDjangoユーザーにとってなじみ深い形
  • プロジェクト自体はHTMXだけに限定されず、ほかのライブラリも試せる
  • コードは GitHub で公開されている

保存・共有方法と既知の制約

  • 保存と共有

    • 右上の「Copy as JSON」を押して内容をコピーする
    • コピーした内容をGistにアップロードする
    • raw URLを「Load Playground」に入力する
    • ページURLが更新されると共有できる

  • 制約事項

    • ページナビゲーションはない
    • モバイル対応は限定的
    • server.js は Click to Edit の例のように状態を持てる
    • on.get("/") ビューで状態を更新すると、その更新は失われることがある
      • 初期ページ読み込みが、画面のiframeを更新する前に別のiframeで先に取得されるため

  • 使用ライブラリ

    • Svelte
    • Ace
    • PollyJS
    • Nunjucks

関連記事

1件のコメント

 
GN⁺ 2024-01-09
Hacker Newsでの意見

  • htmxを作った者だが、これを作ってくれて本当にありがたいし、とても素晴らしいと思う

    • HTMXをサーバー側の変更を最小限にして使う方法があるのか気になる
      既存ページでフォームに入力して送信すると、レスポンスはページ全体として返ってくるが、htmxに「ページ全体が返ってくるが #my-form だけを更新せよ」と伝えられれば、サーバーに「htmxリクエストなら」といった分岐を入れなくて済みそう
      JavaScriptなしでもサイトが動作してほしい人にとって良く、コメント、メール購読、いいねボタンのような複数の機能を1つのバックエンドエンドポイントで処理することもできる
    • Phoenix LiveViewを聞いたことがあるか、htmxと似たコンセプトなのか気になる

  • HTMXを本格的に使ってみようかと思ったが、開発者プールが小さすぎて採用が難しくなるのではないかと心配
    Intershopのismlのように、Thymeleafに似たプロプライエタリなフレームワークに慣れていて、最近は専任のフロントエンド開発者を採用しやすいのでAngularのフロントエンドスタックへ移行しようとしていた
    htmxのような方式は複雑になり得るし、開発者はスパゲッティモンスターと戦いたがらず、フロントエンドがHTMLだけを作りバックエンドがすべてつなぎ合わせる必要があるなら、バックエンド開発者がボトルネックになり得る
    HTMXがこうした落とし穴を考慮しているのか、どう対応しているのか気になる

    • htmxは学ぶのが非常に直感的なので、Reactだけを学んだコーディングブートキャンプ出身者でなければ、実際の計算機科学のトピックを知っている開発者なら最長1週間以内に生産的に働けると思う
    • 対応方法は簡単で、HTMXは学ぶのに半日もかからず、おそらくもっと速い可能性が高い
      ただしHTMXがすべての状況を解決するわけではなく、JavaScriptフレームワークを使うシングルページアプリが必要な場合もある
    • Angularに言及した後でhtmxが複雑になり得るという話は興味深く、複雑さに対する見方が違うようだ
      Angularのようなフレームワークは構造を与えるが複雑さはそのままで、おそらくはるかに大きくなり得る
      結局必要なのはJavaScript、CSS、HTML、ブラウザーAPIといったWebスタックをよく理解しているフロントエンド開発者であり、そういう人なら作業に合ったツールやフレームワークを選べるし、HTMX程度ならすぐ習得する
    • 成功ほど説得力のあるものはなく、htmxは2023年のJS Rising Starsでフレームワーク部門2位に入った
      https://risingstars.js.org/2023/en#section-framework
      Reactのすぐ後ろで、Vue、Svelte、Angularより上なので、その点では将来は良さそうに見える。ただし初期の熱狂が落ち着けば順位は下がると予想している
      htmxはかなり単純なので、ほとんどのWeb開発者は1日程度で習得できるが、開発方式として機能全体を開発者が所有するフルスタック・パラダイムの方向へ組織を押し出すため、開発者だけでなくPMやアーキテクトにも考え方の転換が必要になる
      無料のオンライン書籍もある: https://hypermedia.systems
      ドキュメント（https://htmx.org/docs、読むのに1時間程度）に加えて、htmxとハイパーメディア全般の哲学的・実用的な問題を扱った文章もある: https://htmx.org/essays
      htmxは基本的なアイデアが非常に少なく、遅延読み込みのような有用な動作も属性2つで実装できるため、「拡張可能」になるよう作ろうとしている: https://htmx.org/examples/lazy-load
      同時にイベントやイベントフィルターのようなフック、さらに深い機能もあるので、掘り下げれば望む動作を実装できる
      スパゲッティコードはあらゆるソフトウェア開発で常に存在するリスクであり、シングルページアプリのライブラリがスパゲッティを防いでくれるという確信は個人的には持てなかった
      htmxでは労力をバックエンドに集中し、サーバー側の環境が提供するツールでアプリケーションをうまく分解するほうがよい
      htmxはどのサーバー技術も選べるようにしてくれるため、フロントエンドにすでに大きなJavaScript/TypeScriptアプリがありバックエンドもそちらに寄せざるを得なくなるシングルページアプリより、アプリケーションロジックを組織する選択肢やパラダイムが多い
      htmxがどのようなアプリケーションに適した選択なのかも、ここで整理しようとした: https://htmx.org/essays/when-to-use-hypermedia/
      htmxは多くの場合良いツールだが、あくまでツールにすぎず、Web開発の万能解決策ではない
    • 採用ではHTMXの経歴よりもバックエンド能力を見るのに近い
      少しフロントエンドもできるバックエンド開発者を採用するようなものなので、履歴書にHTMXがある必要はなく、JavaScriptのような基本があればよい
      Web開発者の大半はその条件に当てはまる

  • MapLibreをDjangoとhtmxと一緒に使ってきたので、他の人と共有できるように例を上げてみるつもり

    • 自分も似たように https://ratethispad.com を作ったし、作る過程はかなり楽しかった
      誰も使ってはいないが、そのプロジェクトも見てみたい
    • 公開して共有できるものはないが、Django, htmx, SQLAlchemy, Plotlyで作業してきて、かなり堅牢だと感じた
    • 公式例をもっと移植したければ、リンク付きでissueを作ればリポジトリに追加できる

  • Monacoは設計上モバイルでは動作しないため、モバイルではAceを使うと理解している
    少なくとも最後にGitHub issueを確認したときはそうだった
    [0] https://github.com/Microsoft/monaco-editor/issues/246

  • これ、ActiveXにも対応しているの？

    • このジョークが理解できるほど年を取ったという事実が悲しい
    • HP Quality Centerを思い出した
      初期バージョンはUI全体がActiveXで、DLLをインストールする進捗バーが大量に表示されていた記憶がある

  • Service Workerを使ってこういうものを作り、別タブに複数ページを開いて探索できるようにもできる
    それほど難しくはなさそうだし、ページ生成には純粋なJavaScriptでも、ユーザーが望むものなら何でも使える

  • Svelteで作られているというのに、MPA純粋主義者たちと熊手はどこへ行った？

    • MPA純粋主義者ではあるが、シングルページアプリが最善であるアプリケーションの種類があることも十分認めている

  • htmxの考え方が気に入って今日から本を読み始めたが、いつかネイティブモバイルアプリにも対応しなければならないと思うたびに、使うのをためらってしまう
    その場合、フロントエンドだけでなくバックエンドのかなりの部分も書き直す必要がありそう
    hyperview.orgは知っているが、関心のあるユースケースではReact Nativeアプリでは不十分

  • Service Worker内に定義した仮想サーバーとHTML/HTMXのリクエスト・レスポンス方式でオフラインアプリを作っている人がいるのか気になる

    • いい質問
      htmxは好きだが、オフラインでも動作しなければならない状況では使えなかった
      サーバーコードをワーカー内でそのまま実行できれば、素晴らしいハックになりそう
    • ブラウザの横でローカルサービスとして実行されるhtmx向けのサーバー/バックエンドを作っている
      理論上、セルフホスト可能なサーバースタックなら何でも可能
      目標は外部サービス依存のない単一バイナリを作ることで、Goを使っている
      自動更新するローカルサービス、複製データベースのような構成要素はすでにかなり用意できており、複数のOSやアーキテクチャ向けにクロスコンパイルするのも簡単
      すべてをブラウザに入れる代替案として、別プロセスを実行できるという前提なら、このアプローチはかなり妥当に見える
      ただしGoにもDenoのような権限管理があるとよい
    • 実際の例がある: https://github.com/jon49/htmx-todomvc
      個人用アプリでは全部このパターンを使っていて、ただし自作の小さなhtmx風ライブラリを使っている
      HTMXに置き換えるのもそれほど難しくはなさそう

  • HATEOASをデスクトップやモバイルアプリ側へ持ち込んでみるのは良いアイデアなのか気になるし、面白い実験になりそう

    • ネイティブモバイルのことなら、2013年ごろにネイティブコードでHATEOASを使ったことがある
      動作はするがWebほど柔軟ではなく、リンク可能な各画面を厳格なブラックボックス方式で開発する必要がある
      試み自体は面白かったが、本番環境で使う価値がどれほどあるかははっきりしない
    • HATEOASは抽象的な概念としてしか見ておらず、実際のUIで「ユーザーインタラクションが本当に良くなった」と感じたことはない
      RESTはSOAPの怪物たちを単純化してくれたので歓迎したが、かなりの教条主義も伴っていた
      RESTがユーザーにとって自然な概念、データ、サービスアーキテクチャに合わせるものだという根本的な目的は理解している
      しかしHATEOASは、モデルのおかげでユーザー体験が良くなるかに集中するより、アーキテクチャ会議でより多くの教条主義と虚勢を求めた結果のように見えた
      HATEOASを基本原則にすべき理由を示すUIの例があるのか気になる
      基本的に各ページには「次にすること」へのリンクがあり、HATEOASはそうした状態モデルをRESTサービス呼び出しに持ち込もうとする、きらびやかなやり方のように感じる
    • そもそもHATEOASが良いアイデアなのかが気になる
    • ここにある: https://hyperview.org/