ReactJS *

В релизах ветки 16.x мы постепенно внедряли новую модель разработки, которая решает многие проблемы, с которыми вы сталкивались с самого появления App Router:

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

Делает клиентские переходы в приложениях с серверным рендерингом мгновенными.

Делает кеширование декларативным и компонуемым, при этом включать его нужно явно.

Эта модель называется Cache Components, и в Next.js 17 она будет использоваться по умолчанию.

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

В этом релизе появились ключевые возможности, которые устраняют эти ограничения.

Начиная с Next.js 16.4, мы с уверенностью рекомендуем Cache Components как лучший выбор для любого приложения на Next.js.

Корпоративный сайт на пяти языках: около сотни страниц, блог, новости и 100–150 тысяч пользователей в месяц. Два года он жил на Webflow. Переезд на Next.js 15 и Payload CMS сейчас на финишной прямой, и шёл он без дня Х: страница за страницей, на одном домене со старым сайтом.

Разбираю, как это устроено. Счёт Webflow по строкам, Next.js под /app на Webflow Cloud и 301-редиректы с пятью локалями, перенос CMS-коллекций в Lexical, next-intl и проверки в CI, которые ловят то, что раньше находил только дизайнер через месяц.

Чтобы React летал как Vue 3, достаточно забрать у него тяжелые вычисления и переложить их на плоский реактивный граф зависимостей с умным планировщиком транзакций на уровне микрозадач.

Architecture Baseline определяет границы системы и ключевые архитектурные решения. Но настоящая проверка начинается тогда, когда эта архитектура превращается в работающий код.

В этой статье про переход к первой Full Stack вертикали Enterprise GenAI Platform: React, ASP.NET Core, EF Core и PostgreSQL, модуль Chats, границы frontend и backend, observability, автоматические проверки и End-to-End acceptance.

Главный вопрос “как перейти от архитектурной модели к реализации, не разрушив её преждевременным усложнением”.

Я делаю мобильное образовательное приложение. В какой‑то момент понадобилось объяснять пользователям сложные сценарии, где объекты двигаются по строгим формальным правилам, и объяснять не текстом, а видео. Любая неточная траектория или неверно анимированное действие на видео закладывает неверный паттерн. Я собрал для этого конвейер на Remotion и React Three Fiber.

Что будет, если production smoke-тесты начнут вести себя почти как настоящие пользователи? В статье рассказываю, зачем я запускаю автоматические проверки прямо в проде, как они проверяют реальные пользовательские сценарии и почему однажды из-за них статистика мессенджера внезапно оказалась слишком оптимистичной. Разберём synthetic traffic, soft delete, искажённые DAU/WAU/MAU и то, как отделять техническую активность от реальной, не отказываясь от production smoke.

Неделю назад я рассказывал про Klark + Klara: корпоративный мессенджер и таск‑менеджер, которые живут на нашем сервере. В той статье было про устройство: каналы, звонки, расшифровку голосовых, связку «задача из сообщения». Эта статья расскажет вам более подробно о том как продукт выглядит " сейчас " и что в дальнейшей перспективе мы планируем реализовать.

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

Если у вас несколько фронтенд-сервисов с одинаковыми компонентами (например, сайдбаром), вы либо уже страдаете, либо скоро начнете. Мы начали страдать на шестом.

Добавить новый пункт меню сайдбара. Казалось бы, пять минут. У нас это было как шесть кругов ада: шесть pull-request’ов, шесть ревью, шесть деплоев и бесчисленное количество запущенных CI-пайплайнов ради одной строчки в навигации.

Начали искать решение. Смотрели разные варианты, остановились на Module Federation. Написали прототип, попробовали пару плагинов, словили пару багов, починили, перенесли в код production-сервисов. С тех пор общий UI-каркас живет и деплоится отдельно от всех сервисов уже два года без каких-либо проблем.

В статье рассматриваем два плагина для подключения Module Federation ретроспективно: на каком этапе развития они были два года назад и что с ними сейчас, как выглядит конфиг настройки на Vite для обоих плагинов и пристально вглядываемся в технические детали и ограничения — местами будет сложно, но вы можете в навигации по статье найти интересующий вас раздел или сразу перейти к практическому примеру.

Почему архитектура важнее выбора стейт-менеджера в React

Когда я только начинал свой путь разработчика мне было интересно изучать новые технологии. Учил все подряд. Все знал. Но что лучше или хуже и уже тем более почему — сказать не мог. Именно об этом — как писать код правильно — я собираюсь сейчас рассказать. И буду это делать через призму выбора стейт-менеджера в React.

Всем привет! Меня зовут Даниил Николаев и я frontend-разработчик в компании "Исходный Код"

На каждом kickoff нового проекта всплывает один и тот же сценарий: один разработчик топит за утилиты Tailwind, второй отстаивает чистоту и надежность CSS Modules, третий по привычке тянет проверенный CSS-in-JS, а кто-то просто молча открывает .scss и выходит из созвона.

