Reactコンポーネント卒業！4年間の苦悩の末、私が「地味テック」に鞍替えしたワケ

Next.js、Nuxt.js、Reactと4年間付き合ってきて、気づいてしまったんです。「これって、もしかして複雑にしすぎ？」って。

誤解しないでください。これらのJSフレームワークは、複雑でインタラクティブなアプリには最適です。でも、もっとシンプルなプロジェクトでは？ SSRとCSRの絶え間ない行き来、API（fetch、cache、Redux、状態管理ライブラリなど）の記述、そして依存関係の管理（脆弱性、バージョンの衝突、余計なメンテナンス）は、多くの場合、節約できる時間よりも多くの時間を費やしてしまいます。

AIコーディングの登場で、この状況は悪化しました。今や、小規模なスタートアップは、必要だからではなく、生成が簡単だからという理由で、Reactコンポーネントをデフォルトで使用するようになりました。その結果は？ よりシンプルなソリューションで済むはずなのに、パフォーマンスの悪い、肥大化したアプリが出来上がってしまうんです。

そこで、私は自問自答を始めました。「本当にフルフレームワークが必要なのか？ それとも、vanillaJS、Alpine.js、HTMX、そしていくつかの軽量コンポーネントで実現できるのではないか？」と。そして、私の新しいスタックは、Go、gotempl、Alpine.js、HTMXへと移行しました。

特にソロや小規模なチームにとって、依存関係が少ないということは、メンテナンスが容易になり、実際に長く使えるプロジェクトになるということです。時には、地味な解決策が賢い解決策なのです。

依存性嫌いだって言うくせに、結局もっと依存してるじゃん…😜（皮肉）

良い意見だけど、プロジェクトによるよね。ムカつくのは簡単だけど、Reactみたいなフレームワークやライブラリはかなりミニマルだと思う。state、cache、SSR/CSRの話が出てるけど、別に全部必要ないし、外部ライブラリもいらない。個人的には、ライブラリ/フレームワークは長期的な管理には向いてると思うな。

フルスタックのフレームワークはもう卒業して、ビューライブラリのせいにしてるの？

ピュアなSPAなら、LitElementとその関連ライブラリ（ルーティングとか、場合によってはstate）だけで十分だよ。

SSRとCSRの間を絶えず行き来したり、API（fetch、cache、Redux、state管理ライブラリなど）を書いたり、依存関係管理（脆弱性、バージョンの衝突、追加のメンテナンス）とか。

自分はViteと、いくつかのQOLライブラリ（use-queryとrouting）と一緒に"vanilla"なReactを使ってるけど、そんなトラブル全然ないよ？

useQueryがあれば、fetching/cachingに関する問題の99%は解決するし、複雑なインタラクティブアプリじゃない限り、state管理も問題にならない。

AIコーディングも、しっかりしたアーキテクチャのガイドラインを実装して、レビュー（AIを使って）でそれを守らせれば問題ないよ。

VS CodeでReactアプリを見ると、脳みそが痛くなるのが想像できる。
ブラウザ上でアプリみたいな体験が必要な、複雑な大規模システムには役立つかもしれないけど、ユースケースの80%では、JSフレームワークを使わないのが一番良いと思う。

わかるわー。Web Componentsとフレームワークなしで作業してた時は最高だった。マジで最高。さらに、依存関係のないxstateライブラリだけを使ってた時はもっと良かった。

唯一の問題は、物事を早く終わらせるために、独自のフレームワークを少し書きすぎたことだけど。でも、React Hooksとか、useCallbackとか、コールバックのメモ化とかで苦労してる時、マジで恋しくなる！マジで最悪！

ピュアなReactはマジでミニマルだよね。

おー、またね！

どんな機能も複雑さを増すのは確か。でも、既存の「退屈な」技術で抱えてた問題を解決するために、こういうものが発明されたんだよ。

また同じ問題にぶつかると思うし、Next.jsを再インストールするまで、たぶん1、2日もかからないんじゃないかな（笑）。

てかさ、SPAやめるべきだよ。手掛けるレイヤーが多すぎる。サーバーコンポーネントを使うべき。Reduxもいらないし、クライアントサイドの状態管理の塊もいらない。インタラクティブな部分だけCSRを使って、サーバーから状態を注入すればいいんだ。

DjangoやRailsみたいなフルスタックアプリケーションフレームワークで、もっとシンプルな時代に戻りたいよ。htmxをちょっと足せば、ほとんどのプロジェクトで90％はいける。

一番大事なのは、実際の要件を解決すること。つまり、技術の選択はプロジェクトによって自然と変わってくる。でも問題なのは、銀の弾丸みたいに魔法のフレームワークに頼って、実際のエンジニアリング/プログラミングの部分を忘れちゃう人が多いってこと。

一番うまくいく方法で、常識的に考えればいいんだよ。

その通り。アプリの複雑さによって適切なツールは変わると思う。それ以上に、そのアプリが最初はシンプルでも、将来的に複雑になる可能性があるかどうかを想像できるかどうかも重要だよね。

