React周りの色々なメタフレームワーク等を触った浅い感想2024, 2025

はじめに

2024年あたりから仕事やら検証でReact周りのメタフレームワークを色々と触るようになりました。節操がないとも言います。
利用目的というか実現したかったこととあわせて使用した浅〜い感想・思い出を書いておこうと思います。
ミカン片手に読むレベルな内容の記事です。

Next.js (App Router)

実現したかったこと:

• Reactでモダンな開発がやりたい

最初は「とりあえず人気そうだから」という理由でNext.jsを使っていました。
意外と特に困ることもなく楽しい開発体験でした。
あるいは既に慣れすぎていて昔のことを忘れているだけかもしれません。

プロダクトが頓挫したためにデプロイには至らず。

デプロイする段階になったらVercelが高いだのAWSにデプロイするのは辛いだの特定の機能が動かないだ、色々と悩みが出ていたであろうと思います。お花畑で踊っていたら終わっていました。

デプロイに至らず。じゃなくてどう考えても機能を増やす前にミニマムでデプロイして、早い段階からインフラのことを考えた方がいい。

Astro (SSG)

実現したかったこと:

• PlaneなHTML/CSS/JSで書かれた重複コードまみれの静的サイトを見直したい

Astro独自の文法にビビりつつの開発でしたが、いざ振り返るとライブラリとして比較的落ち着いていて素晴らしい選択でした。
検討した当時はSSGするなら「Next.jsでStaticExportするか、AstroでSSGするか」みたいな風潮だった記憶があるんですが、僕的にはAstroの方が好みでした。

今も本番環境で元気に頑張ってくれています。

2025年末でも新規にSSGするならAstroを選びます。
なんなら2023年にNext.js(Static Export)で作ったものもリプレイスしたいくらいには気に入っています。

Remix, React Router v7 (SPA mode)

実現したかったこと:

• サクッとSPAをつくりたい

元々Next.jsのSPAモードを使ったことはあったんですが、RSCやらが出てきた頃に「もうNext.jsチームはSPA/Static Exportに積極的ではなさそうだ。」みたいな話（今となってはうろ覚え。真偽不明なのでアテにしないでくださいね。）があり、じゃあ別のものを探そうというタイミングでした。

というところでRemixを触ってみました。触ってる途中でReact Router v7との統合が完了してました。

使ってみるとSPAでの制約が多く、やりづらかった印象でした。
ここはNext.jsと変わらないんじゃないかと思います。

あと最大の問題として、AIでガシガシとコードを書く時に、統合によって名前が変わったことがどうしても辛かったです。AIに甘えるのがよろしくない。

なんだかんだ本番環境までデプロイしました。

TanStack Router

実現したかったこと:

• TauriのUIのためにサクッとSPAをつくりたい

React Router v7から鞍替えし、また別のものを探した次第です。
Tauriの話は長くなるので今回は割愛します。

TanStackシリーズはフルスタックなTanStack Startを擁する一方で、TanStack Router含めそれぞれのライブラリが独立しているのが魅力的でした。

使用感は最高でした。型安全なルーティングとloaderがお気に入りです。
上述した通りライブラリが独立しているからこそ、ドキュメントもRouterのみで独立できています。ここが素晴らしい！
ドキュメントを読んでいてNext.jsやRemixのようにSPA独自の制約がなく、サーバの都合を考えずシンプルにSPAをやれることへのありがたみを強く感じました。

2025年末現在でも新規にSPAを作るならTanStack Routerを採用すると思います。

こうして作ったTauri製モバイルアプリはどうにかこうにかAppStoreに公開されています。

Hono, Honox

実現したかったこと:

• StaticSiteをデプロイするときにサクッとAPIも添えたい
• Honoでjsx返せるならNext.jsより気軽にサーバサイドレンダリングできて嬉しそう？！試したい

世間の流行から少し遅れてHonoを触りました。
Cloudflare Workersへのデプロイの楽さ・お金の掛からなさは革命的でした。今でも後述する Hono + Astroの形式で本番環境でお世話になっています。

jsxが返せるぞ。ということで色々チャレンジしてみたかったんですが、スタイリングがTailwindかCSS in JSということで、個人的に好みなCSS Modulesが思うように使えなかったのが渋かったです。

ついでにHonoのせいではないのですが、Next.jsをメインに使っていたせいで、自分の考え方がNext.js基準になっていたのは結構困りどころでした。
実装したいことを突き詰めていくと、Island Archtectureを実現する必要性があり、それにはHonoxを使わないといけなかったり。
Honoxを本番環境で使うにはまだ早いんじゃないか。自分で直せない問題があったら辛いな〜。という情けない理由でHonoxは断念。

ということでjsxを返す部分は使わずに終わりました。
機会を見て再度チャレンジしたいです。

Hono + Astro

実現したかったこと:

• StaticSiteをデプロイするときにサクッとAPIも添えたい

HonoでStaticSiteを表示するならHTMLをrenderするとか色々方法はあるのですが、どうも取り回しが好みではなく、最終的にAstroでSSGしたコンテンツのディレクトリをHonoのStatic assetsに指定する形式で運用するようになりました。

料金・デプロイ体験含めて便利で気に入っています。
似たようなことをする場合今後もこの形式でやっていきたいです。

OpenNext.js (Cloudflare Adapter)

実現したかったこと:

• Next.jsを安く楽にデプロイしたい

結局、Honoxにビビり、Next.jsでRSCを使う方針に回帰しました。SBR(スティール・ボール・ラン)を思い出します。

『一番の近道は遠回りだった』

そんななかVercel以外にもデプロイしやすくなるOpenNextというものがあるらしいぞ。ということで使ってみるとこれが大変ありがたいものでした。
既存のNext.jsアプリをベースにいじって1, 2日でデプロイ出来ました。恐ろしいです。最高です。
感謝のあまり珍しく関連OSSのDocsに地味Contributeをするほどでした。
逆についぞVercelにデプロイすることなくここまで来てしまいました。申し訳なく思っています。

ただデプロイしようと準備している数日後にRSCの脆弱性の話が出てきたことはなかなか不吉でした。

サクッと本番環境に出しています。年末年始の平穏を祈っています。

おわりに

色々触ってきましたが、ライブラリをコロコロ変えずに一つのものを腰を据えて習熟したほうがいいと思います。まるで職歴がハチャメチャな履歴書状態です。
変に道具にこだわるのではなく、プロダクトのことを真剣に考え、本質的な価値創出に繋がる開発していきたいですね！！！！！！！！

……

来年の自分が迂闊にTanStack Startに手を出さないことに期待します。