前回

参考

Remix

Remix vs Next.js

SWR

SWR は、ページに再フォーカスしたタイミングや、タブ切替えで再びページを表示したタイミングで自動的にデータを再取得してくれる機能や、一定時間（インターバル）ごとにデータを再取得してくれる機能をはじめ、きめ細かい有用な機能がたくさん備わっている。

https://swr.vercel.app/docs/api

nukopy

Next.js、Remix を学ぶ前に

Why do you need Next.js or Remix instead of plain React：そもそも純粋な React の代わりになぜ Next.js や Remix が必要なのか
CSR、SSR、SSG、ISR

Next.js と Remix の比較における観点

Routing
Data Loading
Data Mutations
Use of Sessions and cookies
Error Handling
Styling
Image Optimization
SEO
Deployment
Others

nukopy

Next.js、Remix を学ぶ前に

Why do you need Next.js or Remix instead of plain React：そもそも純粋な React の代わりになぜ Next.js や Remix が必要なのか

必ずしも使う必要はないかもしれませんが、それには依存します。重要なのは、React アプリケーションがどのように機能し、どのような問題に遭遇する可能性があり、Next.js や Remix のようなフレームワークがそれらの問題をどのように解決するかを理解することです。

React のポイントは、シングルページアプリケーション（SPA）を作成できることです。ここでは、すべてのウェブページをレンダリングするために単一の HTML ファイルのみが使用され、ルーティングはクライアント側で維持されます。しかし、これは具体的にはどういう意味でしょうか？

最初のリクエストが行われると、ブラウザは一度にすべてのアプリケーションを含む HTML の箱ページを受け取ります。
事前にレンダリングされたコンテンツはありません。
ユーザーのナビゲーションがトリガーされると、JavaScript は要求されたルートに関連するコンポーネントとコンテンツのみを置き換えますが、HTML ファイルは同じままです。

簡単に言うと、どの JavaScript ファイルを読み込むべきか、そして現在のページをレンダリングするかを管理するのはブラウザです。つまり、クライアント側レンダリング（CSR）です。

CSR は、SEO、キャッシュ、初期レンダリングの遅さを気にする必要がないアプリケーションを作成するために非常に便利で有用です。

初期レンダリングの遅さ - ユーザーが最初に訪れたとき、最初のコンテンツのページが読み込まれるまでに長い時間がかかることがあります。これは、JavaScript が読み込まれ、すべてがレンダリングされるまで、彼らに空白のページを表示させることを意味します。
SEO - 単一の HTML ページのみを持つため、コンテンツを検索エンジンやソーシャルメディアのボットによってインデックス化するのが非常に難しいです。
キャッシュの問題 - 最初のレンダリングで利用できないため、HTML 構造をキャッシュすることができません。

この時点で、SPA が悪魔のように思えるかもしれませんが、多くの企業が使用する内部アプリケーションや、彼らが販売するアプリケーション製品について考えてみてください。

Next.js や Remix は、SPA の動作方法を活用しながら、先ほど述べた 3 つのポイントを失わないようにしたいときに登場します。強みは、ウェブサイトをクライアントに送信する前にサーバーサイドでレンダリングできることです。

nukopy

CSR、SSR、SSG、ISR

(2021/01, Zenn)【Next.js】CSR,SSG,SSR,ISRがあやふやな人へざっくり解説する

(2020/11, Qiita) Next.jsにおけるSSG（静的サイト生成）とISRについて（自分の）限界まで丁寧に説明する

CSR, Client Side Rendering

Pros
- リッチな UI、UX
Cons
- レスポンスデータの肥大化により訪問時のデータのロード時間がかかる→レンダリングにかかる時間の増加
- JavaScript の肥大化によりクライアント側で処理する JavaScript が膨大になる→レンダリングにかかる時間の増加
- ページのレンダリングをするにあたり、ユーザの端末のスペックへの依存が大きい

ただ、クライアントサイドでのレンダリングを行う場合、クライアントに対して JavaScript を送信することになるため、アプリケーションが大きくなるとクライアントで処理する JavaScript の量が膨大になり、レンダリングにかかる時間、つまりユーザーにページが表示されるまでの時間が長くなってしまうという問題が発生します。特に、ユーザーが使っているデバイスの CPU の処理能力が高くない場合にこの問題は顕著になります。

SSR, Server Side Rendering

SSR, Server Side Rendering
- CSR のデメリットを改善するため、ページのロジック（API へのデータフェッチ）とレンダリングを（クライアントではなく）サーバ上で実行し、サーバ上で HTML を生成し、それをクライアントに返却するという方式
- React でサーバーサイドレンダリングを行えるフレームワークが Next.js で、ほんの少し前までは Next.js といえばもっぱらサーバーサイドレンダリングのためのフレームワークという印象だった
- 例
  - テンプレートエンジンを利用した MPA（Flask + Jinja、Express + Pug）

