当サイトを最適な状態で閲覧していただくにはブラウザのJavaScriptを有効にしてご利用下さい。
JavaScriptを無効のままご覧いただいた場合には一部機能がご利用頂けない場合や正しい情報を取得できない場合がございます。
承知しました
本サイトではWebサイトのエクスペリエンスを向上させるために、Cookieを使用しています。Cookieはブラウザの設定から無効にできます。本サイトで使用するCookieについては、プライバシーポリシーをご確認ください。

Blog

ブログ

開発者向け

Next.jsがGatsby、Gridsome、Nuxtよりも究極の選択肢であるのはなぜですか?

By Ondrej Polesny  

新しいWebプロジェクトに使用するフレームワークを検討するとき、それらがどれほど適切であるかに関係なく、私たちが知っているツールを好む傾向があります。だから私は反対を試しました。新しい機会があるたびに、私は新しいテクノロジーを試しました。この実験を通して私は何を学びましたか、そしてなぜNext.jsがSSGのデフォルトの選択なのですか?

この記事では、さまざまなWebテクノロジーに関する私の旅とそれらの経験を紹介します。 Jamstackへの道を共有し、あなたとあなたのプロジェクトに適した適切なツールを選択する方法と、それが私にとってNext.jsである理由を説明します。

私がどこから来たのか

私の最初のWeb開発経験は、PHPとMySQLで始まり、大学での研究中に.NETに変わりました。型安全性、MVCモデル、デバッグの可能性が本当に気に入りました。そうです、「私はここにいます」という反響はもうありません。開発とコンサルティングの仕事の間、.NETを使い続けましたが、Angularの初期バージョンでJavaScriptにゆっくりと移行しました。

約2年前、私はほぼ完全にJamstackに変換しました。 JavaScriptフレームワークの中で最も親しみやすいと感じたので、私はVue.jsに慣れることを選びました。 Nuxt.jsを使用して個人用サイトを構築しました。これは、現在は直感的なVue.jsフレームワークと呼ばれている静的サイトジェネレーターです。私がそれを終えたとき、DevRelの私の同僚は、ReactのSSGまたはWebフレームワークであるGatsbyのソースプラグインの最初のバージョンをリリースしていました。そこで、次のプロジェクトであるKentico Advantageを使用しました。これは、Webエージェンシーをサポートするシンプルなサイトです。それがReactでの初めての経験であり、私はそれを嫌っていました。ほんの少しの機能を実行するのはとても複雑でした。

次のプロジェクトは私自身の結婚式のサイトでした。 GatsbyとReactにもう一度チャンスを与えたのは、2日後にGridsomeになってしまうだけでした。当時、Gridsomeは人気を博していましたが、私はどこでもそれに遭遇していました。 3時間でベースサイトを立ち上げて稼働させることができました。感動した。 Vue.jsのその他のポイント。

それからSourcebitが来ました。これは、ヘッドレスCMSとSSGの間のプラグインであり、データを正規化して、CMSとSSGの切り替えを容易にします。 JavaScriptに関連してサポートされているSSGはNext.jsだけだったので、基本を学び、他の1つのプロジェクトにも使用しました。

適切なJamstackツールをどのように選択しますか?

上記のツールは、過去2年間に最も使用したツールです。いつものように、それらの中に明確な勝者はありません。

あなたが開発者であり、次のプロジェクトに適したツールを選択する責任があるとしましょう。たぶんあなたのチームはあなたの選択に依存しているので、あなたがそれらの多くで遊ぶ余裕があるわけではありません。

経験に基づいて選択

あなたの経験だけでなく、経験に基づいて選択してください。過去にAngularを使用したことがある場合は、最初にAngularのツールを検討し始めたいと思うでしょう。それがあまりにも昔のことである場合は、同僚に何を扱っているか尋ねてください。私はそれをしなかったので、すぐにVue.jsを選びました。問題は、同僚全員がReactで作業していたことでした。そのため、私はすべての問題を自分でグーグルで検索することになりました。

