Next.jsのデメリット【欠点】を理解する
Webテクノロジーは、ほぼ毎月のように成長し、変化し続けています。
決定を下すには、各オプションの長所と短所を事前に知る必要があり、自信を持って適切な選択を行うことはますます困難になってきています。
本日はReactを利用したフレームワークであるNext JSの欠点に焦点を当てて解説していきます。
Next.jsとは
Next.jsは、以前はZEIT
として知られていたVercelという名前の会社が所有しており、そのオープンソース開発プロセスを主導および維持しています。
Next.jsの最初の作成者は、VercelのCEOであるGuillermo Rauch氏でした。
Next.jsのサーバーレスアプローチにより、Vercelを使用してWebサイトおよびアプリをデプロイできるため、ホスティングコストが大幅に削減され、パフォーマンスとサイトの読み込み速度が向上します。
Next.jsの優れた点の1つは、アプリケーションの展開段階と運用段階の両方に機能を提供することです。
静的Webサイトは、Webと同じくらい古いものです。
しかし、JavaScriptの台頭によって、静的サイトは市場でより動的になりました。
ビルド時のWebサイトまたはアプリのレンダリングは、静的な生成です。
その結果、HTMLやCSSファイル自体とJavaScriptなどのアセットを含む静的ファイルのコレクションが作成されます。
私たち開発者が知っているように、JavaScriptベースのWebアプリは、実行時にブラウザでReactやスクリプトなどのライブラリを実行することによって機能します。
静的生成では、Next.jsなどのテクノロジーを使用して、ブラウザでの表示と同様のページをコンパイル時にレンダリングし、それにより初期ロード時にコンテンツ全体を提供できます。
Next.jsは、最も人気のある静的サイトジェネレーターの1つにもなりました。
Netflix、Uber、Starbucks、およびTwitchは、Next.jsを使用する世界最大かつ最も有名な企業のほんの一部です。
高速でSEOに適したWebサイトおよびアプリケーション(Jamstack Webサイト含む)を構築するための現在最高のフレームワークの1 つです。
Node.js
とBabel
に基づいて、Next.jsはReact.jsと統合してSPA開発を行い、Reactコンポーネントのサーバー側レンダリング (SSR)または静的生成(SSG)ソリューションを提供します。
Next.jsは「バックエンドですか??」と聞かれる時がありますが、これは場合によります。
小規模なプロジェクトや単純な要件の場合、Next.jsのみを使用してバックエンドの機能を実装することも可能です。Next.jsにはAPIルートと呼ばれる機能があり、サーバーサイドのエンドポイントを作成することができます。
これにより、データの取得や処理などを行うための簡単なバックエンド機能を提供します。
しかし、Next.jsは、バックエンドとしての機能も持っていますが、完全なバックエンドフレームワークではありません。
大規模なプロジェクトや複雑な要件の場合、Next.jsだけではなく他のバックエンド言語やフレームワーク(PHP、Node.js、Rubyなど)との組み合わせも検討する必要があります。
特にデータベースやAPIの処理、認証、セキュリティなどの高度なバックエンド機能が必要な場合は、他のバックエンドテクノロジーを併用することが推奨されます。
ただし、Next.jsはフレームワークとして主にJavaScriptとReactに焦点を当てており、PHPやLaravelなどの言語やフレームワークとの統合に関しては少し複雑になるかもしれません。
つまり、Next.jsはクライアント側のビュー(フロントエンド)とサーバーサイドの機能(バックエンド)の両方を担当することができます。
したがって、Next.jsはフロントエンドのReactとバックエンドの機能を統合するフレームワークであり、サーバーサイドレンダリングや静的生成などの特徴を提供します。
バックエンドフレームワークとしての使用も可能ですが、完全なバックエンドフレームワークではありませんので勘違いしないように注意してください。
Next.jsを使用すると、サーバー側のレンダリングを使用してコンテンツをサーバーに事前に保存するReactアプリを構築できます。
事前にレンダリングされたHTMLページと完全にインタラクティブなWebサイトまたはアプリと対話します。
このアプローチにより、訪問者はインタラクティブなサイトを3秒以内に見ることができます。
このパフォーマンス結果は、ReactのCreate-React-AppアプリでのCSRとして全ページ読み込みのLighthouseの結果で比較すると分かります。
Next.jsでSSRアプリケーションでの全ページ読み込みのLighthouseでの結果では、(0.8秒)です。
一方でReact単体でのアプリ作成では、(6.5秒)です。
この結果によって、SSRがCSRよりも高速にHTMLをブラウザに提供します。
Googleの First Meaningful Paintのドキュメントによると、この指標は「ユーザーがページの主要なコンテンツが表示されていると感じる時間を識別します」と記述されています。
Lighthouseは、これらの違いを視覚化するのにも役立ちますので是非ご自身で確認してみて下さい。
Reactを使用している開発者にとって、自然な次のステップはNext.jsです。
Next.jsを学ぶべき理由の、その主な理由はNext.jsが Reactの上で開発されているという事実です。
これには、Reactで発生する問題を解決する多くのネイティブ機能があるためです。
Next.jsは急速に開発されてます、多くの機能が追加されており、それによりNext.jsは優れたフレームワークですが、開発に関してはいくつかの欠点があります。
Next.jsは完璧なフレームワークではありません。
Next.jsの短所
Next.jsは大規模なサイトやアプリの場合ではビルド時間が長い事です。
開発者は、Next.jsがサイトをビルドするのに時間がかかり、いくつかの回避策がある一方で、一部のユーザーを思いとどまらせる可能性があると不満を漏らしております。
また、基本的な知識がないままNext.jsに入ると、必要が生じたときにフレームワークを変更する機会がなく、閉じ込められる可能性があります。
コミニュティサポート問題もございます。
開発者コミュニティは、Reactに比べて小規模です。
ですが、Next.jsの経験がある開発者が少ないと言う事は、Next.js開発者の必要性が高まっており、開発業界で際立った存在になりたいと考えている開発者にとってチャンスが訪れている事にもなります。
Next.jsではプラグインが少ないのも問題の1つです。
例えば、Bootstrapやその他のDOM操作をサポートするライブラリなどの一部のJavaScriptプラグインおよびライブラリは、クライアント側でのみ実行するように設計されており、開発者はクライアント側およびサーバー側の検証を処理して、いつインポートして使用するかを決定するための追加の労力を必要とします。
一方、Gatsby.jsは多くのプラグインが利用可能であり、より柔軟なプラグインエコシステムを提供しています。
ただし、Next.jsでもプラグインを自作することは可能です。
Next.jsのフレームワーク自体が柔軟な構造を持っているため、必要に応じて独自のプラグインを開発することができます。また、Next.jsの公式ドキュメントやコミュニティのサポートを通じて、プラグインの作成方法や既存のプラグインの活用方法についての情報を入手することもできます。
Gatsby.jsと比較すると、Next.jsのプラグインエコシステムはやや限定的であると言えます。
Next.jsはReactに基づいているため、Reactに関するスキルセットが必要です。
既存の開発チームにとっては適切なスキルセットがある場合に採用することが重要です。また、Next.jsを採用することで、開発チームに新たな技術的なトレーニングやスキルアップの機会を提供することも考慮すべきです。
技術的な短所
ルーティングに関して大規模なアプリ開発では、Next.jsはあまり柔軟ではありません。
デフォルトのアプローチはページベースで、これらのページをサーバー側、クライアント側、または静的のいずれかで生成するかを指定できます。
これは単純で小規模なアプリケーションには適しているので柔軟性があると言えますが、より複雑で大規模なものが必要な場合は、さらに多くのコードを記述してNode.jsサーバーを利用する必要があります。
つまり、Next.jsがファイルルーターのみを使用するように制限されていることを考慮すると、ルートでの動作方法を変更することはできません。ルーティングの方法を変更することは制限されます。
動的ルートを使用する場合、Node.jsサーバーが常に必要です。
現在、Next.jsは、高速な応答時間、効果的なコード分割、サーバーサイドレンダリングなどを提供します。
これらすべての優れた機能は、すべての要求に応答するNode.jsサーバーの助けを借りて提供されているためです。
Reactとは異なり、Next.jsは動的ルーティングを容易にサポートしておらず、セットアップが複雑になる可能性がございます。
独自のルーター以外のルーターを使用する場合または Reduxを追加する場合では多用途ではないことがわかります。
そして、動的ルートを作成するための専門的知識を持っている必要もあります。
ですが、これらの問題は現在、日々取り組んでくれており徐々に修正されてきております。
ルーティングに関しては、将来性を考えると頭を悩ます程の問題ではなくなると思っております。
SSRでの欠点もございます。
サーバー側のレンダリングは、JavaScriptのWebサイトデフォルトではないため、コストがかかり、リソースを大量に消費します。
したがってサーバー側では、ユーザーとボットのためにコンテンツをレンダリングするという完全な負担を負います。
つまり、大量のリクエストや複雑な処理が必要な場合、サーバーの負荷が増加する可能性があります。
サーバー側のレンダリングでは、静的サイトの生成に理想的ですが、頻繁なサーバーリクエストとページ全体のリロードによって、追加の複雑なアプリケーションでのページレンダリングが遅くなる可能性がございます。
Next.jsは意見が分かれます。
開発者として、独自の方法で行っていく必要があります、これは一長一短でありどちらも含まれる可能性があります。
アプリケーションの作成方法に制限があり、回避策を余儀なくされる可能性があります。
プロジェクトにNext.jsは必要か?
この質問に対する答えは、もちろん場合による
が正解となります。
一部のプロジェクト要件では2022年には、ほとんどのアプリケーションにとって最適なフロントエンドフレームワークであると言えます。
しかし、Vue、React、WordPress、Laravel、およびその他の優れたテクノロジーを使用する場合があります。
おそらく、どのフレームワークを使用するかはすでにわかっていると思いますが、まだ急いで決定を下すことはせず、それらのユースケースを確認して、決断できるようにしてください。
最終的にはプロジェクトのニーズに依存します。
コーディング言語やフレームワークは万能ではなく、それぞれ異なる特性や用途があります。プロジェクトの要件と目標に合わせて最適なツールを選択することが成功の鍵となります。
最後に
Next.jsには、多くの素晴らしい機能がありますが、考慮すべき欠点もございます。
ですが、GitHubコミニュティチームが問題の修正に非常に積極的に取り組んでいるため、短所は日々少なくなっています。
それは、主な短所であるルーティングの問題とビルド時間の解決に取り組んでくれています。
Next.js 10以降では、起動時間を最大24%改善し、処理時間をさらに40%削減してくれました。
そこからNext.js 11では、起動時間をさらに短縮するための別の最適化が含まれています。
Next.js 12では、多くの問題が修正されています。
具体的には、ビルドパフォーマンスの改善、TypeScriptサポートの改善、React Componentsの導入、およびAPIルートの改善などが含まれます。
また、Next.js 12では、Node.js 17のサポートが追加され、Vercelのデプロイプラットフォームでのビルド時間が短縮されるなど、多くの改善が行われています。
そして、Next.js 13では、新しいイメージコンポーネント、新しいルーティングAPI、および新いサーバーサイドレンダリングAPIなど、多くの新機能が追加されています。
Next.js 13のアップグレードは以下で詳しく解説していますので参照してみてください。
Next.jsを最新の状態に保つだけで、これらの驚くべき速度の改善が得られます。
Next.jsは依然としてReactに基づいています、Reactを改良しており、非常に高速なWebアプリとSPAを構築できます。
SSRおよびSSG機能は読み込み時間を短縮し、確実なパフォーマンスとSEOの向上を実現します。
ただし、Next.jsを選択した場合は、アプリをサーバーでホストする必要があり、インフラのサイズと複雑さが増すことに注意してください。
最終的に重要な事は、自分にとって意味のあるときにツールを使用することです。
ですが、選択は完全にあなた次第であり、あなたの目標と構築しているプロジェクトによって異なります。
本日は以上となります。
最後までこの記事を読んで頂きありがとうございます。
この記事が役に立ったら、ブックマークと共有をしていただけると幸いです。