この記事はログのように月日を重ねながら更新をかけていき、常にその時の最新の環境で自分だったらどんな技術選定をしたいかを残しておこうと思います。
大きな方向性
Vue or React の選択をすることになりますが、今回はコミュニティーや採用事例が多い React ベースで全てを考えていきます。 使われている数が多いというのはそれだけでかなりのアドバンテージです。周辺ライブラリが充実して、エコシステムが出来上がり、採用例が多い分 issue などが積極的に立てられ、対応されていくので、コミュニティーの大きさは重要な指標の一つになります。 また、学習コストや採用の面でもReactを経験してきている開発者が圧倒的に多数であることからも React ベースで選定していきます。
事業要件に合わせてメタフレームワークを選ぶ
ここで考えることは、そのアプリケーションに求められている要件次第で変わってきます。 ただ、概ね次の3つが自分が考えているほとんどのパターンに対応できるスタックです。
- Next.js
- Vite or Rsbuild + Tanstack Router
- Astro
それぞれの特徴とどんな時に使うといいか
- Next.js
これを選ぶメリットは開発速度の速さと、サーバーサイドとクライアントの両方のレンダリング戦略をシームレスに切り替えられる点です。オールインワンで何でもやってくれるので初期のセットアップが非常に簡単で、細かなライブラリの選定作業が省ける分、意思決定のスピードが非常に速くなります。それでいて、サーバー、クライアント、静的生成など様々なレンダリングパターンに柔軟に対応できるようになっているのが魅力です。
この豊富なレンダリングパターンをシームレスに書き換えられるメリットがあると、どんないいことがあるのでしょう？ 例えば、ドメインとかは同じでいいからちょっとした LP を追加したいんだよね。とか、このページは外部にも公開したいからSEOを意識して作って欲しいんだよね。といった要件が出てきた場合にも全てを柔軟に対応することができるようになります。 この例の場合は、LP は静的生成で、外部公開ページはサーバーサイドレンダリングで、そのほかのページはクライアントサイドでレンダリングしよう！と言ったことが簡単にできます。
この複雑な要件を高い開発者体験を持続させたまま達成できるのがNext.js の強みです。
しかし、これだけ柔軟に対応できるということは内部で何が起こっているのかよく分からないというブラックボックス的な現象にも度々ぶつかります。何でもラップしちゃって API として提供してくることもあります。
また、Next.js を使うということは SEO など主に、サーバー側で動かしたい理由がある場合に使います。その場合に Vercel 以外のクラウドプロバイダーで環境を立ち上げようとすると初期のセットアップだけじゃなく、運用していても難解なバグに遭遇したりと非常にコストが高いです。しかし、Vercel にデプロイすると料金面で高いという、これまた考えることが増えます。そのため、小規模~中規模なサイトの構築にはオーバースペックすぎる可能性が高いです。
- Vite or Rsbuild + Tanstack Router
これが使われているのは、toB 向けのサービスが多いでしょう。先ほどの Next.js は主にサーバーサイドで動かしたいニーズがある時に非常に有用な選択肢ということが分かったと思います。しかし、toB 向けのサービスは管理画面のような複雑な業務ロジックと状態が絡み合った UI をどう設計するかという React の設計力が試されます。このような場合に大事になってくるのは routing 周りとビルド周りの管理コストを下げることです。
そこで、ビルド周りには Vite もしくは、Rsbuild を採用し、routing 周りには Tanstack Router を採用します。Vite に関しては、Rsbuild よりもコミュニティの発達や採用事例の面で大きな利点があります。Rsbuild は、名前の通り Rust で書かれていることで、Vite に比べて、ビルド時間、開発サーバーの起動時間が非常に早いです。
routing に関しては、これまで react-router という選択肢が非常に根強かったですが、Remix の統合などを受け routing だけでなく、フレームワークへと進化していくところで求めていたものとは離れた感覚があります。
以上のことより、この Vite or Rsbuild + Tanstack Router の選択肢で重視していることは、各ライブラリの責務がはっきりしていて、代替の効きやすさとコミュニティの成熟度合いのバランスが取れた構成になっていることです。
この構成にする場合、仮にLPを作成したいなどの要望が出る場合は、別ドメインで一つLP用に別ページを作成するなどを検討して別管理するのがいいでしょう。 業務アプリケーションとは別で管理できていると外注できたり運用・保守が柔軟にできるようになって、疎結合でいいと思います。
- Astro
これまでは、比較的大規模なアプリケーションで性質が違うものに対するアプローチの仕方でした。しかし、世の中にはそこまで大規模なアプリケーションではなく、ホームページなど比較的小さかったり、中規模一歩手前というようなサイトもたくさんあります。そのような場合には Astro を使うのがいいでしょう。
Astro は React ベースというわけではありませんが、少し複雑なロジックをここだけ書きたいという要求が出たら部分的に使うこともできます。 このフレームワークの特徴は基本的には静的生成させて、部分的にリッチに見せたい場所に React を使うなどを柔軟にできるようになっている点です。
補足
今回ここで Remix の存在を触れなかったことについても簡単に補足しておきます。つい先週 Remix Jam で Remix の新たなバージョンが発表され、何となく Remix の進む道が見えました。それは React からの脱却と独自に Web 標準に近づくという道でした。
確かに、ここ最近の React は React というより Next.js チームがReactに侵食しているという感じで、少しサーバー寄りのアーキテクチャーの話ばかりをしていた感覚がありました。そこで Remix への期待も個人的には高まっていましたが、React からの脱却は大きな変化過ぎたため候補からは外れてしまいました。
また、React からの公式ブログで、 React がより幅広い団体によって管理されることが発表されたため、また現実のニーズに合わせた開発が行われていくという期待も持っています。
ここ最近でVite+が発表されたりと、フロントエンドは絶えず変化し続けるなと感じています。 なので、ある程度剥がしやすさも考慮した設計になっているといいんだろうなと。 その観点では2番目の選択肢のように、どこか一つの団体が管理しているのではなく、1つのライブラリが責務を持ち過ぎていないものを組み合わせて作っていくのが好みかもしれないと感じました。 そうすることで、Rustの登場により各種ツールが置き換えられていく波がきた時のように、柔軟に対応できるようになりそうだなと感じています。
結局、ほぼ変わらないのは HTML, CSS, JS という構造で、その次に変わりにくいのは TS, React で、それ以外については変わるという覚悟を持っていた方が良さそう