Blog

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

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

私の来歴

私の最初のウェブ開発の経験は、PHPとMySQLから始まり、大学在学中に.NETに移行しました。型の安全性、MVCモデル、そしてデバッグの可能性がとても気に入りました。そう、"私はここにいます "という声を聞かなくて済んだんです。開発やコンサルティングの仕事では.NETを使い続けましたが、Angularの初期バージョンで徐々にJavaScriptに移行していきました。

約2年前、Jamstackにほぼ完全に移行しました。JavaScriptフレームワークの中で最も親しみやすいと感じたので、Vue.jsに親しむことにしました。直感的なVue.jsフレームワークと呼ばれるようになった静的サイトジェネレーター、Nuxt.jsを使って個人的なサイトを作りました。私がこのサイトを完成させたとき、DevRelの同僚は、React用のSSGまたはWebフレームワークであるGatsbyのソースプラグインの最初のバージョンをリリースしたところでした。そこで、次のプロジェクトである「Kentico Advantage」にそれを使いました。これが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を見つけてください。

まだ試したことのないプラットフォームについて話すことはできませんが、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よりも成熟しており、全体として、深刻なプロジェクトに適しています。

React-Gatsby vs. Next.js

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

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

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

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

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

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

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

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

私の選択

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

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

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