Gatsby、Gridsome、NuxtではなくNext.jsを選択したのはなぜですか？

新しいWebプロジェクトのフレームワークを選択するとき、このプロジェクトにどれだけ適しているかに関係なく、通常は使い慣れたツールを使用する傾向があります。私は正反対のことをしようとしています。機会があればいつでも新しい技術を試します。これらの実験の後で私は何を学びましたか？標準の静的サイトジェネレータ（SSG）ツールとしてNext.jsを使用するのはなぜですか？ この投稿では、さまざまなWebテクノロジーをどのように試したかについて説明します。それは、Jamstack内で適切なツールを見つけること、開発者に最適なものを正確に選択し、彼のプロジェクトにうまく統合する方法、なぜNext.jsを選んだのかということです。

Web開発での私の経験について

私はPHPとMySQLを使用してWeb開発の旅を始め、大学にいたときに.NETプラットフォームに切り替えました。タイプセーフティ、MVCモデル、コードデバッグ機能が気に入りました。そういうわけで、私は今後も.NETを使い続け、プログラミングとコンサルティングを行いました。しかし、私は徐々にJavaScript、特に初期バージョンのAngularに切り替えていました。



約2年前、私はほぼ完全にJamstackに切り替えました。Vue.jsは、最も使いやすいJavaScriptツールのように見えたので、詳しく調べることにしました。個人のウェブサイトを作りましたNuxt.jsを使用します。これは静的サイトジェネレータであり、現在はVue.jsアプリケーションを開発するための直感的なフレームワークと呼ばれています。このプロジェクトを終えると、Reactに基づいて静的サイトを構築するシステムであるGatsbyの最初のバージョンが出てきました。次のプロジェクトでGatsbyを使用して、Webエージェンシーをサポートすることを目的としたシンプルなプロジェクトであるKenticoAdvantageサイトを作成しました。これはReactでの私の最初の経験でした。そして、その時出会ったことは、本当に気に入らなかった。些細なことをする必要がある場合でも、非常に大きな困難が生じました。



私の次の開発は私自身の結婚式の場所でした。それから私はGatsbyとReactにもう一度チャンスを与えましたが、結局、ほんの数日後、Vue.jsのGridsomeフレームワークに切り替えました。当時、この静的サイトジェネレータは急速に人気を博していました。私は文字通り隅々で彼に出くわした。このSSGのおかげで、約3時間で簡単に機能するWebサイトを作成することができました。私はただ魅了されました。 Vue.jsは私の目にはもう少し成長しました。



その後、Sourcebitプロジェクトが登場しました。これは、さまざまなデータソースとSSGを組み合わせるために使用されるプラグインであり、データを変換して使いやすくする役割を果たします。そうは言っても、Next.jsはSourcebitでサポートされている唯一のJavaScriptベースの静的サイトジェネレーターでした。..。そのため、基本を学んだ後、別のプロジェクトでNext.jsを使用しました。

自分または他の人の経験に基づいたツールの選択

上記では、過去2年間で最も使用したツールについて説明しました。しかし、それらを比較すると、よくあることですが、そもそも迷わず配置できるものを選ぶことはできません。



あなたが次のプロジェクトに適したツールを選択する責任がある開発者であるとしましょう。プロジェクトの作業開始のタイミングは、選択したものによって異なる場合があるため、これらのツールの多くを使用して長時間の実験を行う余裕はありません。



自分の経験や他の人の経験に基づいてツールを選択できます。以前にAngularを使用したことがある場合は、最初にAngularを使用するツールを検討することをお勧めします。ずっと前にAngularを最後に使用した場合は、同僚に何を使用しているかを尋ねてください。確かに、そのような状況では、私は誰にも何も尋ねませんでしたが、すぐにVue.jsを選択しました。問題は、私の同僚全員が以前にReactで作業したことがあるということでした。したがって、結局、私はGoogleを使用して、発生する問題を解決する必要がありました。



