RESTとHATEOASについて理論的に語ったり、ハイパーメディア駆動アプリケーションアーキテクチャを説明したりするのは良いことですが、結局のところ、ソフトウェアで重要なのは実用性です。つまり、うまく機能するのか？改善されるのか？ということです。
htmxが機能することは、私たち自身がソフトウェアで使用しているため、確実に言えます。しかし、他のアプローチと比較して改善されるかどうかは、例えばreactと比較して、htmxがどの程度優れているかという、直接的な比較ができていないため、断言することは難しいです。
しかし、今では違います。
ContexteのDavid Guillot氏が、「すべてのhtmxデモの母」と呼ぶべきものを、DjangoCon 2022で発表しました。
実世界のSaaS製品でReactからhtmxへ: 私たちはそれを成し遂げました。そして、それは素晴らしいものです！
私たちは、SaaS製品の2年間かけて構築したReact UIを、シンプルなDjangoテンプレートとhtmxで数ヶ月で置き換えるという思い切った決断をしました。その経験を、さまざまな側面からの具体的な指標とともに皆さんと共有し、皆さんのCTOを納得させたいと思います！
プレゼンテーション全体をこちらで視聴できます (必見です!)。
これは驚くべき数値であり、Contexteのアプリケーションがハイパーメディアに非常に適しているという事実を反映しています。それは、多くのテキストと画像を表示するコンテンツ中心のアプリケーションです。すべてのWebアプリケーションでこのような数値が見られるとは限りません。
しかし、少なくともシステムの一部でハイパーメディア/htmxのアプローチを採用することで、多くのアプリケーションが劇的な改善を遂げることを期待できます。
移植で容易に見落とされがちな側面の1つは、チームの構造に与えた影響です。ContexteがReactを使用していたときは、バックエンドとフロントエンドが明確に分かれており、2人の開発者が完全にバックエンド、1人の開発者が完全にフロントエンド、1人の開発者が「フルスタック」でした。
(ここでの「フルスタック」とは、フロントエンドとバックエンドの両方での作業に慣れており、したがって「スタック」全体で完全に独立して機能を開発できることを意味します。)
htmxへの移植後、チーム全体が「フルスタック」開発者になりました。つまり、各チームメンバーがより効果的になり、より多くの価値を提供できるようになりました。また、開発者は機能全体を所有できるため、開発がより楽しくなります。最後に、開発者は他の開発者と調整する必要なく、スタック内のどこでも最適化できるため、より最適化されたソフトウェアにつながる可能性があります。
プレゼンテーションのスライドはこちらにあります（優れた講演者ノートも必ずチェックしてください！）
https://docs.google.com/presentation/d/1jW7vTiHFzA71m2EoCywjNXch-RPQJuAkTiLpleYFQjI/edit?usp=sharing