Версии
На своем экране вы видите седьмую (?!) версию сайта. К сожалению, скриншоты первых из них у меня не сохранились.
1
Самая первая версия была больше экспериментом. Лето 2022. Я окончил 9 классов, попробовал разные профили. Судьба сложилась так, что меня заинтересовало программирование. Про какие-то конкретные направления я ничего не знал, но много слышал из разных источников про веб-разработку — так все и началось.
Сам сайт был настолько простым, насколько можно себе представить. Сырой HTML, блочная верстка, захардкоженные размеры. Разместил на нем статьи, которые писал для школьного журнала.
2
В августе 2022 я узнал про React.js и переписал сайт на него. Поменялось только то, что теперь сайт представлял из себя SPA, содержимое же осталось неизменным.
3
В ноябре 2022 я узнал про Solid.js и переписал сайт на него. Поменялся только frontend-фреймворк. В этой версии, в отличие от двух предыдуших, даже не было блога — я просто вставил ссылку на публичную папку на Google Диске.
4
В апреле 2023 года я разработал четвёртую версию В то время я активно занимался веб-разработкой, мне хотелось пробовать использовать множество разных технологий. Я выбрал Next.js.
Сайт был откровенно переусложнён. Например, вместо того, чтобы генерировать статические страницы, я подключил облачную MongoDB. Сами страницы хранились как Markdown-файлы и рендерились на ходу. Вначале я добавлял их вручную, но, спустя некоторое время, разработал ещё и CMS:
Именно эта версия сайта была впервые запущена на домене shelepugin.ru — до этого я использовал бесплатный домен третьего уровня от хостинга статических сайтов.
Какое-то время я поддерживал этот сайт. Например, успел перейти на App Router,
который пришел на замену Pages Router — хотя он появился ещё в Next.js 2022,
app/ считался экспериментальным, и начинал разработку сайта я с pages/.
Внедрял новые технологии (отчетливо помню, как подключал Sentry), исправлял
баги.
Но со временем я практически полностью перестал писать на TypeScript и стал меньше заниматься веб-разработкой в целом. В какой-то момент я также понял, что сайт стал неоправданно громоздким. Стал искать более простые решения.
5
В марте 2024 года я, наконец, переписал свой сайт на Hugo. В какой-то момент я также подключил TailwindCSS.
Никакой БД уже не было, CMS была заменена текстовым редактором.
Выбор Hugo как генератора статических сайтов, в основном, был обусловлен его популярностью. В то время я часто натыкался на минималистичные блоги, написанные на нем — особенно среди Open Source сообщества и энтузиастов Linux.
Но я стал ловить себя на мысли, что лично мне с Hugo не очень удобно работать.
Например, тот факт, что CI использовал более старую версию, чем та, что была установлена на моей системе, нередко приводил к ошибкам сборки. И “издания” — часть функциональности выключается на этапе компиляции, вероятно, чтобы собрать статический исполняемый файл, который проще запустить в пайплайне. Конечно, узнавать обо всем этом мне приходилось по логам из GitHub Actions, когда я видел очередной красный крестик.
Или синтаксис. В Hugo есть подобие компонентов, носящее название “partials”:
<body>
{{ partial "header.html" . }}
...
{{ partial "footer.html" . }}
</body>
Но в Markdown partials недоступны, и нужно использовать ещё один вид компонентов — “shortcodes”:
{{ with resources.Get (.Get "src") }}
<audio controls preload="auto" src="{{ .RelPermalink }}"></audio>
{{ end }}
{{< audio src=/audio/test.mp3 >}}
Разделение понятно с точки зрения реализации, но очень неинтуитивно с точки зрения использования. Не говоря уже о том, что shortcode’ы используют нестандартный синтаксис шаблонов.
Наконец, документация. Её было недостаточно — на тот момент и на мой взгляд. Практически весь сайт разрабатывался методом проб и ошибок, и поддерживался потом так же. Особенно сильно это проявлялось в том, в каких директориях должны размещаться те или иные компоненты сайта.
Возможно, мне не хватило терпения, или я был слишком предвзят к Hugo. Как бы там ни было…
6
Astro решает все те проблемы, которые мешали мне при работе с Hugo. Он устанавливается через npm, поэтому версионирование последовательное и интуитивное. Astro использует классические JSX-компоненты, что позволяет простым образом создавать переиспользуемую разметку. Наконец, можно создать что-то более причудливое, не прикладывая при этом колоссальных усилий.
Это фраза из поста, который я написал сразу после того, как перенес свой сайт на Astro.
Те проблемы, о которых я написал выше, и правда удалось решить. Документация у Astro отличная, сам фреймворк достаточно гибкий, есть множество интеграций: с UI библиотеками, frontend-фреймворками, хостингами статических сайтов и т.д.
Правда в том, что я перепутал “простоту” с “легкостью использования”. Hugo
производит “простые” сайты — по большому счету, HTML и CSS, если не добавлять
зависимости вручную. Astro позволяет разработать статический сайт “легко” —
“просто установи ещё вот эту библиотеку!”. На самом деле то, что получается на
выходе, ничуть не “просто” устроено, просто всю сложность от пользователя
спрятали — за сотнями тысяч строк в node_modules/.
Говоря о node_modules/, не могу не вспомнить про ещё один очень важный аспект
разработки ПО — безопасность. Всё это невообразимое количество библиотек —
это код, который пользователи загружают в NPM. По какой-то причине вышло, что в
мире Node.js принято даже самую незначительную функциональность выносить в
пакет. И вместо того, чтобы написать какую-то простую функцию, многие станут
искать, не опубликовал ли кто-то в NPM пакет, эту функцию оборачивающий. Это
создает среду, в которой процветают атаки на цепочки поставок (Supply chain
attacks). Достаточно одному небольшому пакету — коих у вас тысячи — быть
взломанным, чтобы скомпрометировать весь проект, разработчика, компанию, …
Я не говорю, что сторонние библиотеки — это плохо. Я лишь говорю, что это ответственность. К сожалению, очень часто мы, разработчики, эту ответственность игнорируем. И делаем это в самый неподходящий момент.
Все это совершенно не соответствует простоте, к которой я стремился.
7
Эта текущая версия, разработанная в июле 2026.
Изначально я хотел вернуться к Hugo, но, вспомнив особенности работы с ним, передумал. Генераторов статических сайтов очень много. Поэтому я решил разработать ещё один.
Принцип работы очень прост. Есть структура сайта, представленная некоторой директорией:
content/
blog/
img/
diagram.webp
...
foo.md
bar.md.tmpl
...
index.html
После запуска генератора создается выходная директория — она полность соответствует исходной, с той лишь разницей, что шаблоны выполнены и документы конвертированы в HTML.
content/
blog/
img/
diagram.webp
...
foo.html
bar.html
...
index.html
Можно сделать ещё одно преобразование — переименовать *.html в
*/index.html (кроме index.html). Это немного упрощает URL в строке поиска.
content/
blog/
img/
diagram.webp
...
foo/
index.html
bar/
index.html
...
index.html
Для удобства есть layouts и components — базовые шаблоны для документов и
переиспользуемые компоненты соответственно.
Все это умещается в чуть больше чем тысячу строк на Go. Используется стандартная библиотека и два пакета для обработки Markdown-документов: конвертация в HTML и парсинг метаданных в формате YAML. Метаданные могли бы быть в другом, более простом формате, но YAML здесь является стандартом. Можно заменить и сам Markdown, но с ним довольно удобно работать.
Время покажет, насколько жизнеспособно данное решение.
Внешний вид сайта практически никак не изменился. Я портировал стили,
написанные с помощью TailwindCSS, в обычный CSS. TailwindCSS — это очень
удобная и легкая в использовании технология, но она усложняет сайт, который
получается на выходе. Продолжив его использовать, я бы также не смог отказаться
от Node.js/NPM. Хотя команда TailwindCSS и предоставляет самодостаточные
исполняемые файлы, это, в сущности, тот же Node.js и те же node_modules/,
просто обернутые в один файл с помощью упаковщика. Фундаментальную проблему это
не решает.
Ещё, как мне кажется, TailwindCSS, как и другие utility-first CSS библиотеки,
ухудшает качество кода. Почему-то inline-стили — это “очень плохо” и “так
делать нельзя”, но километровые значения атрибута class — это “хорошо” и
“современно”. Мне же кажется, что плохо и то, и другое. Переиспользование
классов и семантически правильных HTML тегов сохраняет в разметке какую-то
логику. Стили в самой разметке сильно эту логику заглушают.
Можно также судить технологию лишь с точки зрения эффективности. Utility-first библиотеки, по словам разработчиков, часто позволяют уменьшить размер выходного CSS по сравнению с классическим подходом. Это звучит логично, поскольку на каждый класс приходится 1-2 свойства, а количество уникальных используемых классов сильно ограничено. В итоге заветные <10 KB CSS, о которых заявляется на главной странице TailwindCSS, вполне могут быть правдой. Но что с размером HTML? Ведь из-за использования utility-классов разметка увеличивается в размере. Статистическими данными я не обладаю, лишь руководствуюсь логикой. Возможно, TailwindCSS и ему подобные решения позволяет достичь меньших размеров в конечном счете, но это уже не так очевидно.
Все это — не критика одной технологии и даже не критика какой-либо отдельно взятой технологии. С технической точки зрения, это сложные и продуманные продукты, для разработки которых было приложено много усилий. То, о чем я здесь пишу — это критика всей современной web-разработки, ушедшей от “простоты” к “легкости”.
Время последней сборки: 19.07.2026 13:01:31.