私はしばらくの間、htmxを追っていました。私はそれが、ウェブ開発で行われている実際の作業、例えばReact Server Components、Svelte Runes、Signalsのような、最先端を実際に押し進めているものからの一種の軽いコメディリリーフとして役立っている、やや面白く/気まずいミームだと思っていました。
残念ながら、2023年の半ばのある時点で、人々は何らかの理由で、htmxを実際に真剣に受け止め始めました。これは非常に憂慮すべき事態であり、私はウェブ開発の将来を深く懸念しています。
そして、私が警戒しているのは私だけではありません。ここで、htmxを痛烈に批判した素晴らしい記事を読むことができます。
基本的に、彼らは自分たちの無知を全面的に露呈し、それから、自分たちがやったことに対してあらゆる根拠のないメリットを付与し、他の誰もがそれを褒め称えることを期待しています。
その通り。まさにその通り。
残念ながら、その素晴らしいMediumの記事の言葉遣いはアカデミックで、理論的なHTMLをしっかりと把握していないと、その中のより重要な点の多くは、典型的なウェブ開発者の頭を飛び越えてしまうでしょう。
そこで、この記事では、素人ウェブ開発者向けに分かりやすい言葉で、なぜhtmxがクソなのかを説明しようと思います。
まず、htmxのコードについて考えてみましょう。
彼らは至る所でvarを使用しており、最新のJavaScript機能はほとんどありません（htmxの人々、モジュールを知っていますか？）、window名前空間を汚染しています。そして、延々と続きます。
最悪なのは、ただの大きなJavaScriptの塊であることです！1つのファイルです！全く分解されていません。もしこの人が私のMSUでのクラスの1つを受講していたら、関心の分離に対するこの完全な誤解だけに基づいて、彼らを落第させていたでしょう。これは、コンピューターサイエンスの1年生なら誰でも理解できるはずのことです。
優れたソフトウェアはクリーンなコードから始まります。そして、このコードは汚いです。
次の危険信号は、ビルドステップの欠如です。htmxには従来のビルドステップがないだけでなく、それによって他のJavaScriptコミュニティが享受している利点を自ら奪っているだけでなく、それについて積極的に自慢しています！
そして、さらに悪化します。
よく見ると、彼らはビルドステップがないと主張しているにもかかわらず、実際にはビルドステップを持っています。それは、彼らが自分で書いたアドホックなbashスクリプトのセットにすぎません。
馬鹿げていて、かつ不誠実です。恥ずべきことです。
明らかな利点があるにもかかわらず、htmxのようなプロジェクトに対してTypeScriptを頑なに拒否しています。その理由の一部は、ビルドステップに対する彼らの不合理な反対（ちなみに、彼らは実際には持っています！）ですが、一部は「デバッグ可能なソースコードを配布する」という馬鹿げたこだわりです。もちろん、完全に無知ではないJavaScript開発者なら誰でも知っているように、TypeScriptは完全にデバッグ可能にするソースマップをサポートしています。この事実にもかかわらず、作者は開発に時代遅れのJavaScriptを使用し続けることを主張しています。
自分たちがしくじったことを暗黙のうちに認めて、彼らは今になってJSDocアノテーションをコードベース（ここでは緩くこの言葉を使います）に追加しています。これはすべて、最初から明白で正しいことをせず、プロジェクト全体を最新のモジュール式TypeScriptで書かなかったという事実を補うためです。
ここでの唯一の良いニュースは、少なくとも彼らがそこそこのテストスイートを持っていることです。そして、コードベースの状態を考えると、当然そうあるべきでしょう！
さて、これでhtmxコードベース自体の主要な（ただし、決してすべてではありません！）問題はカバーできました。htmxに関するより一般的な問題に移りましょう。
最初の明らかな問題は、作者がまたしても自慢していることですが、ハイパーメディアを使用していることです。実際、これは「HTMLを使用している」という気取った言い方に過ぎません。なぜ彼らがそれに対して異なる紛らわしい用語を使うことに固執するのか分かりませんが、まあいいでしょう。
さて、気づいていないかもしれませんが、HTMLは今や30年以上も前のものです。それは古代のものです。さらに、私たちは彼らが推奨しているアプローチについて多くの経験を持っています。htmxが何か新しいことをしているわけではありません。intercooler.js、PJax、Unpoly（ちなみに、htmxよりずっと優れています）は文字通り永遠に存在しています。
それ以前でさえ、jquery.load()がありました。
2008年のこのjQueryコードを見てください
$( "#result" ).load( "ajax/test.html" );
そして、htmxの人々が私たちに提供する超革新的なものを見てください
<button hx-get="/ajax/test.html"
hx-target="#result">
Load
</button>
すごい。素晴らしい。
腹立たしくなければ笑いごとだったでしょう。
htmxを使用しないことを検討する次の理由は、利用可能なコンポーネントがないことです。reactを使用すると、MUI、NextUI、Chakraなどのものが手に入ります。
htmxでは、何も手に入りません。使用したいコンポーネントと、イベントなどを使用してhtmxと統合する方法を自分で考える必要があります。
本当にlitのようなものがどのように機能するかを理解し、さらにそれらをhtmxと統合する方法を考え出すことに時間を費やしたいですか？それは意味がありません。統合された既製のコンポーネントを使用して、面倒な手間なく使用できるフロントエンドライブラリを使用する方がはるかに優れています。
htmxを避けるもう1つの大きな理由は、バックエンドチームとフロントエンドチームの間の分離をなくすことです。彼らは、自社が（愚かにも）Reactからhtmxに移行したときに、それが美徳であるかのように自慢しているページさえ持っています。
フロントエンド/バックエンドの分離は、多くの企業にとって非常に成功しており、フロントエンドエンジニアは優れたユーザーエクスペリエンスの構築に集中し、バックエンドエンジニアはデータアクセス層を正しく取得することに集中できます。
確かに、バックエンドエンジニアがフロントエンドエンジニアの要求が頻繁に変更されると不満を言い、フロントエンドエンジニアがバックエンドエンジニアの動きが遅すぎると不満を言うなど、2つのチーム間の調整には時々いくつかの困難があります。しかし、それに対処するためにGraphQLやRSCのようなテクノロジーがあり、既存の標準的なWebアプリケーションモデル内で、これは現時点では解決済みの問題です。
フロントエンド/バックエンドの分離は、特に開発チームを拡大するにつれて、企業にとって非常に優れた組織モデルであることが証明されており、「フルスタック」（いわゆる）開発のためにそれを放棄することは、リスクが高く、率直に言って愚かなことです。
フロントエンド/バックエンドの分離が良いか悪いかはさておき、バックエンドエンジニアがゴミのようなユーザーインターフェースを作ることは断言できます。
ただ、htmxのウェブサイトを見てください。インラインスタイル、テーブルがあり、画像のタグにはaltの説明が永遠にありませんでした。HTMLを使用するように私たちに言おうとしている人々による、ただのひどいHTMLの寄せ集めです！
ユーザーインターフェースは、それらを適切に構築する方法を理解している人々に任せるべきであり、それらの人々は今日、主にフロントエンドのSPA開発者です。
htmxを使用すべきでないより技術的な理由に戻ると、それはクロスサイトスクリプティング攻撃（略して「XSS」）と呼ばれる種類のセキュリティ問題を引き起こします。
ここでの問題は、htmxの設計の根本的なものです。マークアップに動作を入れることを可能にし、さらには推奨することさえあります。ここでも、関心の分離の明確な違反が見られます。ウェブ開発では、マークアップ、スタイル、動作をそれぞれHTML、CSS、JavaScriptファイルに分離する必要があることは、昔から知られています。
この明白でよく知られた真実を違反することによって、htmxは、HTMLを適切にサニタイズしない場合、他の人があなたのウェブアプリケーションに動作を注入することに対して脆弱になります。
時々、htmxの作者は「では、href属性についてはどう思いますか？」のような賢しらげなコメントをしますが、それは明らかに別物です。
htmxを使用しないもう1つの実用的な理由は、ざっくり言うと、htmxの仕事がゼロであることです。
私はIndeedでhtmxの仕事を検索したところ、合計2つしか見つかりませんでした。1つはMicrosoft、もう1つはオークリッジ国立研究所です。
一方、「react」を検索すると、13,758件の仕事が見つかります。
開発者の皆さん、どちらのテクノロジーにあなたのキャリアを賭けたいですか？
上記の問題の裏返しは、あなたが会社である場合、ざっくり言うと、htmx開発者がゼロであるということです。
誰もがブートキャンプに行ってReactを学びます。もし、あなたが大規模な潜在的な従業員プールを必要としている場合（おそらくあなたの会社には何らかの理由で離職率が高い、おそらく従業員の賃金を低く抑えたい、おそらく少人数のフルスタックエンジニアチームがあなたの王国建設を妨げるかもしれない）、フロントエンド開発の大御所を採用する方がはるかに理にかなっています。
今日、その大御所はReactです。
より技術的な側面に戻ると、htmxを採用した場合、モバイルアプリやサードパーティが利用するAPIも必要となる場合、Webアプリケーションのエンドポイントとは完全に別にAPIを作成する必要があります。
ここでもまた、信じられないことに、htmxの人々は、この事実を自慢しており、ここで行われる作業の重複を完全に無視しています。
単一のバックエンドチームが保守し、あらゆるニーズに柔軟に対応できる単一のAPIを持つ方が、はるかに理にかなっています。
これは明白であり、率直に言って議論する価値もありません。
htmxのもう一つの技術的な問題は、スケールしないということです。小さなアプリケーションではうまく機能するかもしれませんが、アプリケーションが大きくなるにつれて、htmxのモデルは崩壊し、めちゃくちゃになります。Reactや他のフロントエンドツールのコンポーネントモデルは、すべてを区画化し、テスト可能に保ちます。これにより、大規模なコードベースをクリーンに保つことがはるかに容易になります。
例として、htmxによく似たテクノロジーを使用して開始したGitHubを考えてみてください。最近Reactを採用し始め、以前よりもはるかに安定しています。最初からReactを使用し、最新のコンポーネントベースの方法で全体を構築した方が良かったでしょうが、少なくとも今、正しい方向に進んでいます。遅れてもやらないよりはましです。
最後に、おそらくhtmxを使用しない最も重要な理由：作者は明らかに精神的に不安定です。
彼のTwitterフィードを見てください：プロフェッショナルではなく、子供っぽく、意図的に挑発的です。
または、彼が自分のサイトに同意しない）エッセイを投稿しているという事実を考えてみてください。
エッセイのタブにはミームのセクションがあり、そのほとんどが不快で、真剣に受け止められることを期待するフロントエンドライブラリのWebサイトにあるべきではありません。
どうやら彼は誰でもhtmxのCEOになれるようにし、LinkedInでその非常に不快な求人発表をさせているようです。
みだらな道化です。
フロントエンドライブラリを選択するとき、ある程度、そのライブラリの作者を同僚として選択していることになります。本当にこの人と一緒に働きたいですか？私は絶対に嫌です。
これが、Webアプリケーションにhtmxとハイパーメディアを選択することが、例外的に悪い考えであり、モンタナでしか生まれないということを納得させてくれたことを願っています。「終わった」、「復活した」などのナンセンス、CEOのプロフィール、子供じみたミームに惑わされないでください。
ソフトウェア、特にフロントエンドソフトウェアは、真剣なビジネスであり、法律や政治といった他の非常に真剣で生産的な活動と同じように真剣に扱う必要があります。私たちは、イノベーションと洗練に焦点を当てたライブラリをサポートすべきであり、Twitterでばかげたことを投稿するのにほとんどの時間を費やしている作者による、壊れていて時代遅れのライブラリをサポートすべきではありません。
それはただの常識です。htmxは最低です。