フレームワークの選択に影響を与えるもう1つの要因は、プロジェクトのサイズです。ツールをテストして個人用サイトを作成する場合、作業で発生する質問は簡単です。それらに対する答えは通常、選択したツールのドキュメントに記載されています。しかし、あなたが企業プロジェクトを開発しているとしましょう。それらは部分的なビルドを使用し、プロジェクトの一部はサーバー上でレンダリングされ、多くのデータソースを使用します。作業中に問題が発生した場合は、ドキュメントの助けを借りてそれらに対処することができないため、同僚に質問するか、StackOverflowなどで回答を探す必要があります。



上記の3つのJavaScriptツールについて説明しました。ただし、Jamstackは必ずしもJavaScriptであるとは限りません。おそらくPHPまたはRubyがあなたに近いでしょう。自分に合った静的サイトジェネレータを見つけるには、次の表を参照してください。





まだ使っていないプラットフォームについては何も言えません。しかし、Vue.js、React、および関連する静的サイトジェネレーターに関する私の考えを共有することはできます。

Vue.js：GridsomeとNuxt.jsの比較

Vue.jsフレームワークは、その優れたドキュメントで知られ、有名です。 Gridsomeは同じ道をたどります。このSSGのドキュメントは非常によく書かれています。それはGridsomeで始める誰もが期待できるすべてを持っています。本当。このドキュメントを読んだとき、その作者が私の心を読んでいるように見えました。 GridsomeはGraphQLを使用します。したがって、データソースは特別なプラグインを使用してサイトに接続する必要があります。 Gridsomeは、データモデルを対応する名前のテンプレートに自動的に関連付け、ルーティングを整理します。初心者にとって、これは大きなプラスです。 Gridsomeは外部JavaScriptリソースを許可します。 「ベストプラクティス」のようには聞こえないことはわかっていますが、たとえば、HTML5UP.netなどのサイトからテンプレートをダウンロードした場合、このようなテンプレートには、ある程度のJSコードが含まれます。 Nuxt.jsでこのようなものが必要になったとき、私は困難に遭遇しました。結局、Vueの対応する機能を書き直さなければなりませんでした。



Gridsomeを使用した経験を要約すると、作業は簡単だったと言えます。フレームワークは私が必要なものを達成するのを助けました、私はこのプラットフォームが私の前に置くであろう障害と戦う必要はありませんでした。 Gridsomeを使用すると、わずか数時間で簡単に機能するWebサイトにアクセスできます。



Nuxtを使用する場合、最も難しい部分は、Vuexデータストアの操作の詳細を理解し、Vuex.storeを作成することでした。..。これらのリポジトリは、Nuxt.jsプロジェクトで使用されます。コンポーネントがデータを処理する必要がある場合は、すべてのデータが1か所に保存されているという事実から先に進む必要があります。もちろん、コンポーネントレベルでデータを保存することもできますが、異なるコンポーネントが同じデータを使用することがよくあります。その結果、コードの重複を避けるために、単一のデータストアを使用する必要があります。このようなストレージを実装するために、どこかから必要なデータを収集する特別なプラグインは必要ありません。たとえば、私はKentico KontentUIなしでCMSで動作するように設計された1つのプラグインを使用しました。それは間違いなく私の人生を楽にしてくれましたが、DeliverySDKでFetchAPIを使用することもできました。..。すべてがうまくいった後、私はこのパターンが好きだと気づきました。信頼性と柔軟性があります。私は、大規模なプロジェクトでの作業には、それを選択します。それを使用するには、最初に、それを知るために時間を費やす必要があります。



Nuxt.jsは、サーバー側のレンダリングとプレビューモードの両方をサポートしています。彼の周りには大きなコミュニティが形成されています。これらすべてから、Nuxt.jsはGridsomeよりも成熟したプロジェクトであり、Nuxt.jsは深刻なサイトに適していると言えます。



次の表に、GridsomeとNuxt.jsの長所（「+」でマーク）と短所（「-」でマーク）をリストして、情報を要約しましょう。

React: Gatsby Next.js

