web-dev-qa-db-ja.com

すべてが静的サイト生成を実行できるのに、Nuxt / NextではなくGridsome / Gatsbyを選択するのはなぜですか?

Gridsome/Gatsbyの使用例:CMSのみ?

私は、Gridsome/GatsbyがCMSでうまく機能することを読みましたが、CMSで何もする必要がなかったので、個人的にrelateできません。利点。これは、Gridsome/Gatsbyを使用する方が良い唯一のケースですか?

静的サイトの生成とプリフェッチ

すべてが静的サイトの生成とプリフェッチを実行できます。動作に違いはありますか?

柔軟性

基本的に、Nuxt/Nextを使用すると、積極的に開発しているときに、自分のやりたいことを簡単に実行し、ビルド動作(SSRまたは静的サイト生成)を簡単に変更できます。一方、Gridsome/Gatsbyでは、そのような柔軟性はありません。またはそれは?

時間投資

また、時間を考えると、2つのフレームワークを学ぶことは時間のかかる作業です。したがって、Nuxt/Nextを使用すると、さまざまな使用例に対応でき、学習する価値が高まります。少なくともそれが私の現在の知識に基づいて私が考える方法です。

現在の個人的な使用例

私の特定のケースでは、ランディングページを作成します。理論的には、記事を読むことから、Gatsby/Gridsomesoundsがより適切です。しかし、機能を見ると、Nuxt/Nextは、Gridsome/Gatsbyと比較して、まったく同じことをデメリットなしに実行できます。

2
oemera

Gridsome/Gatsbyは静的指向のみで、Nuxt/Nextが最初にSSRになります。

[〜#〜] ssg [〜#〜]:静的サイトジェネレーター-ギャツビー/グリッドサム

[〜#〜] ssr [〜#〜]:サーバー側レンダリング-次/ nuxt

CMSのみ

いいえ。ただし、CMSからデータを取得するのに役立つSSGプラグインは多数あります(Wordpress、Drupal、Contenful、Strapiなど)。 SSGを使用するためにCMSは必要ありません。JSON、Markdown、MDXのいずれかを使用してマークアップをハイドレートできます。

柔軟性

実際、SSGでビルド動作を変更することはできません。しかし、静的なWebサイトで動的なことを行うことができます。

時間投資

SSGとSSRの間でよく似ています。 SSGはより単純で抽象化されているかもしれませんが、Gatsbyを使用すると、Reactの一部を学習できます。

個人的な使用例

ランディングページとしては、SSGが最適なツールだと思います。ビルドプロセス中にデータをフェッチする静的なディスプレイ以上のものが必要ですか?フォーム? Netlifyフォーム(またはその他のツール)を使用できます。バックエンド関数?サーバーレス機能を使用します。

SSGには優れたSEO /パフォーマンスプラグインが付属しています。SSRで使用できるかどうかはわかりません。

1
Zooly

GridsomeやGatsbyなどの静的サイトジェネレーターを使用すると、S3などの非常に安価な静的ホスティングプラットフォームにサイトをデプロイし、すべての動的部分をクライアントのブラウザーに保持できます。 API呼び出しまたはフォーム処理には、動的バックエンド(NodeJSまたはServerlessなど)のみが必要です。

NuxtやNextなどのサーバー側レンダリングエンジンの場合、通常は静的ページを提供するNodeJSサーバーも必要であり、そのサーバーの容量と可用性を自分で処理する必要があります。

NextまたはNuxtでサイトを作成し、それを静的サイトジェネレーターとして使用するという、世界最高のアプローチもあります。 ' next export 'または' nuxt generate '。静的サイトではサポートされていない機能にいくつかの制限があるため、少し試して、それが適しているかどうかを確認する必要があります。

1
GreyFairer