あと、シンプルなアプリにReduxやSSRは必要ない。React + Vite + SWR（キャッシュ付きの5kbの状態管理ライブラリ）+ wouter（基本的なルーティング）で十分なことが多い。

気になるんだけど、Svelte5も検討した？

同じことに気づいたよ。最初はPHPから始めて、みんなと同じようにReactとかに乗り換えた。簡単な「近日公開」ページでさえ、モダンなフレームワークに頼るようになってた。
今はそこから少し抜け出して、ピュアな状態を見直してる。複雑なバックエンドのためにRustも学ぼうと思ってる。

JavaScriptを一切使わないようにすると、人生はもっと良くなるよ。

リアクティビティ、パフォーマンス、開発/メンテナンスのしやすさの点で、Solid.jsが最高の妥協点だと思う。React/Nextの無駄なバンドルもないし。

Vanilla JavaScriptはすごく進化してて、マジですごい。最近は開発するのがすごく楽しい。Reactは永遠に大切にするし、仕事の大きなプロジェクトでは使い続けるけど、自分でやることはほとんど全部バニラのWeb技術でやってる。すごく楽しいし（それに、ブラウザが何をしてるか、すべてがなぜそのように動作するのかを教えてくれるから、フレームワークで問題をデバッグする必要があるときにすごく役に立つんだ）。

問題はNext.jsとか、React、Vueなどの上に構築されたフルスタックフレームワークだと思う。最小限のセットアップでいいんだよ。俺はReact + Vite.jsとTanStack Routerを使ってる。良いスキャフォールディングシステムを作れば、どんなアプリでも素早く構築して、追加コストなしでCDNにデプロイできる。

jQueryに戻ろうぜ

Svelteをチェックしてみるといいよ。マジ使いやすいから。

君はウェブの言語、ハイパーメディアを受け入れる準備ができているようだね。

これらのサイトのエッセイを読んでみて。

• https://htmx.org/essays/

• https://infrequently.org/series/reckoning/

• https://infrequently.org/2024/11/if-not-react-then-what/

そして、https://data-star.dev を使ってみて。

もう二度と振り返らないよ。

最近のウェブスタックは、ありえないくらい肥大化してる。ウェブアプリの99%はNext.jsを必要としないし、使うべきじゃない。

Reactはいつもひどい選択だ。Lit、Svelte、シグナル付きのAngularは実際に使える。

フレームワークを避けるのは、運転する代わりに歩くようなものだよ。
確かに、ドイツの7人乗りSUVを運転するのは過剰だけど、トヨタを運転すれば間違いなく生活は楽になる。
抽象化を使えるのに、なぜバニラJSを書くことを気にするの？
僕は信頼できるソースからの基本的な依存関係が好きだし、毎朝新しいパッケージをインストールしないようにしてる。

めっちゃ同意。今、Go、quicktemplate（ただの慣れ。もっと良いものがあるかも）、PostgreSQL、sqlc、TypeScriptを使って自分のプロジェクトを進めてるんだけど、React、Angular、Emberは使ってないんだ。でも、将来クライアントサイドのロジックが増えたら、Svelteを選ぶかもしれない。

ReactとSvelteの経験はあるけど、プロジェクトを始める時はやっぱりVanillaJSとTypeScriptが好きなんだよね。

ちょっと同意。もちろんユースケースによるけど、「一部の人がオーバーエンジニアリングしてる」っていうのは的を射てると思う。

個人的には、最終的な目標に焦点を当ててる。俺の仕事はコンテンツウェブサイトだから、本当に重要なのはページの速度。インタラクティブ性は、みんなが言う「アプリ」に比べるとかなり控えめだから、JSフレームワークは一切使ってない。JSなしでできることは全部そうしてる。JSが必要な場合は、必要最低限にして、できる限り遅延させる。遅延できないものは慎重に扱う。

もちろん、SEOを気にしない人や、インタラクティブ性の高いウェブアプリを作ってる人は、この方向には進まないだろうね。必要な最終結果に最適なものを使うってこと。重要なのは、みんなが自分が使うツールや技術を理解してること。

怖いのは、どれだけ多くの、一応賢いCS卒の連中が、メタフレームワークに疑問を持たずに突っ込んでいって、一度にどれだけ複雑なことを処理できるかを自慢してるか、ってこと。まるでメスでもキメてるヒップスターウェブデベロッパーみたい。

俺もReactから、HTMXでJSX書いて、バックエンドでJSXコンポーネントをレンダリングするように切り替えたんだ。HTMXの呼び出しでコンポーネントを入れ替える感じでね。大規模プロジェクトでも小規模プロジェクトでもうまくいくし、何より軽くてメンテが楽。AIとの相性も抜群で、トークンもあんまり必要ないし。今じゃReactのプロジェクト開くと、フックとかステート、プロップス、依存関係とか読むだけで疲れちゃうわ。

結局はバランスが大事だよね。

最初は最小限の構成で始めて、本当にプロジェクトでよくある問題を解決できる場合にのみ、徐々に追加していくのが良いと思う。

それに、簡単なプロジェクトでReact、Redux、RTK、それに本格的なバックエンドを勧めるなんて、ちょっと考えられないな。