Сравнение Gatsby и Next.js для разработки веб-сайтов

Список навыков Full Stack разработчика

05.03.2022

Компоненты высшего порядка в эпоху React Hooks

06.03.2022

Gatsby и Next.js, на первый взгляд, могут выглядеть почти одинаково. Оба являются фреймворками на основе React, имеют SSR, SSG, имеют большие сообщества.Частый вопрос, почему используется Gatsby вместо Next.js для разработки сайтов? Эта статья объяснит это подробно.

Выбирая технологию для разработки сайта, нужно учитывать несколько факторов

Скорость разработки
Редакционный опыт
Ремонтопригодность
Масштабируемость
Настройка

Вот как может выглядеть таблица сравнения функций двух фреймворков. Они почти одинаковые, не так ли?

Однако эти незначительные различия могут оказать огромное влияние на разработку веб-сайта.

Теперь давайте рассмотрим, что должно быть на веб-сайте, и проверим, как фреймворки справляются с теми же задачами.

Все начинается или заканчивается с Favicon

Простая, крошечная вещь, которая есть на каждом сайте. Но, чтобы соответствовать разным вариантам использования, ОС, браузерам, обычно нужно иметь более одного — 16×16, 32×32, 180×180, 512×512 и т. д. Приятно, когда об этом не нужно заботиться.

…а с Гэтсби вы не

Измените одну строку gatsby-config.jsи загрузите значок на основе png/jpg/svg… Вот и все. Gatsby сгенерирует набор соответствующих значков в соответствии с передовыми методами оптимизации изображения без какой-либо дополнительной работы.

… а как насчет Next.js?

Next.js не рекомендует для этого способа. Попробуйте погуглить и посмотреть, насколько разные ответы, например, этот Stackoverflow Thread . Все должно быть сделано вручную – оптимизация изображения, изменение размера изображения, встраивание правильных тегов с помощью <Head>тега. Как вариант, вы можете использовать такие сервисы генераторов фавиконок .

Будущее уже здесь с оптимизацией изображений

Оба делают много волшебства, настраивая изображения с помощью библиотеки Sharp, обеспечивая поддержку современных форматов файлов изображений, таких как webp и avif, что приводит к меньшим размерам файлов и более высокой скорости загрузки веб-сайта.

Оба имеют свои собственные компоненты изображения next-image, и gatsby-imageс похожим API. Но есть несколько отличий.

Является ли следующее изображение хорошим?

next-image это просто компонент, когда реальная оптимизация изображения происходит через маршрут API, который принимает параметры строки запроса и возвращает обработанное изображение, например,/_next/image?url=http://example.com/avatar.png&w=32&h=32

Мне нравится эта архитектура, поскольку она также обеспечивает дополнительную гибкость с точки зрения использования оптимизированных изображений без использования компонента реакции.

Еще одна вещь, о которой стоит упомянуть: next-imageтребует, чтобы вы указали ширину/высоту изображения, что не так, когда вы извлекаете данные из CMS, если только вы не используете layout="fill",, но после этого вам необходимо вручную обрабатывать логику оболочки изображения. Таким образом, чтобы избежать смещения макета, вы загружаете изображение из CMS, получаете его ширину и высоту, затем, например, используете свойство соотношения сторон CSS или используете хак SVG, gatsby-imageкоторый автоматически сохраняет исходные пропорции.

или gatsby-image лучше?

gatsby-imageне имеет этой конечной точки API и творит магию за кулисами, используя мощь своего уровня данных graphql и различных плагинов-преобразователей. Все работает из коробки без дополнительной настройки. Но есть еще кое-что, что Гэтсби умеет делать лучше, — режиссура имиджа . Художественное направление направлено на определение нескольких наборов изображений для разных размеров экрана, которые можно обрезать и располагать по-разному. Типичный пример использования этого — когда у вас есть большая диаграмма, скажем, на домашней странице, но на мобильном устройстве она будет слишком маленькой, если мы просто уменьшим ее масштаб. В качестве решения вы можете передать вторичное изображение с увеличенными метками диаграммы в srcset, оптимизированный для мобильных устройств.

Важность интеграции с CMS

