Как стать автором
Обновить

Что такое генераторы статических сайтов и почему Astro — лучший фреймворк для разработки лендингов

Уровень сложностиПростой
Время на прочтение4 мин
Количество просмотров9.8K
Всего голосов 8: ↑6 и ↓2+4
Комментарии12

Комментарии 12

Если сравнивать с jekyll то какие преимущества будут?

Вопрос ещё по управлению контентом, предположим если есть команда разработки и команда маркетинга которая управляет контентом, то как это все лучше организовать? В случае с WordPress тут то никаких проблем. У маркетинга просто визуальный редактор и нет проблем, как тут со статическими генераторами быть не очень понятно.

Добрый день!

Во-первых, Jekyll требует Ruby, и все плагины для него написаны на Ruby. Astro написан на TypeScript — он воспринимается как обычная npm-зависимость, а не какая-то внешняя утилита. Во-вторых, Jekyll использует морально устаревший шаблонизатор Liquid, когда как в шаблонах Astro используется JSX-синтаксис со всей его гибкостью. В-третьих, в Jekyll будет целой эпопеей встроить виджет, написанный на любой UI-библиотеке, значит вы не сможете легко добавить какую-то мало-мальски сложную интерактивность на своих сайтах. В Astro можно использовать одновременно React, Vue, Svelte и т.д. и это будет работать очень быстро и легко настраиваться.

Что касается второго вопроса, мне кажется, что генераторы статических сайтов подойдут для тех команд, которые могут выделить ресурс на разработку собственных решений, так как хотят иметь больший контроль над своими приложениями. Тот же Astro отлично интегрируется с различными решениями для админок, но команде разработки придётся самостоятельно заниматься настройкой всех этих инструментов. Это не тот вариант, где всё работает из коробки как в WordPress, так что генераторы стоит использовать, если только вам необходим полный контроль над инструментами и качеством сайтов, которые получаются на выходе. Кстати, тот же WordPress формирует разметку по запросу, а не на этапе сборки, это влияет на скорость работы и безопасность сайта.

Ещё есть вариант, в котором маркетинг-команда работает с md-файлами, там очень простой синтаксис и тот же Astro умеет преобразовывать их в полноценные страницы, но, конечно, это не замена визуальному редактору, какие-то базовые навыки разработки при работе с этим синтаксисом необходимы.

Интересно, почему производительность вы сравниваете с SSR фреймворками?

Где другие SSG типа VitePress?

Означает ли это, что Astro просто чуть легче, чем SSR?

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

Что касается сравнения скорости и производительности с VitePress — такого я не нашёл, думаю, что здесь они оба покажут достаточно хорошие результаты. Я попробовал сформировать отчёты в PageSpeed Insights для главных страниц Astro и VitePress, замеры не претендуют на то, чтобы показать полноценное сравнение, но все равно приложу результаты:

Astro: https://pagespeed.web.dev/analysis/https-astro-build/8s5msp9qs6?form_factor=mobile

VitePress: https://pagespeed.web.dev/analysis/https-vitepress-dev/8q9i7x3xtf?form_factor=mobile

Как видно, показатели не отличаются критическим образом, где-то больше очков у Astro, где-то у VitePress, но, конечно, стоит провести более точные замеры на одном и том же контенте страницы.

Думаю, что в сравнении с VitePress основным фактором предпочтения Astro может стать его UI-agnostic философия и архитектура островов. Если VitePress завязан на использование Vue.js, то Astro не ограничивает в выборе UI-библиотеки.

Спасибо за проведенные тесты. Да, все SSG должны давать примерно одно

Кстати, свой язык шаблонов и поддержка JSX - это скорей минусы.

Представим ситуацию: уже построили сайт, и ставится задач по той или иной причине переехать на другой фреймворк.

Кому это сделать проще - VitePress с его Markdown-ом, или Astro со своим языком шаблонов?

Понятно, что VitePress можно так закастомизировать, что тоже потребуется ощутимая работа, но всё же.

Astro тоже поддерживает markdown и даже mdx-синтаксис, в который можно встраивать JSX-выражения: https://docs.astro.build/en/guides/markdown-content/.

Плюс язык шаблонов Astro очень простой, если вы писали на любой современной UI-либе типа React, Vue или Svelte, то вы можете практически сразу же писать шаблоны Astro. А если вам вообще не нужна динамика, то это будет просто обычный HTML-синтаксис, ничего специфического учить не нужно.

Помимо Астро, есть еще и https://www.11ty.dev/. Делаю на нем пару небольших проектов. Они очень похожи.

Простота хостинга. Статические сайты намного легче развёртывать на различных хостинг-платформах, так как они не требуют настройки сложной инфраструктуры.

Вот тут вы немного (вернее очень даже много) недоговариваете. Помимо хостинга статического сайта, ещё нужно где-то хранить его данные, иметь эндпоинты для отдачи этих данных сборщику, плюс ещё где-то запускать компиляцию этого всего. То есть получается нужен хостинг для Headless CMS, затем сервер с поддержкой Node.js, затем сервер для отдачи статики. То есть три сервера вместо одного. Понятное дело, что какие-то или даже все эти штуки можно физически разместить на одной машине, но это всё равно уже достаточно сложная инфраструктура получается.

А ведь если приделать фронтенд напрямую к CMS, как было принято раньше, то вместо трёх сервисов останется всего один.

Но самое непонятное для меня вот что: как вообще можно продать клиенту систему, где нужно запускать компиляцию фронтенда, чтобы увидеть изменения, внесённые в контент.

PS: я сам люблю все эти модные реакты и делал несколько очень серьёзных проектов, где использовался next.js для SSR, но не SSG.

Пока останавливает отсутствие гибкости в формировании ссылок при пагинации. Как понимаю, нельзя сделать, чтобы начальная страница была, скажем, `/articles/`, а следующая `/articles/feed/2`, используя один шаблон. В Eleventy с ссылками (permalink) можно делать почти что угодно.

Jekyll ужасен по скорости на большом количестве страниц, я в итоге выбрал HUGO. Опять же он замечательно и нативно интегрируется с github-pages - https://gohugo.io/hosting-and-deployment/hosting-on-github/ Закомитил в github, автоматом обновилось на github.io

VitePress понравился, уже вышел на стабильное апи. Современные практики, отличная скорость.

Тут все пишут про vitepress и облизывают его. Вот вам еще кандидат на эти действия https://rspress.dev/

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории