- Gumroadは新しいプロジェクトHelperを始めるにあたり、htmxを検討した。
- Reactの複雑さを避けるためにhtmxを使おうとしたが、チーム内で意見が分かれた。
- 当初、htmxはシンプルなインタラクションを追加するうえで有望に見えた。
htmxの限界
- 直感性と開発者体験: htmxで作業することはNext.jsより直感的ではなかった。複雑なフォームや動的バリデーションを実装する際、サーバー側のロジックが複雑になった。
- UXの制約: htmxは基本的にRails/CRUDアプローチを取るため、ユーザー体験が単調になった。ドラッグ＆ドロップインターフェースの実装はReactより難しかった。
- AIとツールのサポート: Next.jsはAIツールと相性が良いが、htmxはそうではない。これは開発速度や問題解決に影響した。
- 拡張性の問題: プロジェクトが複雑になるにつれて、htmxは要件に追随できなくなった。リアルタイム共同編集や複雑なデータ可視化機能を追加する際、状態管理が難しかった。
- コミュニティとエコシステム: React/Next.jsのエコシステムは成熟しており、多様なソリューションを提供しているが、htmxはそうではなかった。
最終的な決定 : React/Next.jsへ移行
- 複雑なUXの構築にはReact/Next.jsが適していた。
- ドラッグ＆ドロップ機能、複雑な状態管理、動的フォーム生成、リアルタイム共同編集、パフォーマンス最適化などでReactの強みを活用した。
- htmxの限界を乗り越えるためにReactへ移行し、これはプロジェクトの長期的なビジョンを支えるものとなった。
- この決定に満足しており、現時点ではより速く前進し、より魅力的なユーザー体験を作り、既存のツールやライブラリを活用できるようになった。
経験から得た教訓
- 軽量な代替案を検討することも重要だが、プロジェクトとともに成長し、長期的なビジョンを支えられる技術を選ぶことも重要である。
- Helperの場合、ReactとNext.jsがそのような選択肢であることが証明され、移行後はコア顧客向けアプリのユーザー体験を大きく向上させることができた。
GN⁺のまとめ
- Gumroadの経験は、軽量な代替案を検討することが重要である一方で、プロジェクトの成長と長期的なビジョンを支えられる技術を選ぶことの重要性を示している。
- htmxはシンプルなインタラクションモデルや既存のサーバーレンダリングアプリケーションに適している可能性がある。
- Helperの複雑な状態ベースのインターフェースには、ReactとNext.jsのほうがより良い選択だった。
- 技術スタックは必要に応じて再評価でき、新しい技術が登場するたびに柔軟性を保つことが重要である。
1件のコメント
Hacker Newsの意見
GumroadのCEOがhtmxを試した後にNextJSへ移行した経験を共有しており、これはhtmxでの否定的な経験を探していた人にとって有益な情報だった
複雑なフォームを作る際、サーバー側のロジックが複雑になり、Reactでのクライアント側作業より難しかった
htmxでフロントエンドを軽量に保とうとしたが、複雑なUI/UXと状態管理のためにサードパーティライブラリを使うことになった
htmxではドラッグ＆ドロップインターフェースの実装が難しく、Reactライブラリのほうがよりスムーズな体験を得られた
htmx.onLoadイベントを活用して、読み込まれたコンテンツ内で属性を持つマークアップを見つけて接続できるチームはフロントエンド開発により慣れているようで、バックエンドとのやり取りに苦労していた
Next.jsでは開発プロセスが自然だったという意見がある
HTMXがこのような経験を共有しているのは興味深く、HTMXだけでは十分でないプロジェクトもあるという意見がある
HTMX.orgがこのようなエッセイをホストしていることへの称賛がある
AIツールが新しいフレームワークやプログラミング言語の採用を難しくする可能性への懸念がある