ReactのフレームワークとしてNext.jsを採用した3つの理由

「Reactの開発環境構築、CRA（create-react-app）じゃ不十分なの？」
「Next.jsがいいって聞くけど、その理由は？」
「Gatsby.jsとの違いは？」

Reactのフレームワークを調べると、上記のような疑問が浮かびますよね。

僕も同様にこの疑問を持ち、調べた結果、Next.jsという結論にたどり着きました。

ということでこんにちは、株式会社Playgroundのフロントエンドエンジニアの稲垣です。

この記事では以下の情報についてまとめ、解説していきます。

Reactでカンタンに環境構築できるCRA・Next.js・Gatsby.jsの違い

Reactは環境構築が大変です。

初学者に、Webpackやbabelの設定などはめちゃくちゃ辛いと思います。

しかし、以下のような環境構築のツールやフレームワークを使うとそのツラミから解放されます。

それぞれの違いの重要ポイントは、「いつコンポーネントがレンダリングされるか」です。

CRAはクライアントサイド（ユーザーがブラウザでページを表示した時に）レンダリングを行います。

難しいことを考えなくて済みますが、SEO的には最弱です。

一方、Next.jsはサーバーサイドレンダリングです。

ユーザーにページを表示する前に、サーバー側でコンポーネントをレンダリングしてから、見せていきます。

Googleなどのクローラー（ロボット）にもページ内のコンテンツを正確に見せることができるのでSEO的に強いです。

そして「静的サイトジェネレーター」と呼ばれるGatsby.jsは、ビルドする時点でコンポーネントをレンダリングし、静的ファイル化します。

なのでこの3つのうち、表示は最速と言われています。

それぞれ特徴があり、一長一短です。

その中でNext.jsを選ぶ理由をお伝えします。

ReactのフレームワークとしてNext.jsを採用する３つの理由

僕は今までずっとCRAでサクッと開発環境を構築して、クライアントサイドのレンダリングのみのSPAを開発してきました。

しかし、そろそろ「SEOも意識したSPAを開発したい…」と思った結果、Next.jsを採用しました。

Next.jsを採用した理由は以下の3つです。

①SSRと②ルーティングについて、別の機会に語りたいと思います。

③が個人的に大きな理由で、僕は「ユーザー同士がやり取りする」ようなWebアプリを開発する機会が多いからです。

確かに、ブログのような「データの更新頻度が少ない」SPAは、Gatsbyがオススメだと思います。

しっかりと比較検証したわけではありませんが、Nextよりも表示が爆速なはずです。
（むしろそこがGatsbyの得意領域だと思う）

ですが、ユーザーが自由にリアルタイムにデータを更新するようなサービス系のアプリの場合、Nextに軍配が上がるでしょう。

Gatsbyではデータの更新頻度が多いとビルドによる負荷が高くなると感じました。

なので僕はしばらくNext.jsを使ってみようと考えています。

今回はこんなところで！

ABOUT ME

稲垣 貴映

サーバーエンジニア兼Webフロントエンジニア。 新卒で独立系SIerに入社後、金融系システム基盤の構築・運用を3年間経験。 プログラミングを独学していた頃に、CEOの馬谷が開講していたSwiftスクールに通い、2019年9月に入社。 趣味はブラジル音楽の演奏。