Для наилучшего обслуживания клиентов очень важно обеспечить наибольшую гибкость для редакторов и надежную интеграцию с CMS. На веб-сайтах мы создаем каждое слово и страницу, которую можно редактировать через CMS и любые дополнительные метаданные — URL-адрес страницы, метатеги, теги og и т. д. В большинстве случаев мы используем Headless WP, но иногда делаем работу с Contentful, Strapi или Prismic, поэтому крайне важно иметь гибкий и простой способ получения данных с разных платформ.

Гэтсби и сила плагинов

С Gatsby интеграция заключается в установке плагина и предоставлении ключей API. Не нужно иметь дело с SDK и копаться в документации по API. Все будет извлечено и добавлено в единый слой Gatsby Graphql. Существует так много плагинов, что вы можете найти исходный плагин буквально для чего угодно. Клиент использует какую-то рекрутинговую платформу и хочет отображать список вакансий и на своем сайте? Не проблема. Планирует ли он отображать список репозиториев Github со счетчиком звездочек — просто идите и скачайте плагин для этого. Данные будут добавлены в Graphql, и вам не придется беспокоиться о кривой обучения для понимания различных API.

Пример получения данных с помощью Gatsby Graphql с использованием плагина gatsby-source-wordpress

Индивидуальный подход Next.js

Next.js не имеет экосистемы плагинов, поэтому для извлечения данных из CMS нам нужно найти SDK, изучить API, подумать о возможности повторного использования этой интеграции на веб-сайте на разных страницах, возможно, сделать некоторые оболочки SDK для общего использования. случаи, или HOC. Может быть, это нормально для небольших сайтов, но для крупных потребуется потратить некоторое время на обдумывание общей архитектуры выборки данных и масштабируемости решения.

Превью или не превью?

Хорошо, давайте отступим здесь, потому что я уверен, что многие люди даже не удосуживаются предоставить эту функциональность редакторам. Функциональность предварительного просмотра означает рендеринг определенной страницы по запросу из CMS без ее публикации в рабочей среде.

Если вы используете Gatsby, он поддерживает самые популярные CMS и работает без проблем. Вы можете либо использовать Gatsby Cloud, и сервер предварительного просмотра будет создан автоматически, и все, что вам нужно будет сделать, это просто указать CMS правильный URL-адрес, или вы можете развернуть собственную версию gatsby с расширением GATSBY_ENABLE_REFRESH_ENDPOINT=true. Ниже приведен пример того, как это работает с Gatsby + Headless WP.https://player.vimeo.com/video/680458460

С Next.js все снова усложняется; см. официальный документ . Опять же, необходимо написать его вручную для каждой сущности, которую вы планируете просмотреть, определяя правила того, как будут анализироваться данные из триггера предварительного просмотра, что будет извлечено позже и что будет отображено. Вместо пятиминутной настройки с Гэтсби вам придется потратить часы, чтобы получить что-то полезное.

Гибкость для редакторов с программным созданием страниц

Параметры Next.js

Чтобы добиться лучшего в своем классе опыта работы с редактором, редакторы должны отвечать за определение URL-адресов и страниц, отображаемых на нем. Давайте нарушим правило и начнем сначала с Next.js. Есть несколько вариантов его достижения или частичного достижения.

