依存関係管理の疲弊: Reactを捨ててGo+HTMX+Templを選んだ理由

• 今年、Go、HTMX、Templを使って個人プロジェクトを進めた結果、Reactの利用をやめることにした
  • HTMX公式サイトでは、ReactをやめてHTMXを選ぶ説得力のある主張をいくつも見つけられるが、依存関係管理の疲弊について語る人はあまり多くないと感じる
• 「依存関係管理の疲弊」とは何か？
  • Reactを使った最後の個人プロジェクト（インタラクティブなカタルーニャ語辞書）で、主にReactパッケージの依存関係更新にあまりにも多くの時間を費やしていることに気づいた
  • パッケージを最新リリースへ更新すると、APIに重大な変更が入り、そのたびにコードのリファクタリングへ時間を投じる必要があった
  • WebアプリはEC2インスタンス上で公開サービスとしてデプロイされていたため、依存関係の更新を維持したいと考えていた
• 新しいメジャーバージョンのリリースは本当に必要か？
  • wouter（Reactルーターパッケージ）やTanStackQuery（バックエンドからデータを取得・キャッシュし、状態を管理するために使用）といったパッケージで、メジャーバージョン更新が原因となってWebアプリが致命的に壊れた
  • 最初のメジャーバージョン更新でアプリケーションが壊れたときは疑いもなくコードをリファクタリングしたが、2回目に起きたときには疑問を抱くようになった
  • セキュリティパッチを除いて、Webアプリがメジャーバージョンのリリースから実際にどんな利益を得ているのか疑問を持つようになった
  • 主要コンポーネントのAPIを5回も破壊的変更する必要があるのか疑問を持った
  • 新機能や別の製品をリリースできたはずの時間を、どれほど失っているのか考えるようになった
• 時間不足の問題
  • 個人のコーディングプロジェクトに割ける時間は多くないため、依存関係のメジャーバージョン更新後にコードをリファクタリングすることへ時間を無駄にしたくない
  • 顧客向けの製品を構築し、今後の保守作業に対して費用を請求するつもりなら、不安定な依存関係を多く使っても構わない
  • しかし、最小限の保守しか必要としない製品を作りたいのであれば、JSエコシステムからは距離を置くだろう
• Go+HTMX+Templの使用
  • 個人プロジェクトでGo+HTMX+Templを使う主な理由は、一般的な依存関係／セキュリティ更新を無視せずに、Goプロジェクトでは機能のリリースに集中できるからである
  • Go言語自体が、安定した標準ライブラリと言語仕様を維持している

[bbulbum]

HTMX はかなり好意的な評価が多いですね。
SSR ベースのアプリケーションを補完する手段として、HTMX をよく探しているのかなという気がします。
サイドプロジェクトで一度試してみたいですね。

[savvykang]

TanStackライブラリは必要以上に複雑で、ここ数年はドキュメントの品質も低くなっているため選びませんでした。そして npm パッケージの入れ替わりサイクルが短すぎるので、常に最新バージョンにこだわる必要があるのかとも思います。

ただ、会社の仕事では React を捨てることはできない気がします。個人プロジェクトなら何を使っても構いませんが。

[dohyun682]

メジャーバージョンアップデートさえしなければ、依存関係の問題はそこまで大きくないのでは…？

[aer0700]

少し前に、社内で動いているスケジュールジョブの中に Python 2 で動いているやつを見つけたのですが、息が詰まる思いでした。
悩んだ末に、今は問題なく動いているのでひとまずそのままにしておこう、ということにしました。いつまでも更新せずに耐えられるわけではないでしょう。

[aer0700]

依存関係管理のしんどさ VS 車輪の再発明のうんざり感
昔からある議論です。不要な車輪は使わないのが正しいとはいえ、今日必要なくても明日も必要ないとは限らないですし……
Goは使ったことがないんですが、最近はGoで作られたサーバーをよく見かけますね。今すぐ使わないとしても、一度は触ってみるべきかなと思います。

[clickin]

HTMXは流行の技術の筆頭だからか試してみる人が多いですが、むしろ go + vecty + gox のような方向性はどうだろうかと思いますね

[GN⁺]

Hacker Newsの意見

• Reactのようなライブラリをやめて、Actix、Tera、HTMXでWebアプリを開発した経験が共有されている。こうしたスタックは保守性に優れ、ユーザーにも好評だった

  • 新しいWebアプリを素早く開発し、テストユーザーに配布した経験が説明されている
  • 「依存関係管理の疲れ」がなかったため、ツールへの深い理解を得ることができた

• Tannerのライブラリは機能は豊富だが、API設計に難があると評価している

  • React TableとReact Queryは強力だが、境界の切り方が適切でなく、問題を引き起こす
  • Reactの利点はフレームワークではない点であり、うまく設計された境界で止まっていることだ
  • この基準を満たすライブラリだけを採用するよう努めている

• HTMXの例は複雑さを別の場所に移しているだけに感じられ、JSXはテンプレートを避けるためのエレガントな方法だと説明している

  • ルーティング、状態管理、認証など、依然として解決すべき問題は多い

• Reactをやめると言うのは奇妙に感じられ、問題はReactではなく他の依存関係にあると主張している

  • Goでバックエンドを書くという選択は、もともと常に可能だった

• パッケージの次のメジャーバージョンへ更新するときは、変更があることを前提にすべきだと強調している

  • Remixを例に、変更を段階的に適用できる方法を説明している
  • 良いパッケージには大きな努力が必要だと主張している

• DjangoとHTMXでSPAプロジェクトを移行した経験を共有し、JavaScript依存を大幅に減らしたと説明している

  • SPAは時限爆弾のように感じられたと表現している

• Reactは、適切に保守されていないサードパーティーパッケージの責任を負うべきではないと主張している

  • ルーターやReduxのような状態管理ツールは必要ないと説明している

• react-queryのv5はv3 APIと互換性があるべきだったと思う一方で、マイグレーションは容易で必須でもないと説明している

  • 「依存関係管理の疲れ」は誇張されていると感じており、依存関係の数は合理的な範囲に保つよう助言している

• Webアプリが追加の利点を得ていないにもかかわらず、なぜアップグレードしたのか疑問視している

  • 最新版へアップグレードしても利点はないと説明している

• Reactとnextjsをやめて別のスタックへ移行してから、ストレスが減り、アップデートがもはや憂うつを引き起こさなくなったと説明している