もう1つの側面は、プロジェクトのサイズです。概念実証として個人用サイトを構築している場合、Googleクエリは単純で、ほとんどの場合、それぞれのプラットフォームのドキュメントにつながります。一方、インクリメンタルビルドを使用して企業サイトを構築し、一部をサーバー側でレンダリングし、複数のデータソースを使用する場合は、同僚やコミュニティの支援が必要になります。

3つのJavaScriptフレームワークについて説明しましたが、Jamstackは必ずしもJavascriptであるとは限りません。 PHPやRubyに親しみを感じるかもしれません。以下のリストをチェックして、適切なSSGを見つけてください。

プラットフォーム(.NET、Angular、Go ...)および静的サイトジェネレーター(Statiq、Scully、Hugo ...)
プラットフォーム(.NET、Angular、Go ...)および静的サイトジェネレーター(Statiq、Scully、Hugo ...)

まだ試したことのないプラットフォームについて話すことはできませんが、Vue.jsとReact、およびそれぞれの静的サイトジェネレーターについての私の見解を共有することはできます。

Vue.js-GridsomeとNuxt.js

Vue.jsは、その優れたドキュメントで知られ、有名です。 Gridsomeは同じ道をたどります。ドキュメントは非常にきれいで、初心者として探しているものが正確に含まれています。本当に。それは私の心を読んでいるように感じました。 GraphQLを使用するため、データソースは特別なプラグインを介して接続する必要があります。 Gridsomeは、データモデルを同じ名前のテンプレートに自動的に接続し、ルーティングも処理します。これは初心者にとって便利です。 Nuxt.jsとは別に、独自の外部JavaScriptを使用できます。ベストプラクティスではないことは承知していますが、 HTML5UP.netなどのサイトからテンプレートをダウンロードすると、いくつかのJS機能が付属しています。 Nuxt.jsは私にこれで苦労していました、そして私はVueの機能を書き直すことになりました。

全体として、Gridsomeを使用すると、プラットフォームの障害に対処する必要があるのではなく、フレームワークが機能の実現に役立っていると感じました。簡単なウェブサイトを数時間で立ち上げて稼働させることができます。

Nuxtとの最大の苦労は、Vuex.storeを理解して実装することでした。データストレージとして使用されます。コンポーネントがデータを取得または操作する必要がある場合、コンポーネントはこの1つの場所を使用します。もちろん、コンポーネントレベルでデータ操作を処理することはできますが、コンポーネントはデータセットを共有することが多いため、コードの重複を避けたいと考えています。データストアを実装するために、コンテンツリポジトリからデータを収集する特別なプラグインは必要ありません。私は1を使用するためにヘッドレスCMS Kentico Kontent間違いなく物事が容易になり、私は同じように簡単に使用される単純なのかもしれないAPIを取得して配信SDK 。それが機能するようになるとすぐに、私は実際にこのパターンを楽しんだ。堅牢で柔軟性があり、大規模なプロジェクトに適しています。最初は時間の投資が必要です。

Nuxtは、サーバー側のレンダリング、プレビューモードもサポートし、コミュニティが大きいため、Gridsomeよりも成熟しており、全体として、深刻なプロジェクトに適しています。

グリッドサムNuxt.js
+優れたドキュメント+柔軟
+使いやすい+成熟してより堅牢
+ GraphQLを使用+より大きなコミュニティ
+外部JSコードの簡単な統合を可能にします+サーバー側のレンダリングの可能性
-データソースプラグインが必要+プレビューモード
-時にはあなたが期待するよりも「賢い」 -Gridsomeと比較して急な学習曲線

React-Gatsby vs. Next.js

ギャツビーから始めましょう。私の意見では、すべての中で最も優れた機能であるGraphiQLエクスプローラーから始めましょう。 GatsbyはGraphQLを使用しており、エクスプローラーを使用すると、Webサイトで利用できるようになっているデータを参照できます。これがどれだけ役立つかを強調することはできません。これにより、データソースのドキュメントを読む必要がなくなります。データをクリックして必要なものを選択し、生成されたGraphQLクエリをコピーしてコンポーネントに貼り付けるだけです。

Kentico Kontent

