- Gumroadは新プロジェクト Helper で軽量なフロントエンドを期待してhtmxを検討したが、複雑なUX要件が大きくなるにつれて React/Next.js に移行した
- 単純なインタラクションにはhtmxが有望だったが、動的バリデーションや条件付きフィールドを持つフォームではサーバー側ロジックが冗長になり、開発フローが不自然になった
- ワークフロービルダーの ドラッグ＆ドロップ、リアルタイムコラボレーション、複雑な状態管理、動的フォーム生成は、Reactエコシステムとコンポーネントモデルのほうがより直接的に実装できた
- 問題解決の情報やAIツールのサポートは Next.jsとReact のほうが豊富で、htmxはオープンソースの学習データ不足により開発速度の面で不利だった
- htmxは既存のサーバーレンダリングアプリや単純なインタラクションモデルには適している可能性があるが、Helperのように状態が多いインターフェースにはReactとNext.jsのほうが合っていた
Helperでhtmxを検討した背景
- Gumroadは新プロジェクト Helper を始めるにあたり、htmx をフロントエンド候補として検討した
- 当初の期待は、Reactは必要以上に重い という過去の経験から来ており、htmxは単純なインタラクションを軽量に追加する方法になり得ると見ていた
- チーム内では、htmxは複雑化したJavaScriptエコシステムを風刺するミームに似ているという評価もあった
- TailwindがインラインCSSの別構文のように見えるのと同じように、htmxもインラインJavaScriptの別構文に近いという見方があった
- TailwindはGumroadのツール体系に定着したが、htmxはHelperの目的に合う形では拡張できず、顧客にとって最良のユーザー体験にはつながらなかった
React/Next.jsのほうが自然だった点
-
開発体験とフォーム処理
- htmxでも正しい実装は可能だったが、GumroadはNext.jsで機能を動かす過程のほうが直感的だと感じた
- 動的バリデーション と条件付きフィールドを持つ複雑なフォームでは、Reactのクライアント側処理のほうが単純で、htmxではサーバー側ロジックが長くなった
-
UXとインタラクションの制約
- htmxはアプリをRails/CRUD方式へ押し進める傾向があり、基本体験が平凡または一般的な形になりやすかった
- ワークフロービルダーの ドラッグ＆ドロップインターフェース はhtmxでは回避的な実装が必要で、Reactライブラリで得られる滑らかな体験よりも粗く感じられた
-
AIツールと問題解決の速度
- AIツールはNext.jsには慣れているがhtmxにはそれほど慣れておらず、その理由としてオープンソースの学習データ不足が挙げられた
- React/Next.js側の資料が豊富で、問題が起きたときに解決策を見つける速度がより速かった
-
複雑さと拡張性
- プロジェクトが複雑になるほど、htmxの単純さは利点というより制約に近くなった
- リアルタイムコラボレーションや複雑なデータ可視化が追加されるにつれて、htmxのサーバー中心アプローチでは複数コンポーネント間の状態管理がますます難しくなった
Helperの機能ごとに見えた違い
- ドラッグ＆ドロップ: Reactエコシステムの
react-beautiful-dnd は、少ない設定で滑らかかつアクセシブルなドラッグ＆ドロップを提供する
- 複雑な状態管理: 各ワークフロー段階の設定と条件ロジックをリアルタイムでUIに反映するには、
useState やReduxのようなReactの状態管理方式のほうがより直接的だった
- 動的フォーム生成: 段階タイプごとに異なる設定フォームを作り、ユーザー入力に応じて変更する作業は、Reactコンポーネントモデルのほうがより直感的に処理できる
- リアルタイムコラボレーション: 複数ユーザーが同時にワークフローを編集する機能は、WebSocketsとReactで比較的直接実装でき、htmxではより複雑なサーバー側ロジックとカスタムJavaScriptが必要だった
- パフォーマンス最適化: ワークフローが大きく複雑になるほど、Reactのvirtual DOM、
useMemo、useCallback のようなフックでレンダリングを細かく最適化できた
エコシステムと最終判断
- React/Next.jsエコシステムは大きく成熟しており、Gumroadが直面したほぼすべての問題に対する解決策を提供した
- htmxでは機能を妥協したり自分たちで作り直したりする状況が多く、サードパーティサービスやライブラリ統合でもReactバインディングはあるがhtmx対応物はないケースがあった
- React/Next.jsに移行した後、Gumroadは複雑なUXを構築するうえでより適した選択だったと評価した
- より速く動け、より没入感のあるユーザー体験を作ることができ、既存のツールやライブラリを活用できた
- Helperの主要顧客に向けたアプリのユーザー体験も大きく改善できた
- htmxの限界は克服不可能なものではないが、解決の過程はhtmxの強みから離れ、JavaScript中心の環境により自然な解法へと移行させるものだった
- htmxは単純なインタラクションモデルや、既存のサーバーレンダリングアプリの上に構築されたプロジェクトには良い選択になり得る
- Helperのように複雑で状態の多いインターフェースではReactとNext.jsのほうが適しており、Gumroadは必要な変化や新技術に応じて技術スタックを継続的に再評価できると見ている
1件のコメント
Hacker Newsの意見
別スレッドで書いたことだが、GumroadのCEOがTwitterで、あるプロジェクトでhtmxを試したものの最終的にはNextJSを選んだと話していた。
htmxのWebサイトに載せられるような、よく考えられた否定的な体験談を探しているので、経験を文章にしてくれないかと頼んだところ、快く引き受けてくれてありがたかった。
何にでも最適解だと主張する他のプロジェクトと比べると新鮮だ。
特に ドラッグ＆ドロップ に関する指摘が気になる。htmxでは本当に難しいと見ているのか、もしそうなら解決する計画があるのかも知りたい。
RailsとReactを一緒に使えないわけでもないのに、そう言ったことになる。
記事自体はhtmxに関する否定的な経験というより、ドラッグ＆ドロップやリアルタイム共同編集が出てくる時点で、そもそも htmxを試したという選択 が間違っていた可能性があるという話に見える。
スクリーンショットが何を見せようとしているのかもよく分からないが、それでもhtmxのWebサイトに載せるには良い記事だと思う。
私にとってhtmxはReactの代替というより jQueryの代替 に近い。
htmxとjQueryはドキュメントにインタラクションを加え、Reactはドキュメント全体になろうとする。
仕事に応じて道具は変わるべきだ。
「AIとツール支援: AIツールはNext.jsには非常に慣れているが、htmxにはそれほど慣れていない点もworth noting」という部分は、欠点として淡々と書かれていたが、開発ツール・ライブラリ・フレームワーク・言語の未来にとってはかなり不気味な兆候だ。
予想すると、大規模言語モデル は既存の勝者総取りと先行者利益をさらに強めるだろうし、より多くより良い学習データのおかげでオープンソースツールの利用もさらに後押しするだろう。
大規模言語モデル以前から、Reactには質問の大半がStackOverflowにすでにあり、ほぼあらゆる用途に成熟したライブラリがあるという利点があった。
今は、以前ならStackOverflowで聞いていた質問を大規模言語モデルに尋ねる人が出てきただけで、結果は同じだ。
みんなが多く使っているものを使えば利点がある。
ただ、ソフトウェアエンジニアとしての長期的なキャリア戦略としては、あまり良い賭けではないと強く思う。
むしろこれは 良いこと かもしれないとも思った。
ソフトウェア業界は最新のツール、言語機能、フレームワークを追いかけるのにあまりにも多くの時間を使っている。
少し停滞して、6か月ごとに新しい金づちを作るより、すでに持っている道具で仕事を終わらせる方向のほうが前向きかもしれない。
実際にAIがHTMXをうまく扱えなかったという経験なのか、それとも単に別の資料不足の話に移ったのか、コメントだけでは分からない。
大規模言語モデルはしばしば 汎用翻訳機 のように非常によく機能する。
人気フレームワークの一般的なパターンや概念を学び、より小さなフレームワークの構文をある程度知っていれば、経験上かなり良いニッチなフレームワークのコードも生成する。
海賊たちが学習データで一度も語られていない話題でも海賊口調で話せるのと似ている。
「動的バリデーションや条件付きフィールドのある複雑なフォームを作るとき、Reactでは簡単なクライアント側の作業で済むことを処理するために、複雑なサーバー側ロジックを書くことになった」という部分を見ると、Anakin Padmeミームを思い出す。
「でも サーバー側バリデーション も実装するんだよね…だよね？」
Reactでは簡単でもhtmxでは難しいフォームといっても、React的なグローバルアプリケーション状態を押し込んでライブラリで90%終わらせたい場合以外はあまり思い浮かばない。
ただしページごとではなく、送信時に一度 行うだけだ。
「フロントエンドをとても軽く保つのにhtmxが良い解決策になりうると思った」という話とは逆に、軽いフロントエンド を諦めた時点でhtmxが合わなくなったように見える。
複雑なUI/UXや状態管理をレンダリングするためにサードパーティライブラリを使い始めている。
また、「ReactではXをするのがもっと簡単だった」と言っても、それをサードパーティライブラリでやっていたなら公平な比較ではない。
誰かが代わりにやってくれたから自分でやらずに済んだだけだ。
記事にはかなり共感するが、複雑な状態とレンダリングが必要だと分かっていたなら、htmxは最初から良い解決策ではなかったと思う。
htmxは好きだが、この記事は筆者の技術的理解がかなり不足していたことを示している。
Webプラットフォームやhtmx.orgの文書を少しでも知っていれば見えてくる長所短所ではなく、雰囲気だけでHTMXを使ってみたかったのに近く見える。
Gherkin言語は単純なケースでは良さそうに見え、原理的には複雑なケースにも拡張できるが、抽象化レベルを何層にもわたって管理しなければならないほど、純粋なPythonであるpytestのほうが楽になる。
プロジェクトの範囲はまったく「単純」ではなく、私なら最初からReactを選んでいただろう。
「ワークフロービルダー向けのドラッグ＆ドロップインターフェースの実装はhtmxでは大きな挑戦で、Reactライブラリで得られる滑らかな体験に比べると無骨な回避策が必要だった」という点については、HTMXはフロントエンドのバンドルが必要な分だけを行い、それ以上をしないときのほうが向いている
htmx.onLoadイベントに接続したあと、読み込まれたコンテンツ内で属性付きのマークアップ、たとえば columns、cards、tasks などを見つけて適用すればよいたとえばレンダリング済みのマークアップに sortable.js をバインドし、sortable イベントを HTMX 経由の状態更新に接続できる
かなりシンプルで、ドキュメントにもまさにこの例がある: https://htmx.org/docs/#3rd-party
モダンで状態を持ち、動的なウェブサイトは HTMX とまったく両立しないわけではない
文を読むと、このチームはバックエンド開発よりも フロントエンド開発 に慣れているように見える
昔ながらのやり方の開発者の立場からすると、フロントエンド開発者の考え方にはちょっとした恐れや誤解が見えることがある
正直、こういうやり方がどう動くのかを理解するには、少しだけ発想を調整すればいいと思うが、多くの人がキャリアを通して一般的なクライアント／サーバーアプローチを見たことがないという点も理解できる
それでも、既製の React コンポーネントの価値や、ドキュメント・ヘルプを見つけやすい利点は無視できない
一世代のデザイナーたちがモバイルとウェブを非常に似たものとして設計し、その実装の複雑さを開発者に押し付けてきた
しかしウェブは、可能ならモバイルと違っているべきだし、違っていてよい
文では CRUD アプリのようにデザインがあまりに「generic」だと言っているが、それは本当に悪いことなのか?
どのサイトでも予測可能なユーザー体験を作れるようにする、普遍的に採用された文書モデルという偉大な成果があるのに、私たちはそれを「退屈だ」としか見ていない
退屈さそのものに本質的な問題があるかのように扱っている
モバイルアプリのように感じられる独自でブランド化された体験を求める市場圧力は理解できるが、デザイナーたちが React的思考と同じくらい WWW的思考 もできたらどうだろう、と想像してしまう
HTMX がこうした記事や似た記事を自分のサイトに載せているのは良いことだ
HTMX だけではうまく合わなかったもっともな理由がかなりあったように見える
フロントエンドの専門家ではないが、いくつか思うところがある
第一に、どうせバックエンドでもフォーム検証はしなければならないのではないか?
バックエンドシステムがその結果をフロントエンドに渡すのが、なぜそんなに難しかったのか気になる
多くの場合、フロントエンドとバックエンドの両方でフォーム検証をする十分な理由があるので、その場合は HTMX だけでは足りないだろうが、この問題の表現は少しわかりにくい
第二に、HTMX だけを使うとアプリがある程度こういう方向に押されうるし、場合によってはそれが良いことでもあるが、このチームは顧客のために別のやり方が必要だと判断したようだ
第三に、AIツールへの依存が主要な問題になるほど、このチームが AI ツールをどう使っていたのかをもっと知りたい
今後 AI 開発ツールの重要性が増すなら、新しいフレームワークやプログラミング言語が導入されるために必要な、十分なツールや統合を確保する基準が高くなりすぎるのかもしれない、というのも興味深い問いだ
第四に、HTMX に対するよくある不満と同じく、プロジェクトによっては HTMX が提供するもの以上を必要とする
第五に、Django と Python が好きな理由の一つも、深いコミュニティと統合、アドオンのエコシステムにある
概念は似ていながら HTMX より機能が多い https://unpoly.com/ のようなもののほうが、このチームには合っていたかもしれない
「Next.js の開発プロセスは自然に感じられた」という言葉については、この ReactJS 文法のどの部分が自然なのかわからない
慣れることはあっても、自然ではない
useEffect(() => { const timer = setInterval(() => { setCount((prevCount) => prevCount + 1); }, 1000); return () => clearInterval(timer); }, []);結局は JavaScript でぎこちなくつなぐことになるだろう
可変タイムアウトを持つカスタムフックが欲しいなら、はるかに複雑になることもある
Dan もこのテーマで長い記事を書かなければならなかった: https://overreacted.io/making-setinterval-declarative-with-r...
コードを書いてみてもらえるだろうか?
htmx.org がこの記事をホスティングしたのは称賛に値する
結局、誰かが htmx を手に取って自分の要求を満たせないと腹を立てたとき、今では示せる資料もできた
自分のいくつかのプロジェクトで htmx を使っていて、かなり良かった
こういう記事は、htmx が得意なところと不足しているところをめずらしく見せてくれるので、むしろ htmx を使うことへの確信が強まる
3つ目のポイントはぞっとする
企業が自分たちのフレームワークがモデルの学習セットで過剰代表されるように金を払い、それをもとに契約を売る世界を想像してしまう
検索エンジン最適化 が開発ツールの中に baked in されているようなものだ