Размеры, структура и характеристики пакетов
Gatsby и Next.js - возможно, самые известные фреймворки для React.js. В то время как Gatsby - это всего лишь генератор статических сайтов, Next.js обладает множеством талантов. Но, в конце концов, мы также можем очень хорошо использовать Next.js в качестве генератора статических сайтов для React.
Помимо обоих лидеров, в мире генераторов статических сайтов появилась новая звезда: Astro. Раньше я хвалил инновационный и молодой SSG, в основном за его уникальные особенности. В то время как Next и Gatsby являются эксклюзивными для React.js, Astro можно использовать для Vue, React, Svelte и других. Новый SSG великолепен, когда речь идет о размерах пакетов и различных вариантах загрузки компонентов.
Но на этот раз речь идет не о том, чтобы отличаться, а о том, чтобы быть лучше или хуже по сравнению с лучшими собаками.
Для этого я создал такое же небольшое приложение в Gatsby, Next.js и Astro - вот результаты в различии, производительности и многом другом.
Маленькое «приложение»
Наш проект будет состоять из двух компонентов React.js.
Оба компонента настроены на прямую загрузку - не используется ленивая загрузка в виде загрузки по запросу или загрузка, когда основной поток освобождается. Следовательно, это честная игра.
Первый компонент - это простой счетчик, использующий useState:
Второй - это простой отображаемый список:
Я знаю, что вы хотите сначала увидеть размеры пакетов - вот и все. После этого мы еще что-нибудь посмотрим.
Размеры связки
Давайте перейдем к самому интересному: размеры пакетов, которые во многом определяют производительность вашего сайта. Несмотря на то, что все три генератора статических сайтов используют один и тот же код React под капотом, существуют различия в размерах пакетов. Особенно важно здесь Astro.
Его философия - частичное увлажнение, то есть страница состоит из отдельных компонентов. Эти компоненты приводят к отправке только необходимого кода для их отображения в браузере. С другой стороны, Next и Gatsby - это фреймворки, ориентированные на React. Другими словами:
Next.js, Gatsby и другие JavaScript-фреймворки не могут поддерживать частичную гидратацию, потому что они представляют весь ваш веб-сайт / страницу как единое приложение JavaScript.
- Astro Documentation
Я не хочу здесь долго говорить. Вот результаты необходимого кода, который отправляется браузеру:
Next.js: 206 kilobytes Gatsby: 185 kilobytes Astro: 134 kilobytes
Как видите, Astro поставляет намного меньше кода, что приводит к более быстрой странице в целом.
Итак, можете ли вы просто переместить приложение Next.js или Gatsby в Astro для этого? Давайте выясним, устраивает ли это структура Astro-проекта по сравнению с лучшими собаками.
Структура приложений
На самом деле, по моей оценке, три генератора статических сайтов больше похожи, чем различаются. Страницы с уникальными URL-адресами основаны на компонентах в каталоге pages. Лучше всего хранить компоненты и их принадлежности в каталоге components. Перенос всего приложения из одного генератора статических сайтов в другой не должен быть слишком сложным, если не используются эксклюзивные функции.
Поначалу я стал жертвой различия, так как Astro обрабатывает компоненты React. Их нельзя хранить в .js файлах, как в Gatsby или Next. Вместо этого нам нужно использовать .jsx или .tsx файлы - но это уже все.
Тот факт, что Astro является генератором статических сайтов общего назначения, не эксклюзивным для React, можно увидеть, когда речь идет о таких вещах, как выборка данных при запуске производственного пакета. Да, я имею в виду получение данных для статического рендеринга на страницах - например, размещение статического блога и загрузка его с помощью Headless CMS.
Такие функции требуют индивидуального решения в каждом генераторе статических сайтов. В то время как Next.js и Gatsby используют для этого более React-метод, Astro для этого использует свои специальные .astro файлы / компоненты. При использовании Astro
Технические особенности
Когда дело доходит до выбора генератора статических сайтов, производительность - это еще не все, на что мы должны обращать внимание. Поскольку Next и Gatsby уже хорошо известны сообществу, я хочу немного больше сосредоточиться на Astro - конечно, в сравнении с другими.
Как я уже упоминал, Astro не придерживается принципа React. Я не вижу в этом проблемы, потому что
Я уже рассказывал, как переключить Next.js на Preact. Тем не менее, насколько я могу судить, частичное переключение невозможно. Если вы переключитесь на Preact, все ваше приложение будет использовать Preact. Похоже, то же самое можно сказать и о Гэтсби.
Astro, с другой стороны, получает здесь огромную выгоду от своей философии. Нет проблем использовать React.js и Preact одновременно для разных компонентов. Таким образом, нет необходимости в полном переключении. Используйте Preact, чтобы ускорить работу вашего приложения, используйте React.js, если вы не можете переключить этот компонент на Preact.
В то время как переключение на облегченную альтернативу React в Next и Gatsby требует некоторой настройки, Astro поддерживает Preact из коробки, если вы решите инициализировать свой проект с помощью обеих библиотек (CLI позволяет вам выбрать это). Все, что вам нужно изменить, - это импорт поверх вашего .jsx файла.
Кроме того, я не мог написать эту статью, не воздав должное различным способам загрузки компонентов в клиентскую сборку Astro. В то время как Next.js и Gatsby действительно предлагают отложенную загрузку, Astro поддерживает еще пару способов загрузки, если это необходимо вашему компоненту. Это упрощает создание высокопроизводительных пользовательских интерфейсов на основе компонентов.
Поскольку я не хочу только хвалить Astro, давайте выскажем хорошее мнение о каждой лучшей собаке.
Что мне действительно нравится в Gatsby, так это его поддержка по умолчанию GraphQL и множество безголовых CMS. Если бы я хотел перенести свой блог WordPress на статический сайт, я бы обратился к Гэтсби. Тем не менее, трудно сравнивать это преимущество с другими, поскольку Next.js предназначен не только для статических страниц, а Astro еще очень молод.
Говоря о Next.js, фреймворк является явным победителем, когда дело доходит до особого сценария: вы хотите сделать свою страницу как можно более статичной, но все же требовать, чтобы некоторые страницы активно отображались на сервере.
Next.js сияет своей возможностью отображать некоторые страницы на сервере, а другие статически обслуживать по причинам производительности и нагрузки на сервер. Кроме того, сложные функции, такие как статическая регенерация, помогают объединить лучшее из обоих миров - статических страниц и активно отображаемых на стороне сервера.
Спасибо за чтение!
Подробнее о Next.js и Astro:
Больше контента на plainenglish.io
