Game Boy専用で発売される初のJavaScriptライブラリ、htmx 4.0

 (swag.htmx.org)
1 ポイント 投稿者 GN⁺ 1 시간 전 | 1件のコメント | WhatsAppで共有
  • htmx 4: the gameは、携帯型Game BoyでHTMXを体験できる25ドルのゲーム
  • 全4レベルを巡りながらピクルスを集めて進行する
  • クライアント側JavaScriptを最小限にし、slopを避けることが主な目標
  • 最後にWarrenを倒すと、htmx 4.0のソースコードをアンロックできる
  • 受注生産品のため、印刷ミスや目に見える品質上の問題は交換・返金対応となるが、通常返品やサイズ関連の返品は受け付けない

Game Boyで出会うhtmx 4.0

  • htmx 4: the gameは、携帯型Game BoyでHTMXを体験できるように作られたゲームで、価格は25ドル
  • 4つのレベルでピクルスを集めながら、クライアント側JavaScriptを小さく抑え、slopを避けなければならない
  • Warrenを倒すと、htmx 4.0のソースコードがアンロックされる

品質保証と返品条件

  • 印刷ミスや目に見える品質上の問題があれば、製品を交換または返金する
  • 受注生産品のため、通常返品およびサイズ関連の返品は受け付けない

関連記事