В этой статье мы опустим споры о «красивом синтаксисе» и разберем инженерную сторону вопроса: кто на самом деле платит за динамику — сборка или браузер клиента.

Заглянем под капот ключевым подходам в мире React (для уровня middle и middle+): разберем классические CSS Modules, ушедший в maintenance mode styled-components, Emotion, современный Tailwind v4 на движке Oxide и перспективный zero-runtime (Linaria, Vanilla Extract). Посмотрим, что реально происходит с CSSOM, reflow и рендером в браузере, а в конце — соберем практическую матрицу выбора без фанатизма и хайпа месяца.

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

Я продуктовый дизайнер, больше шести лет делаю SaaS. Программировать умею, но фулстек-разработчиком себя не назову. Уже несколько месяцев я в одиночку делаю Котомку, планировщик жизни по методу PARA: сферы, проекты, задачи, календарь, привычки, финансы. Есть веб, мобильная версия, синхронизация между устройствами и с Google и Apple календарями. Почти весь код пишет Claude Code. Я ставлю задачи, проверяю результат и принимаю решения.

Этой осенью сын пошёл в пятый класс, и я заметил странную вещь: со смартфоном он на «ты», а за обычной клавиатурой теряется. Мы попробовали несколько тренажёров слепой печати, но ему быстро стало скучно — и я решил сделать свой.

В итоге простая идея превратилась в React‑проект с анимированными руками, анализом слабых клавиш и персональными тренировками. Расскажу, как устроил логику, почему больше всего времени заняли руки и что показало тестирование на главном пользователе.

Хочу посвятить эту статью погружению в разные возможности обновления данных в JS и React, раскрыв это на примере своей библиотеки "nexus-state". Поделюсь подробными примерами, мотивацией и расскажу, для чего вообще нужны стейт-менеджеры и как они работают. При написании примеров я постараюсь максимально просто объяснить суть и не буду затрагивать тему типизации.

В большинстве SPA-авторизация до сих пор строится вокруг JWT, localStorage и заголовка Authorization. Такой подход прост и удобен, но он заставляет клиентское приложение самостоятельно управлять credential и пользовательской сессией.

В этой статье разберём, что меняется при переходе на HttpOnly Cookie и серверные сессии: как браузер хранит и отправляет Cookie, зачем нужны HttpOnly, Secure, SameSite, Domain и Path, и почему вместе с Cookie приходится по-новому смотреть на CSRF и CORS.

Отдельно разберём разницу между JWT и session ID внутри Cookie, а в практической части посмотрим, как такая архитектура меняет React-приложение с Axios и MobX.

Всем привет, это третья часть, в которой пилю калькулятор плитки - tilely.ru. Получился довольно крупный патч, в основном вокруг 3D-режима, и там оказалось прилично багов. Многое пришлось переделывать из того, что сначала казалось логичным, а на практике оказалось вообще неудобным.

Перед самим 3D - то, что допилил ещё раньше в очереди. Теперь можно загружать фото плитки, чтобы не смотреть на однотипные прямоугольники одного цвета. Есть кнопка «применить ко всем комнатам». Если у вас, скажем, санузел и кухня одной плиткой идут, не надо грузить фото дважды. Так же теперь можно выбирать цвет швов, а то они были всегда одного цвета, и картинка порой сливалась.

Производительность React-приложения редко ломается из-за одной “тяжёлой” функции. На практике проблемы накапливаются постепенно: компонент начинает ререндериться чаще, чем нужно, состояние оказывается поднято слишком высоко, в useEffect появляется лишняя работа, а список из нескольких тысяч элементов начинает заметно влиять на интерфейс.

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

Полгода назад я в одиночку начал делать Nookly — локальное приложение для заметок на Flutter: страницы, блочный редактор, таблицы с канбан-видом, полнотекстовый поиск. Ключевое требование с самого начала: всё работает офлайн, данные не покидают устройство. В этом посте — не про сам продукт, а про два инженерных решения, которые могут быть полезны: как спроектировать схему БД так, чтобы синхронизация потом не потребовала переписывания половины кода, и как собрать лендинг вообще без шага сборки.

Разбираю несколько инженерных решений из небольшого браузерного проекта: бинго на шахматных задачах Lichess без собственного сервера. Как получить одну и ту же карточку у всех игроков в один день с помощью детерминированного сида, почему запись из пула данных нельзя удалять (флаг retired), как записать правило «одна партия в день» частичными уникальными индексами и почему политик RLS в Supabase недостаточно: по умолчанию клиентским ролям выданы права, в том числе TRUNCATE, который RLS не проверяет.

Хочу рассказать о своей npm‑библиотеке — это мой второй и самый сложный npm‑проект на момент написания статьи.
Библиотека решает ряд проблем и ограничений связанных с дефолтным поведением браузерного элемента скролл.

Глубоко в код погружаться не буду — поделюсь историей создания и мотивацией.✨