$30 off During Our Annual Pro Sale. View Details »

React フレームワークの 動向と選定基準

React フレームワークの 動向と選定基準

まずはじめ React に焦点を置き、昨今のフロントエンドでどのようなフレームワークが選択肢にあげられるのかについて紹介します。続いて、技術選定を行う際に、どのようなことを考えるべきかについて話します。最後にこれまで話した点を踏まえて、私が実際に技術選定を行った際にどのような選択をしたのか実践的な内容について触れたいと思います。

azukiazusa

April 01, 2024
Tweet

More Decks by azukiazusa

Other Decks in Technology

Transcript

  1. ほとんどのサイトやアプリケーションで 必要な機能の再発明を防ぐ • ルーティング、データ取得、コード分割... ◦ React は UI ライブラリである •

    React の公式ドキュメントでもフレームワークを使うこ とが推奨されている https://ja.react.dev/learn/start-a-new-react-project
  2. React フレームワークの紹介 • Next.js(Pages Router) • Next.js (App Router) •

    Remix • Remix(SPA モード) • React + Vite(バンドラー) • Gatsby • Astro
  3. Next.js(Pages Router) • Next.js v13 以降で登場した App Router に対して Pages

    Router と呼ばれる ◦ Pages Router が非推奨というわけではない • ページごとに SSR・SSG・ISR の中からレンダリング方 式を選択できる
  4. Pros • 画面ごとのパフォーマン スの最適化 • 枯れたフレームワークと 言える • <Image />

    などの様々 な最適化 • 動的なページを必要とす る SPA には向いていな い • ISR を採用する場合、イ ンフラが制限される Cons
  5. Next.js(App Router) • Server Components や Streaming、Server Actions の ような

    React の最新の機能をいち早く使える ◦ React Canary: Meta 外での段階的な新機能導入 https://ja.react.dev/blog/2023/05/03/react-canaries • よりよいユーザー体験を追求できる
  6. Pros • 最新の機能を利用でき、最も 高いユーザー体験を提供でき る • デフォルトでリクエストの キャッシュ、重複排除機能が 備わっている •

    コロケーションパターンを採 用しやすい • 運用する難易度高い • キャッシュの仕様が難解 • undocument な挙動も 多く、ソースコードを読 み解く覚悟が必要 • エコシステムが整ってい ない Cons
  7. Pros • Web 標準の API を採用 しているため、学習コス トが比較的緩やか • フィーチャーフラグによ

    るリリースの安定 • Next.js(Pages Router)と比較して採 用事例はまだ多くない • ISR やリクエストキャッ シュのような高度な機能 は提供されていない Cons
  8. Remix(SPA モード) • 最近 Stable になった • React + React

    Router + Vite の延長のような使いごこち • Remix の既存の API をほぼ利用できる
  9. Pros • インフラは静的ファイルの配 信サーバー • SSR をしたくなったときに移 行しやすい • ルーティング、コード分割な

    どフレームワークに求めれら れる機能が揃えってる • ユーザー体験や SEO が 犠牲になる Cons
  10. React + Vite • フレームワークを採用しない選択肢 • 現代ではバンドラとして Vite が採用されるのが主流 •

    サーバーを使わない SPA アーキテクチャを採用する場合 選択肢に入ってくる
  11. Pros • サーバー運用コストや、 フレームワークの学習コ ストを抑えられる • 既存のバックエンドと統 合しやすい • ルーティングやデータ取

    得のライブラリを統合す る作業を自分で行う必要 がある ◦ 結局独自のフレーム ワーク作って学習コス トの問題が発生しがち Cons
  12. Gatsby & Astro • SSG に特化されたフレームワーク • 静的なドキュメントサイトが主な用途 • Gatsby

    は豊富なプラグインがあり、多くの設定ができる • Astro は正確には React のフレームワークではなく、UI ライブラリの一部として React を使える
  13. プロダクトの特性 • EC サイト?社内システム?BtoB 向けの SaaS? • EC サイトでは LCP

    スコアが収益に直結する ◦ https://web.dev/case-studies/rakuten?hl=ja ◦ パフォーマンスの最適化のためにコストを払える • BtoB 向けの SaaS では App Router は too much になりがち ◦ パフォーマンスを重視する優先度は下がる ◦ 常に最新のデータを表示するため、キャッシュが全く不要
  14. 前提条件 プロダクトの特性 • SaaS アプリケーション • キャッシュは不可能 • グラフの表示が主で、クライアント でデータを取得することが多い

    プロジェクトの優先度 • 多くの工数を割けない 開発メンバーのスキルセット • 開発メンバー全員がすべての領域 を触る 社内の採用事例 • Next.js(Pages Router)が多い
  15. React + Vite を採用 • パフォーマンスは最優先事項ではない ◦ 開発メンバーに対する教育コストを払うに値する材料ではない • フレームワークのリプレイスに工数を割けない

    ◦ 既存のバックエンドと統合しやすいのがメリット • 社内のその他のプロダクトとは特性が異なるので、採用事例は重視 しなかった • 技術選定をした当時 Remix SPA モードは Stable ではなかった