1件のコメント

 
GN⁺ 1 시간 전
Hacker Newsのコメント

  • htmxを3年間使っていて、サーバーサイドのテンプレート言語と組み合わせることで、Webソフトウェアを作る新しいやり方を見つけた
    さらに印象的なのはショップ運営者の対応力だ。以前、8オンスのマグは小さすぎるとTwitterで不満を言ったら、翌日に48オンスの超大型マグが追加され、その後は毎日そのマグを使っている

    • 学術・学会運営のような比較的ニッチな用途のWebサイトをたまに開発する程度だが、HTMXの速くてシンプルなやり方に魅了された
      JavaScript中心の配信の肥大化なしに、訪問者の負担が少ないレスポンシブサイトを素早く作れ、互換性の問題や障害点も減り、Googleの速度スコアも60〜80から100に上がった。デバッグもしやすくなり、JavaScriptに浪費していた時間をデザインや機能改善に回せるようになった
      ユーザーの同意なしに任意のWebサイトがユーザー端末で重い演算や分析を実行する慣行は、そもそも許されるべきではなかった
    • 3〜4年前にサーバーサイドテンプレートとhtmxを導入し、B2B SaaSのJavaScriptの3分の2を削減したが、はるかにシンプルになった
      Webアプリを作るシンプルなやり方に戻ろうという哲学に共感する
    • HTMXのバックエンドとしてAWS Step Functionsを使い始めたが、難しい一方で楽しい
      最近のStep Functionsは奇妙で荒削りなテキストテンプレートエンジンのようにも使えるので、その不便さを整えるDSLレイヤーを考えている
    • htmxでプロジェクトをもう1つリリースしたが、このレベルの開発速度に勝つのは難しそうだ
    • 1.25リットルはヨーロッパ人の感覚ではマグではなくバケツだ

  • HTMXの雰囲気が素晴らしい。技術的に優れていてシンプルで、さまざまな状況で役に立つが、自分たちを必要以上に深刻に捉えていない
    intercooler.jsの時代から仕事と個人プロジェクトで使ってきたが、今でも好きだ。NROL-39を思わせる狂気じみたユニコーンのレーザーアイのマグも気に入っている: https://swag.htmx.org/collections/octohorse, https://en.wikipedia.org/wiki/USA-247

    • NROL-39のミッションパッチは特に好きなデザインだ。承認文書の手書きメモを探して読んでみると、とても笑える
    • 長い間HTMXに反対していたが、Claudeが簡単なプロジェクトで使っているのを見て、Reactにも疲れてうんざりしていたこともあり、今ではかなり良く見える

  • Big Sky Dev ConでGame Boyゲームが公開された瞬間、エミュレーターを使ったごまかしだと思ったが、全員が実物のカートリッジを持ち帰れると言われて口があんぐりした
    これまで見た販促イベントの中でも特に楽しい部類で、HTMXチームがあらゆる仕事で完成度と楽しさをどれほど重視しているかをよく示している

  • HTMXが好きでいろいろなプロジェクトで使っているが、古いものが再び新しくなる現象が面白い
    .NET FrameworkのWeb Formsは、すでに2005年にUpdatePanelでWebページの一部レンダリングをサポートしており、.NETの外では多くの批判を受けていた。HTMXは、ある意味でそれをはるかに洗練され強力に拡張した形だ

    • そのやり方自体も、C#の先祖格であるDelphi IntraWebがDelphi 7の時代から提供していた解決策を受け継いでいるとも言える
      ピクセル単位で合わせたPSDをHTMLテーブルやFlashアプレットに移していた時代には、スタイリングとの両立が難しく、この概念は消えていったが、古いIntraWebの業務アプリを見ると、コンポーネントやイベントなどを流行するずっと前にすでに解決していたことがわかる
      現代のWebスタック向けRADツールがまた出てきてほしいが、変化の速度が速すぎるうえ、今やフロントエンドとバックエンドが分かれた専門分野なので、投資する価値は低そうだ
    • HTMXは昔LAMPスタックでWebサイトを作っていたやり方に似ているが、開発体験はより良い
    • React、Angular、Vueのフロントエンドを10年間開発したあと、伝統的なサーバーサイドレンダリング方式であるRuby、Elixir、さらにはPHPに戻ると、むしろ自然に感じる
      AIのおかげでPHPのような見た目の悪い言語ともやり取りしやすくなり、深いエコシステムと実行速度、非常に短いビルド時間を活用できる。PHPの文法と静的型の欠如は嫌いでも、SPAだらけの環境より生産的だ
      リロードなしでアプリのような体験を与えるというクライアントサイドレンダリングの大義名分は、実際には2010年代の論理であり、Webとブラウザー技術はすでに大きく進歩している

  • ホームサーバー上の複数のオープンソースWebアプリをHTMX + Go + PostgreSQLで作り直した
    デスクトップでもモバイルでも軽快かつ高速に動作し、複雑さは最小限に抑えられ、コードも理解しやすく修正しやすい。今は数か月おきに小さなバグを直す程度で、成熟したアプリでは必須アップグレードの間隔が数年から数十年に伸びることを期待している

    • 公開しているオープンソースがあるのか気になる。Go・htmx・PostgreSQLの組み合わせは何度か軽く試したが感触がよくなく、特にGoのサーバーサイドテンプレートが使いづらかったので、適切なパターンやライブラリを見落としているのか知りたい
    • これでも設計過剰に見える。スキーマ変更中の無停止運用が絶対に必要なサイトでなければ、WAL2モードのSQLiteで十分だ
      PostgreSQLも、バージョンアップ時に大きな停止を避けようとするとレプリケーション環境や複雑な切り替え手順が必要になるので、選択はそれほど単純ではない

  • HTMXが最初に知られるようになった頃から満足して使っており、Grugの記事も広く共有してきたが、ソフトウェア開発を楽しく保つ文化のおかげで、今回の商品もすぐに購入した

  • Grug-brained developerの記事とHTMXを同じ人が作ったのか気になる

    • そう
    • 彼はLuluの本も書いた

  • HTMXも結局はJavaScriptライブラリであり、スクリプトを無効にした環境向けの自動フォールバック動作が十分でない点が気に入らない
    そのせいで、開発者が静的コンテンツのページですらすべてHTMXで処理しようとしてしまう。昔ながらのフォーラムをホスティングするためにPHPとMySQLの負担を避けてPythonベースのPunkwebBBを見つけたが、スクリプトを無効にすると一部のボタンがまったく動作せず、機能的に不要なHTMXを使っていた
    フォークして不要なJavaScriptを取り除くには作業量が多すぎるので、結局Python DjangoベースのノーJavaScriptフォーラムを自分で作っている

    • 自分のNext.jsサイトは、JavaScriptを無効にしてもリンクとHTMLがサーバーでレンダリングされて動作する。クライアントで実行されるツールは止まるが、静的であり得るページは静的なまま保たれる
      ただ、最近キャッシュコンポーネントを導入してからこの特性が後退していたことに今さら気づき、もどかしい
    • HTMXの設計全体が一種の自動フォールバック動作のように感じられる。hx-get、hx-postのような属性を理解できないブラウザを考慮して、最初に送るHTML自体を正常に動作するよう設計すればよい
    • だからTurbo(https://turbo.hotwired.dev/)のほうを好む
      Turboは正しいHTMLから始めて豊かな動作を付け加える、プログレッシブエンハンスメントの哲学に従っている。HTMXはReactと同じくJavaScriptライブラリであり、それ自体が悪いわけではないが、あらゆるものをJavaScriptに依存させるアンチパターンに陥りやすい
      今では、JavaScriptなしで動作すべきだという論拠よりも、サーバーレンダリングされたセマンティックなHTMLがアクセシビリティ・SEO・LLMおよび自動化ツールにとって重要だという点のほうが強い。HTMXでも優れたHTMLは作れるが、HTML属性の中にこっそりJavaScriptアプリを作ってしまっていないかを見抜く規律と経験が必要になる

  • htmx 4.0をGame BoyとGame Boy Color向けゲームとして発売する
    Mario Bros.に着想を得た本物のゲームで、3つのバイオームにまたがる4つのレベルを突破し、最後にはスロップ工場でオンライン上のライバルであり現実の友人でもあるボス、Warren Bufferingと戦うことになる。勝利するとhtmx 4.0のソースコードがアンロックされる
    Stephen Mitchell(scum)が大幅にカスタマイズしたGB Studioで自ら制作しており、制作記はまもなく公開予定。Jarason Banesがカートリッジ制作と表紙デザインを担当し、Ash(https://www.fiverr.com/ae1996/)が表紙イラストとhttps://hypermedia.systemsのソフトカバーの絵を担当した

    • GB Studioの作者です。このプロジェクトで使われているのを見るのはすばらしく、次のバージョン向け機能も開発中です: https://www.youtube.com/watch?v=q8UKwV1gJAI
    • GB Studio内蔵サウンドエンジンを使ったのなら、そのコードは私が書いたものです。こういうプロジェクトで自分のコードが使われるのはいつも嬉しい
    • カートリッジや他の商品も注文してあり、https://brickboy.xyz/が届いたらすぐに始めるつもり
    • 最初の開封・プレイ・レビュー動画が楽しみ
    • 本当に物理カートリッジなのか、最後にどうやってソースコードを取り出すのか気になる
      Gitリポジトリ用のパスワードを表示する方式なのか、ソースへのアクセス権を与えるNFTのような形なのか知りたい

  • 批判者が割り込んできてHTMXがなぜダメなのかを説明しないHTMXスレッドだなんて驚き
    React愛好家でさえ、Game Boy版の発売だけは認めざるを得ないようだ