Как я создал технический блог на Next.js 16 и почему Learning in Public работает

Как я создал собственный технический блог и почему Learning in Public изменил мой подход к обучению

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

Проблема была не в том, что я не учился.

Проблема была в том, что ничего не оставалось в памяти.

За последние годы я прочитал сотни статей, посмотрел множество видео и прошёл десятки руководств по разработке программного обеспечения. Но каждый раз происходило одно и то же: я находил что-то интересное, понимал это в моменте, а спустя несколько недель обнаруживал, что большая часть информации просто исчезла из памяти.

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

Learning in Public: идея, которая изменила всё

Впервые я столкнулся с концепцией Learning in Public благодаря Swyx — разработчику, за которым я слежу уже несколько лет.

Суть идеи удивительно проста: публикуй то, что изучаешь.

Не нужно ждать, пока станешь экспертом. Не нужно ждать появления уникального взгляда или особенного опыта. Не нужно ждать момента, когда почувствуешь себя «готовым».

Нужно просто писать о том, что ты узнал, и о том, как пришёл к этим выводам.

Сначала эта идея показалась мне немного наивной.

Зачем кому-то читать мою статью, если существуют официальная документация, курсы с десятками тысяч студентов и обучающие материалы от людей с гораздо большим опытом?

Со временем я нашёл ответ.

Голос важнее авторитета.

Иногда объяснение человека, который только что решил проблему, оказывается полезнее, чем идеально написанная, но безличная документация. Более того, сам процесс объяснения заставляет тебя понять тему гораздо глубже.

Невозможно качественно объяснить то, что ты сам по-настоящему не понял.

Почему я решил создать блог

Вместо того чтобы просто завести блог, я решил построить его с нуля.

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

По сути, это уже было практическим применением Learning in Public: создание блога о разработке с использованием технологий, о которых я собирался писать.

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

Выбор технологического стека

Первые вопросы были исключительно практическими:

• Где будут храниться статьи?
• Как будет происходить публикация?
• Как сайт будет работать на мобильных устройствах?
• Как контент будет индексироваться Google?
• Как организовать поддержку нескольких языков?

Next.js 16 и App Router

Основой проекта стал Next.js 16.

Это не самая необычная технология, но сегодня Next.js остаётся одним из самых зрелых решений для React-приложений в продакшене.

Одним из самых важных изменений последних версий стали Server Components, которые теперь используются по умолчанию.

Это означает, что компоненты без интерактивности выполняются на сервере и сразу отправляют браузеру готовый HTML.

Для блога преимущества очевидны:

• более быстрая загрузка страниц;
• улучшенная SEO-оптимизация;
• меньше JavaScript на стороне клиента;
• более простая архитектура приложения.

Статьи генерируются статически, а метаданные для SEO создаются динамически для каждой страницы через встроенные возможности фреймворка.

Tailwind CSS 4

Одним из самых приятных открытий стал Tailwind CSS 4.

Новая версия существенно отличается от предыдущих подходов к настройке. Файл tailwind.config.js больше не является обязательным, а конфигурация темы переносится непосредственно в CSS через директиву @theme.

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

По пути я усвоил важный урок.

В Tailwind v4 все утилитарные классы находятся внутри @layer utilities. Если написать собственный CSS вне какого-либо слоя, он может получить более высокий приоритет и полностью переопределить классы Tailwind.

Это один из тех нюансов, которые обычно обнаруживаются только после нескольких часов отладки.

Sanity v3 как Headless CMS

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

Самый простой вариант — хранить статьи в Markdown-файлах прямо в репозитории.

Это работает. Это бесплатно. Это легко понять.

Но довольно быстро появляются ограничения:

• для каждой статьи нужен новый commit;
• редактирование с телефона становится неудобным;
• работа с изображениями ограничена;
• совместная работа усложняется.

Поэтому я выбрал Sanity v3.

Его визуальная Studio работает прямо внутри приложения, данные запрашиваются через GROQ, а изображения доставляются через CDN с автоматической оптимизацией и динамическими преобразованиями.

Для современного блога это значительно более удобное решение.

Интернационализация с next-intl

Блог доступен на трёх языках:

• Румынский
• Английский
• Русский

Это решение было продиктовано не желанием добавить больше языков ради количества.

Многие разработчики в Восточной Европе и странах бывшего СССР читают контент на всех трёх языках, поэтому многоязычность позволяет охватить более широкую аудиторию.

С помощью next-intl каждый язык получает собственную структуру URL и собственные файлы переводов, сохраняя при этом удобный пользовательский опыт.

Почему я выбрал Feature-Sliced Design

Архитектура стала темой, над которой я размышлял дольше всего ещё до написания первой строки кода.

Я выбрал Feature-Sliced Design (FSD).

FSD разделяет приложение на слои с чётко определёнными обязанностями.

Shared

Содержит переиспользуемые компоненты и утилиты без бизнес-логики.

Entities

Содержит основные модели данных:

• Post
• Author
• Category

Здесь же находятся TypeScript-типы и запросы к данным.

Features

Содержит интерактивные возможности:

• формы обратной связи;
• переключение языка;
• тёмная тема;
• действия пользователя.

Widgets

Содержит крупные блоки интерфейса, собранные из entities и features:

• Navbar;
• Footer;
• сетки статей;
• сложные секции страниц.

Почему архитектура важна даже в личных проектах

Когда работаешь один, у тебя нет code review.

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

В такой ситуации архитектура становится инструментом дисциплины.

Границы между слоями помогают быстро замечать ошибки и предотвращают постепенное ухудшение качества кода по мере роста проекта.

Если в будущем я добавлю:

• рассылку;
• раздел с проектами;
• комментарии;
• новые типы контента;

для каждой новой возможности уже будет понятно, где ей место в структуре приложения.

Что дальше

Сразу после публикации этой статьи меня ждут следующие шаги:

• деплой на Vercel;
• настройка домена;
• проверка метаданных для всех языковых версий.

В ближайших планах:

• автоматическая генерация sitemap;
• JSON-LD structured data;
• корректная настройка hreflang;
• дополнительные SEO-улучшения.

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

Контент остаётся самым важным

Каким бы качественным ни был блог с технической точки зрения, без контента он практически не имеет ценности.

Архитектура, фреймворки и SEO — это всего лишь инфраструктура.

Настоящая работа начинается с регулярной публикации материалов.

Моя цель — не создать идеальный блог.

Моя цель — создать блог, который будет расти вместе со мной.

Каждая статья — это доказательство того, что я понял тему достаточно хорошо, чтобы объяснить её другому человеку.

А иногда во время написания неожиданно выясняется, что ты понимал её далеко не так хорошо, как тебе казалось.

Именно такие моменты зачастую оказываются самыми ценными.

Потому что именно тогда начинается настоящее обучение.