1) URL-адреса динамических подстраниц жесткого кода, например. pages/post/[slug].js. For example, there is a slug field for a post on the CMS side, and you agree it will always be under the/post`, затем определите getStaticPaths в компоненте.

2) Напишите подстановочный компонент в корне pages/[...path].js. Затем напишите дополнительный компонент-оболочку с логикой сопоставления определенного URL-адреса с определенным компонентом. Это поднимает множество проблем и значительно увеличивает сложность архитектуры.

3) Используйте Faust — фреймворк, построенный на основе Next.js и настроенный специально для интеграции с WP. Посмотрите на исходный код, и вы обнаружите, что они в точности выполняют вариант 2) и увидите, насколько он сложен. И это доступно только для WP.

Гэтсби путь

Изначально Gatsby создавался как фреймворк SSG, поэтому он имеет несколько мощных архитектурных концепций.

1) Единая точка программной генерации страниц в gatsby-node.js. Представьте, что это похоже на сообщение фреймворку на естественном языке: «Пожалуйста, выберите все страницы из CMS, затем создайте для каждой страницы CMS соответствующую страницу Gatsby на основе шаблона и сделайте ее доступной по URL-адресу, определенному в CMS». Итак, здесь мы можем использовать разные шаблоны для страниц на основе данных из CMS.

2) Концепции шаблонов. Разделение концепции страниц и шаблонов упрощает определение жестко заданных URL-адресов и программно созданных страниц на основе шаблонов.

В результате вы можете добиться создания маршрутов и страниц, полностью управляемых CMS, не перегружая себя сложной логикой в коде.

Мы требуем добавочной статической регенерации!

Инкрементная статическая регенерация (ISR) позволяет постепенно обновлять только определенные страницы вместо перестроения всех страниц на основе входящих изменений. Инкрементные сборки технически отличаются от ISR, но обе пытаются решить одну и ту же проблему: ускорить обновление контента в производстве за счет постепенного обновления страниц. У Gatsby есть инкрементальные сборки, начиная с v3, и он активно использует их с помощью различных интеграций CMS и Gatsby Cloud, перестраивая только новые обновления, что обычно занимает считанные секунды.

Next.js придерживался немного другого подхода, который не требовал дополнительной сборки для запуска в случае изменений CMS. Вместо этого он позволил вам указать время в секундах, в течение которого страница будет извлекаться из кеша, поэтому она отправится и извлечет новые данные при входе первого незадачливого пользователя.

Изначально я рассматривал это как недостаток для Next.js. Это была функция с высоким спросом, но пока я работал над статьей, они представили ISR по запросу, который должен решить проблему, предоставляя возможность повторной проверки кеша из вызовов из внешних источников. С 17 февраля эта функция считается бета-версией.

Запросы данных везде

Еще одна очень требовательная функция Next.js — запрашивать данные, подобные getServerSideProps, getStaticPropsна уровне компонента, а не только на уровне родительской страницы. В настоящее время вам нужно использовать сверление реквизита или хранилища/контекст для передачи данных с верхнего уровня на нижний компонент. React 18 и серверный компонент потенциально должны решить эту проблему в будущем.

Между тем, в проекте Gatsby вы можете извлекать данные из глобального слоя graphql из любого места, используя файл useStaticQuery. Это упрощает архитектуру и позволяет повторно использовать компоненты.

Очень внешний импорт

Это было недавно предложено NextJS и имеет все признаки огромного преимущества в перспективе для объединения решений Low-Code / No-Code с рукописными приложениями. Чтобы понять эту функцию, лучше всего прочитать этот отличный пример использования между Framer и Next.js. Вы можете создать пользовательский компонент в визуальном редакторе, возможно, также обернуть его красивой анимацией, а затем просто импортировать его в проект с помощью одной строки:

Это сногсшибательно и открывает множество дополнительных возможностей. Гэтсби не позволяет вам сделать это в данный момент. Так что, если вы хотите использовать это в своем проекте, Next.js, вероятно, будет лучшим вариантом.

Карта сайта хороша везде

Обе платформы могут справиться с этим, используя дополнительные библиотеки. Gatsby справляется с этим с помощью плагина и минимальной конфигурации. Для Next.js библиотека делает то же самое, но требует дополнительного выполнения скрипта после сборки.

Безумный i18n

Интересно, что несмотря на то, что реализация будет выглядеть почти одинаково для обоих фреймворков, еще одна функция Next.js, называемая Global Middlewares , делает ее намного более мощной. Это позволяет вам определить промежуточное программное обеспечение верхнего уровня и выполнить, скажем, определение страны в пограничной сети, а затем либо заменить, либо перенаправить пользователя на статически сгенерированную страницу.

Резюме

Мы по-прежнему можем рекомендовать оба фреймворка для разработки веб-сайтов как очень надежные решения. Тем не менее, Gatsby определенно работает лучше с точки зрения статической генерации и интеграции, которые стали возможными благодаря экосистеме плагинов. Для нас эти функции имеют решающее значение, и мы видим, как Gatsby позволяет нам быстрее создавать веб-сайты, делать их гибкими и удобными в сопровождении. Next.js — более динамично-ориентированный фреймворк, и я бы выбрал его, только если мне нужен дополнительный уровень аутентификации на веб-сайте или, может быть, в случае, когда мне нужна эта функциональность глобального промежуточного программного обеспечения, которая могла бы помочь справиться с i18n, A/B-тестированием. , или флаги функций. Это, безусловно, приятно иметь, но обычно они требуются только для огромной технологии корпоративного уровня, где вы можете позволить себе такие эксперименты.