ギャツビーから始めましょう。このフレームワークの最も興味深い機能は、GraphiQLと呼ばれるGraphQLを操作するためのツールによって表されると思います。 GatsbyはGraphQLを使用します。また、GraphiQLを使用すると、サイトで使用されているデータを操作できます。このツールの重要性と有用性を十分に強調することはできません。これにより、開発者は使用されているデータソースのドキュメントを読む必要がなくなります。 GraphiQLを使用すると、データをインタラクティブに表示できます。データから、必要なものを選択できます。これにより、コンポーネントにコピーされる自動的に生成されたGraphQLクエリが生成されます。 Gatsby





でGraphQL



を使用してGraphiQLを操作することは、プラグインを探すことも意味します該当するデータソース用。確かに、そのようなプラグインは、ユーザーインターフェイスなしですべての主要なCMSで利用できます。 Gatsbyのもう1つの長所は、このフレームワーク用に膨大な数のプラグインが作成されていることです。 SEOから画像のプログレッシブロード、GraphQLスキーマのエクスポートまで、文字通りすべての場面に対応するプラグインがあります。



ただし、Next.jsを使用する場合、データを操作するための標準ツールが不足しています。その結果、開発者は、それぞれの特定の状況で何を使用するかを正確に把握するために時間を費やす必要があります。たとえば、同様の問題を解決するとき、私はこのリポジトリに触発され、「リポジトリ」パターンを使用しました。 GraphQLなしで生活できる場合、Next.jsはGatsbyが実行できるすべてのものなどを提供します。





Next.jsでのルーティング



Next.jsは、ファイルベースのルーティングモデルを使用します。これにより、なじみのないプロジェクトで作業する必要がある場合でも、ページやテンプレートを簡単に見つけることができます。このフレームワークを使用すると、静的ページと動的に生成されたページを組み合わせることができます。これらの2つのページ作成メカニズムは、1つのページに結合することもできます。これにより、マテリアルプレビュー機能の実装が大幅に容易になります。 GatsbyとNext.jsはどちらも、インクリメンタルビルドを作成する方法を知っています。ただし、Gatsbyの場合は、 Gatsby Cloudでサイトをホストする必要があります。これは、特別な要件で準備されたプラグインを使用した場合にのみ可能です。



Next.jsとGatsbyを比較すると、Next.jsがより小さなリリースバンドルを生成することがわかります。参考資料の検索やコミュニティメンバーからの質問への回答の取得について話す場合、実践が示しているように、GatsbyとNext.jsはこの点でほぼ同じように見えます。



GatsbyとNext.jsの長所と短所に関するデータを要約しましょう。

プラットフォームを選択する際に考慮すべきその他の考慮事項

Webプロジェクトに使用するツールを決定するとき、私たちはよく次のように考えます。「ドキュメントはここで優れています。多くの人がTwitterでそれについて話し、リリースがリリースされることが多く、プラグインがたくさんあります。」それは通常そのような推論で終わります。特定のプラットフォームを十分に長く使用すると思われる場合、複数のプロジェクトで使用できる、または会社全体の公式ツールになることができると思われる場合は、次の質問も行う必要があります。

• , ?
• ?
• ?
• , , - ?
• ?
• - ?

Webフレームワークの選択に関しては、可能な限りVue.jsを使用する傾向があります。このフレームワークは、標準設定にあまり干渉することなく、必要なものをすばやく簡単に作成できるように思えます。私は通常、動的機能を必要とするカスタム要素や従来のWebサイトコンポーネントが必要な場合は常にVue.jsを使用します。私はVue.jsで小さなサイトを構築しています。また、大規模なプロジェクトにはVue.jsを使用しないため、Gridsomeを使用する傾向があります。



より大規模で深刻なプロジェクトには、Reactライブラリを使用します。Kenticoでは、ほとんどすべてのフロントエンド開発がReactに基づいています。将来的にはこの方向に進む予定です。したがって、私が同じことをするのは論理的です。静的サイトジェネレーターの選択について話す場合、今はNext.jsとGatsbyの両方を使用していますが、どちらか一方の方が好きです。私にとって、このフレームワークの最大の機能は、動的ルートもサポートするファイルベースのルーティングです。また、Sourcebitとの互換性も気に入っています。これにより、必要に応じて、すべてを最初から書き直すことなく、データソースまたはSSGを変更できます。



どの静的サイトジェネレータを使用していますか？