GraphQLは、データソースがGatsbyと ソースプラグインを統合する必要があることも意味します。ただし、すべての主要なヘッドレスCMSはこの統合を備えています。もう1つの大きな利点は、プラグインエコシステムです。 SEOからプログレッシブ画像の読み込み、GraphQLスキーマのエクスポートまで、必要なものは何でもプラグインがあります。

一方、Next.jsには、データを取得するための標準化された方法がありません。どちらの方法が自分に最適かを判断するために、ある程度の時間を費やす必要があります。このリポジトリからインスピレーションを得て、リポジトリパターンを使用しました。 GraphQLなしで生活できるのであれば、Next.jsはGatsbyが行うすべてのことを実行します。

Kentico Kontent

ファイル名に基づくルーティングモデルがあるため、プロジェクトに慣れていない場合でも、ページやテンプレートを非常に簡単に見つけることができます。 静的ページと動的に生成されたページを組み合わせたり、1つのページで両方の方法を使用したりすることもできます。これは、 プレビュー機能に大いに役立ちます。ギャツビーとNext.jsの両方の機能インクリメンタルビルドが、ギャツビーと、あなたは上のサイトホストする必要がありギャツビークラウドのみに利用可能であるファーストクラスのプラグインを。現在は無料枠もありますが、それでも単一のプロバイダーに固定されています。 Next.jsは、ワンライナーでのインクリメンタルビルドのホスティングとオン化をサポートします。

Next.jsは、Gatsbyよりも小さいリリースバンドルも生成します。私の経験では、問題を解決し、コミュニティから助けを得るのは同等です。

ギャツビーNext.js
+ GraphQLを使用+ファイル名に基づく簡単なルーティングモデル
+ GraphiQLエクスプローラー+ユニバーサルプレビューモード
+たくさんのプラグイン+静的ページと動的ページを組み合わせる可能性
-真のサーバー側レンダリングが欠けている+より小さな出力を生成します
-GatsbyCloudに関連付けられた増分ビルドとプレビュー-データを取得する標準化された方法はありません-正しい方法でデータを取得する方法を理解する必要があります
-ギャツビースキーマとビルドキャッシュは、キャッシュの問題を引き起こすことがよくあります

選択したプラットフォームの他の側面

Webプロジェクトに使用するツールを検討するとき、「ドキュメントは良い」、「多くの人がTwitterでそれについて話す」、「頻繁にリリースされる」、「プラグインがたくさんある」とよく言いますが、そこで終わります。 。プラットフォームを長時間使用していて、それが複数のプロジェクトで使用され、全社的に推奨されるツールの1つになる可能性があると思われる場合は、以下も確認してください。

  • ツールの使用期間とその履歴
  • 大規模なサイトのスケーリングに問題がある場合
  • 他のサービスへのどの統合が利用可能か
  • 必要に応じて、実装を別のツールに移行できるかどうか
  • 所有者は誰で、将来の計画をどのように決定するか
  • 有料サービスが必要な機能

私の選択

プラットフォームについて話すときは、できる限りVue.jsを使用することを好みます。設定なしで簡単かつ迅速に使用できると思います。典型的なユースケースは、カスタム要素、動的なフロントエンド機能を必要とする従来のWebサイトコンポーネント、および小さなサイトです。また、大規模なプロジェクトにはVue.jsを使用しないため、Gridsomeを使用する傾向があります。

大規模で深刻なプロジェクトの場合、私はReactを選択します。 KenticoはReactでほぼすべてのフロントエンド開発を行っており、今後もその傾向を継続するため、自分で同じことを行うのは理にかなっているように思われました。静的サイトジェネレーターの選択に関しては、現在両方を使用していますが、GatsbyよりもNext.jsに少し傾いています。私にとっての最大の機能は、動的ルートとSourcebitとの互換性もサポートするファイルベースのルーティングです。これにより、すべてを最初から再実装することなく、将来必要な方法でデータソースまたはSSGを切り替えることができます。

これを読んでいる場合は、Jamstackの選択を教えてください。 Twitterで。ありがとう:-)

Headless CMSの導入をお考えでしょうか?

クラウドとマルチデバイスに最適化されたKentico Kontentをお試しください