Pros / Cons

Pros
- JavaScript を大量にクライアントに送信するという問題は回避できる
- 重い処理をサーバ側で処理できるため、ユーザ端末よりもスペックの高いコンピュータで演算処理を行うことが出来る
Cons
- サーバーサイドレンダリングであっても、ユーザからのリクエスト（アクセス）ごとにサーバ側で演算を行う以上、オーバーヘッドが発生することは避けられない

→ SSR の次に注目されたのが静的サイト生成（SSG、Static Site Generation）

SSG, Static Site Generation

CSR も SSR も結局はユーザからのリクエストに応じて「動的に」アプリケーションのロジックを実行し、クライアント側、またはサーバ側でレンダリングを行う。この処理を行うことが Web ページの表示速度を下げる主要な要因である。

となると、あらかじめレンダリングを行なっておいて、ユーザからのリクエストに対して、すでに構築済みの HTML を返却するだけという形を取れば高速な応答を実現できるはず。これが SSG（静的サイト生成）の発想である。

SSG, Static Site Generation
- Web アプリケーションをビルドするタイミングでレンダリング処理を行なってしまい、そのとき（＝ビルド時）に各ページの HTML ファイルを生成する。そして、ユーザからのリクエストに対してはその HTML ファイルを返す。
- SSG ではアプリケーションをビルドするタイミングでデータ取得を行い、そのデータを使用して HTML を生成する。
- SSG の力を引き出すためには、既に生成済みの HTML を都度アプリケーションサーバから返却するのではなく、CDN に HTML ファイルのキャッシュを配置しておき、各ユーザに地理的（ネットワーク的）に近い CDN からそのキャッシュを返す、という方法を取ることが有効であり一般的。

Pros / Cons

Pros
- 静的に HTML 生成することによりページの表示速度が上がる
- CDN を活用することによりページの表示速度が上がる（特にこっちの寄与が大きい）
Cons
- データの更新頻度が低くなり、ユーザが最新のデータを取得できない可能性がある（結果整合性）。特に、リアルタイムにデータが更新されることを期待されるようなページには不向き。

→ SSG のデータ更新の問題を解決しようとするのが ISR

ISR, Incremental Static Regeneration

ISR, Incremental Static Regeneration; ISR)
- SSG の挙動に加えて、一定時間ごとにバックグラウンドでデータの再取得およびページの再レンダリングを行い、HTML を再生成 (regenerate) する手法

nukopy

データフェッチングライブラリ：SWR

SWR は、ページに再フォーカスしたタイミングや、タブ切替えで再びページを表示したタイミングで自動的にデータを再取得してくれる機能や、一定時間（インターバル）ごとにデータを再取得してくれる機能をはじめ、きめ細かい有用な機能がたくさん備わっている。

https://swr.vercel.app/docs/api

nukopy

Next.js と Remix の比較における観点

Routing

Data Loading

Data Mutations

Use of Sessions and cookies

Error Handling

Styling

Image Optimization

SEO

Deployment

Others

Next.js と Remix を選択する際に考慮すべき他の点もありますが、ここでは私の意見として、プロジェクト開発時に最も影響が大きいと思われるものを集めてみました。
しかし、もう少し詳しく知りたい場合は、この記事で触れていない点について簡単にまとめてみます。

ライブリロード。Next.js はホットモジュールリローディング（HMR）を使用し、デフォルトで有効になっています。一方、Remixでは、コードが変更されるたびにアプリケーションをリロードするように、root.tsx にコンポーネントを追加する必要があります。
Remix はクッキー、セッション、認証をサポートしていますが、Next.js はそうではなく、外部ライブラリを使用する必要があります。
Next.js はフォントとスクリプトの最適化を組み込みでサポートしていますが、Remix はそうではありません。
どちらも箱から出してすぐに TypeScript を使用できます。(out-of-the-box, いわゆるプロジェクト初期化時点で設定無しで TypeScript を使用できるよってこと)
Remix はほとんどの機能を JavaScript を実行せずに動作させることができますが、Next.js はそうではありません。
Remix では、ネストされたルートの内部に独立したルートを含めることができます。
どちらも Tailwindcss と迅速に連携でき、それを実現するための独自のガイドがあります。
Next.js は国際化ルーティングを組み込みでサポートしています。
Next.js は AMP を箱から出してすぐにサポートしていますが、Remix はそうではありません。