Обновление затрагивает проекты, которые используют Metro для разработки и сборки. В релизе исправили Fast Refresh с ленивыми сегментированными бандлами, пропуск файлов, записанных в каталог во время его обхода FallbackWatcher, ошибки сокета при записи через HttpStore и обработку выражений с Platform.OS и Platform.select.

FallbackWatcher стал экономнее: потребление RSS при обходе файлов снизилось примерно на 34%, а пиковое использование heap — примерно на 41%. Также Metro отказался от зависимости image-size в пользу встроенных парсеров, чтобы устранить предупреждения CVE.

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

Источники

• Release v0.87.1 · react/metro · GitHub

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

Теоретически получить базовое понимание фреймворка можно за десять дней курсов, но у меня ушло минимум полтора месяца, чтобы перестать мысленно переводить конструкции React на Angular и начать просто писать код.

Разделение ответственности и файловая структура

Главный сдвиг в голове при переходе с React — смена подхода, где компоненты несут всю нагрузку, на архитектуру, построенную на классах и ООП. В React привыкаешь думать компонентами: каждый кусок интерфейса представляет собой функцию, которая принимает пропсы и возвращает разметку. Вся логика и JSX-шаблон живут в одном файле, всё плоское и перед глазами. В Angular приходится перестраиваться и думать объектами и иерархиями.

Разделение на файлы поначалу вызывает раздражение. Вместо одного файла здесь сразу три: отдельный HTML-шаблон, стили и TypeScript-класс компонента, взаимодействующие через декораторы. Если нужно сделать маленький компонент-иконку для рендеринга SVG, Angular всё равно потребует три файла. Инлайн-шаблоны сделать можно, но это считается плохой практикой. Переключение между файлами поначалу отвлекает, но когда шаблон становится большим и сложным, работать с ним как с отдельным документом оказывается удобно.

Проект в Angular организуется по строгой структуре: сначала выделяются библиотеки (libs), внутри них — фичи (features), и только внутри фич живут компоненты. В React всё обычно проще и ограничивается папками с компонентами, которые используют друг друга.

От функций и хуков к ООП и наследованию

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

Архитектура строится вокруг базовых классов с общими методами и свойствами, от которых наследуются конкретные сущности. Если создать базовый класс Animal, дочерние классы Cat, Duck или Elephant получат его функциональность и добавят собственные уникальные атрибуты, не затрагивая родительский код. Когда нужно исправить или обновить базовую логику, нужно только внести изменения в одном месте, и они автоматически разойдутся по всей иерархии.

Асинхронные данные и реактивные потоки RxJS

Больше всего при переходе на Angular пугает RxJS. В React мы привыкли явно запрашивать данные и ждать ответа, а здесь приходится подписываться на поток и реагировать на каждое его изменение. Данные идут сами и непрерывно, а главная задача разработчика — правильно их направить: отфильтровать лишнее, объединить несколько потоков в один и вовремя отписаться, чтобы избежать утечек памяти.

В реальном коде это выглядит как цепочка операторов, модифицирующих данные до их попадания в компонент. Проблема в том, что в RxJS около 50 операторов, и для нормальной работы нужно сходу знать хотя бы 10-15 из них, без этого читать чужой код не получится.

На адаптацию уходит время: сначала приходишь в документацию за каждым оператором, а затем вырабатывается инстинкт. Начинаешь сразу видеть, где применить switchMap, а где добавить takeUntilDestroyed для автоматической очистки ресурсов. Это похоже на изучение иностранного языка — сначала переводишь каждое слово, а потом начинаешь думать на нем.

Встроенный tooling: формы, CLI и декораторы

Когда от стадии “отрицания” переходишь к “принятию” подхода, начинаешь замечать вещи, за которые Angular хочется любить. Первое, что бросается в глаза после React, — работа с формами. В React каждый раз приходится выбирать между React Hook Form, Formik и другими решениями, разбираясь в новой библиотеке на каждом проекте. В Angular работы с формами встроена в сам фреймворк: есть задокументированные Template-driven и Reactive Forms. Реактивные формы позволяют прописать объект FormGroup и всю валидацию прямо в TypeScript. В сложных конструкторах с вложенной логикой и зависимыми полями это полностью закрывает задачи без поиска сторонних пакетов на npm.

Следом привыкаешь к CLI, который буквально не даёт сделать что-то неправильно. Для нового компонента достаточно выполнить ng generate component auth-form — инструмент сам создаст файлы и зарегистрирует компонент в модуле. Точно так же одной командой генерируются сервисы и модули с маршрутизацией. Инструмент выполняет рутину по единственному правильному шаблону, который при необходимости можно настроить под проект.

Приятно удивляет и декоратор @HostBinding. Если в React для добавления CSS-класса по условию приходится писать логику в JSX или выносить её в отдельную функцию, то в Angular достаточно повесить одну строчку над свойством класса. Класс сам появляется или исчезает на хост-элементе в зависимости от значения, не создавая лишнего шума в шаблоне.

Диагностика циклических зависимостей

Самая противная проблема в Angular — циклические зависимости. Это ситуация, когда Сервис А зависит от Сервиса Б, а Сервис Б где-то дальше по цепочке ссылается на Сервис А. Фреймворк далеко не всегда ясно указывает на место ошибки: приложение может просто упасть при старте или вывести в консоль сбой, указывающий совсем не на ту причину.

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

Для выхода из этой ситуации есть инструмент Nx и команда nx dep-graph (или nx graph). Она визуализирует интерактивную карту проекта прямо в браузере, рисуя дерево связей между всеми библиотеками. Если в проекте появился закольцованный цикл, команда автоматически подсвечивает его красным цветом.

Критерии выбора стека под задачи

Angular точно не подходит на роль первого фреймворка для новичка. Это логичный следующий шаг, если хочется развиваться в сторону фуллстека или бэкенда: Java и Go тоже используют классы, объекты и dependency injection как стандартную практику. Год работы с Angular помогает легче понимать паттерны того же Spring Boot, потому что основные концепции уже отработаны на фронтенде.

Если задача — быстро собрать MVP, стартап, лендинг или небольшое приложение, объективно проще взять React. Там меньше формальностей и ниже порог входа на старте. Когда же предстоит развивать сложную долгоживущую систему с крупной командой, Angular оказывается практичнее: через год любой новый разработчик сразу поймёт структуру без дополнительных объяснений.

По этой причине Angular часто выбирают для разработки крупных распределённых платформ и корпоративных экосистем — например, в Centicore Group, где есть сложные стандарты архитектуры и строгая типизация, чтобы поддерживать порядок в масштабных проектах.

Итого

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

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

Для меня этот опыт стал крутым шагом вперед. Ты перестраиваешь мышление с коротких функций на нормальное ООП, начинаешь нативно понимать архитектурные паттерны и уже без страха смотришь в сторону того же бэкенда. Так что если представится шанс пощупать Angular на реальном проекте — не бойтесь, оно того стоит.

В статье разбираем, почему React.memo сравнивает пропсы по ссылке, как inline-объекты и inline-функции обнуляют эту оптимизацию, и какие два простых приёма действительно возвращают производительность.

React.memo пропускает рендер только тогда, когда все пропсы равны по Object.is. Для объектов и функций это проверка по ссылке.

Inline-объекты и inline-колбэки в JSX создают новую ссылку на каждый рендер родителя, поэтому memo видит «новые» пропсы и снова рисует дочерний компонент.

В эксперименте со 200 memoизированными строками это дало 243,9 мс на один keystroke; после стабилизации ссылок — 6 мс.

Сначала выносите статические объекты за пределы компонента, а useCallback применяйте только там, где колбэк действительно пересекается с memoизированным потомком.

Оптимизировать всё подряд не нужно: измеряйте в Profiler, а не добавляйте хуки «на всякий случай».

Как React решает, рендерить компонент заново или нет

Когда родитель перерисовывается, React не делает послаблений дочерним элементам только потому, что они обёрнуты в React.memo. Он сравнивает новые пропсы со старыми. Если каждый проп проходит проверку Object.is, React может «отказаться» от рендера — bailout. Если хотя бы один проп не равен, компонент рисуется заново.

Для примитивов Object.is работает очевидно: 1 === 1 и 'hello' === 'hello'. А вот для объектов и функций сравнение идёт по ссылке.

Два объекта с одинаковым содержимым — это разные объекты в памяти. То же самое с функциями. Поэтому, когда вы пишете style=\{\{ padding: 16 \}\}, React получает новую ссылку на каждом рендере и считает проп изменившимся.

Почему inline-пропсы — это не микрооптимизация, а поломка контракта

Сам по себе объект в JSX не вреден. Если компонент дешёвый, редко перерисовывается и не обёрнут в memo, inline-пропсы почти не влияют на скорость. Проблема появляется, когда три условия накладываются друг на друга:

• родитель перерисовывается часто — поиск, скролл, фильтры, live-данные;
• дочерний компонент или поддерево достаточно тяжёлые, чтобы лишний рендер был заметен;
• вы уже добавили React.memo и ожидаете, что React будет пропускать работу.

В такой ситуации нестабильные ссылки не просто добавляют накладных расходов — они полностью отменяют ту оптимизацию, ради которой вы взяли React.memo. UI продолжает работать, но лагает ввод, тормозят списки, а в Profiler видно, что дерево горит жёлтым при каждом чихе.

Классический опасный пример

Представьте список товаров из 200 строк. Каждая строка обёрнута в memo, но в месте вызова передаются inline-пропсы:

Здесь style и onAddToCart создаются заново при каждом рендере ProductList. Для memo это сигнал, что у каждой строки изменились пропсы, и все 200 компонентов рисуются снова.

Эксперимент: от 243,9 мс до 6 мс на один keystroke

Автор оригинальной статьи собрал контрольный пример: поисковый интерфейс со 200 memoизированными строками. Все строки получают одинаковые логические значения, но новые ссылки на объекты и функции. Результат после шести введённых символов: каждая видимая строка отрендерилась 14 раз.

В React DevTools Profiler один keystroke дал коммит длительностью 243,9 мс, в котором подсветились все 200 волокон строк. Инструмент @welldone-software/why-did-you-render прямо указал причину: props.style — «different objects that are equal by value», props.onAddToCart — «different functions with the same name».

Почему 14 рендеров?
Каждый ввод в поиск меняет searchTerm, родитель перерисовывается, и inline-пропсы дают строкам новые ссылки. Счётчик рендеров растёт на каждый keystroke, даже если отфильтрованные товары не изменились.

Как починить: два приёма вместо дюжины хуков

Чтобы восстановить bailout, нужно сделать так, чтобы неизменяющиеся значения не получали новую ссылку на каждом рендере. Правило простое: сначала вынести, потом закешировать.

1. Статические объекты — за пределы компонента

Если объект не зависит от пропсов и состояния, создайте его один раз на уровне модуля. Это дешевле любого хука и не требует dependency-массива.

2. Динамические колбэки — useCallback

Если функция передаётся в memoизированный компонент и не должна меняться без причины, оберните её в useCallback со стабильным массивом зависимостей.

После этих двух изменений в эксперименте время рендера упало с 243,9 мс до 6 мс, счётчики строк застыли на 2, а Why Did You Render замолчал — avoidable re-renders исчезли.

Когда не нужно ничего стабилизировать

Главная ошибка — оборачивать в useCallback каждую функцию и выносить каждый объект за компонент. React сам по себе быстрый, а мемоизация — это контракт, а не стиль кодирования.

• Компонент дёшев и редко перерисовывается — не тратьте когнитивный бюджет команды.
• Дочерний элемент не обёрнут в React.memo — тогда стабильные ссылки ничего не экономят.
• Значение зависит от часто меняющегося состояния — useCallback с нестабильным массивом зависимостей всё равно будет пересоздаваться.
• Вы ещё не замерили в Profiler — оптимизация без измерений почти всегда лишняя работа.

React Compiler, который сейчас выходит в стабильное состояние, автоматически мемоизирует многое из того, что раньше делали вручную. Но и он не отменяет понимания ссылочной стабильности: useMemo и useCallback остаются полезными, когда нужен точный контроль, например для зависимостей эффектов.

Часто задаваемые вопросы

Выводы

Inline-объекты и inline-колбэки в JSX — не антипаттерн сами по себе. Они становятся проблемой только на границе memoизации, где React ожидает стабильные ссылки. Как только вы понимаете это правило, многие «таинственные» лишние рендеры перестают быть таинственными.

1. Профилируйте до оптимизации, а не после.
2. Вынесите статические объекты за компонент — это самый дешёвый способ стабилизации.
3. Применяйте useCallback только для колбэков, которые уходят в memoизированные потомки.
4. Проверяйте себя через React DevTools Profiler и Why Did You Render.
5. Не забывайте про React Compiler, но не полагайтесь на него как на волшебную палочку.

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

Источник: LogRocket — The React pattern everyone uses that kills performance.

Проверьте свой текущий проект: откройте React DevTools Profiler, введите что-нибудь в поиск и посмотрите, сколько компонентов подсветится жёлтым только из-за новой ссылки в пропсах.

Речь пойдёт не о теории reconcile-алгоритма, а о практике: что проверять первым делом, как изолировать проблему через Suspense, куда смотреть в production-логах и как писать тесты, которые ловят регрессии до попадания к пользователям.

Что такое hydration mismatch

Гидратация — это процесс, при котором React берёт серверный HTML и навешивает на него обработчики событий, после чего страница становится интерактивной. React ожидает, что дерево, которое он отрендерил на клиенте, точно совпадёт с тем, что пришло с сервера. Если строки, атрибуты или структура различаются, возникает hydration mismatch.

В development-режиме React покажет предупреждение, текст расхождения и стек компонента. В production всё сводится к коротким кодам вроде #418 или #425. Без телеметрии вы не узнаете, на каком маршруте, в каком компоненте и из-за каких данных произошёл сбой.

Почему это больно именно в RSC

В классическом SSR обычно один серверный рендер и один клиентский проход гидратации. App Router добавляет Server Components, Client Components, потоковую передачу, Suspense-границы, динамические данные маршрута и RSC payload, который едет рядом с HTML.

Когда несовпадение происходит вне Suspense-границы, React может отбросить весь серверный HTML и перерендерить дерево на клиенте. Приложение заплатило цену серверного рендера, а пользователь не получил ни производительности, ни преимуществ стриминга. Это не просто предупреждение в консоли, а реальная потеря производительности.

Ключевые выводы

• Hydration mismatch в production без телеметрии почти невозможно локализовать: нужна инструментация на клиенте.
• Основные причины: browser-only API, дата/время/локаль, состояние авторизации, невалидный HTML, расширения браузера, CSS-in-JS.
• Граница 'use client' — это не только маркер сборки, но и граница гидратации: серверный рендер должен быть детерминирован.
• Suspense-границы помогают изолировать сбой и не давать ему сломать всё дерево.
• Проверяйте hydration только на production-сборке: next dev ведёт себя иначе.
• Добавьте Playwright-smoke-тесты на критичные маршруты, чтобы ловить регрессии в CI.

Самые частые причины

Перед тем как копать RSC payload или сравнивать HTML, стоит проверить шесть типовых сценариев. Они покрывают подавляющее большинство production-инцидентов.

• Browser-only API во время рендера: window, document, localStorage, navigator — сервер не знает об этих значениях.
• Дата, время и локаль: Date, Intl.DateTimeFormat, относительное время — сервер обычно в UTC, пользователь в своей зоне.
• Состояние авторизации: сервер рендерит выклогнутый UI, клиент сразу видит авторизованного пользователя.
• Невалидный HTML: браузер чинит DOM до гидратации, а React сравнивает с исходным деревом.
• Расширения и middleware: браузерные плагины и edge-переписывания меняют HTML.
• CSS-in-JS и порядок классов: styled-components и Emotion могут генерировать разные имена классов при стриминге.

Browser-only API и сторонние провайдеры

Самая частая причина — не ваш собственный код, а сторонний провайдер, который читает localStorage, window или navigator при инициализации. Под это попадают аналитика, фичер-флаги, A/B-тесты, session replay и персонализация.

Проблемный вариант: провайдер читает localStorage прямо при рендере.

Исправление: серверные флаги передаются в Client Component, а локальные оверрайды применяются после гидратации.

Принцип: серверный и первый клиентский рендер должны получить одинаковый результат. Браузерные оверрайды включаются в useEffect после монтирования.

Дата, время и локаль

Сервер часто работает в UTC, а пользователь — в своей зоне. Date.toLocaleString(), Intl.DateTimeFormat и функции вроде formatDistanceToNow() дают разные строки в зависимости от часового пояса и времени между рендером и гидратацией.

Проблемный вариант: относительное время считается на сервере.

Исправление: сервер отдаёт стабильную абсолютную дату, клиент заменяет её на относительную после монтирования.

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

Состояние авторизации

Типичный сценарий: сервер рендерит UI для неавторизованного пользователя, потому что маршрут статический или не читает куки, а клиент сразу видит залогиненного пользователя. При каждой загрузке страница перерендеривается.

Решение — читать куки на сервере через cookies() из next/headers.

С cookies() маршрут становится динамическим — это обычно правильный компромисс для UI, зависящего от авторизации. Начиная с Next.js 15, cookies() асинхронный и требует await. В Next.js 16 синхронный доступ к request-time API полностью уходит.

Невалидный HTML

Браузер молча чинит невалидную вёрстку. React же гидратирует не исходную строку, а DOM, который построил браузер. Классический пример — внутри

Браузер превратит это в примерно такую структуру:

Если HTML приходит из CMS или редактора, валидируйте и нормализуйте его на сервере. Для собственных компонентов следите за предупреждениями validateDOMNesting в DevTools.

Расширения браузера и middleware

Менеджеры паролей, переводчики, грамматические плагины и другие расширения могут вставлять или переупорядочивать узлы до гидратации. Edge middleware и CDN-трансформации тоже могут переписывать HTML в пути.

Если несовпадение затрагивает только <html> или <body>, сначала подозревайте расширения. React 19 стал терпимее к инъекциям в head/body, но на старых версиях такие ошибки особенно шумные.

suppressHydrationWarning на корневых элементах — документированный escape hatch, но он работает только на один уровень вглубь и не должен использоваться для сокрытия неизвестных расхождений в продуктовом UI.

CSS-in-JS и порядок классов

В проектах со styled-components или Emotion имена классов могут зависеть от порядка рендера. Стриминг и Suspense меняют этот порядок, поэтому нужен registry с useServerInsertedHTML.

Production workflow для отладки

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

1. Настройте клиентскую телеметрию: перехватывайте console.error и отправляйте hydration-ошибки на свой endpoint.
2. Воспроизводите баг на production-сборке: next build && next start, а не next dev.
3. Используйте Suspense-границы, чтобы изолировать проблемный участок и понять, в каком поддереве ошибка.
4. Сравнивайте серверный HTML (curl) и клиентский DOM после гидратации.
5. Когда найдёте расходящийся элемент, проверьте: browser-only API, дата/время, авторизацию, HTML-вложенность, расширения, стили.

Инструментация: instrumentation-client.ts

Файл instrumentation-client.ts в Next.js запускается после загрузки документа, но до гидратации React. Это удобная точка для лёгкой клиентской телеметрии.

Если используете LogRocket, Sentry или другой инструмент, прикрепите тот же payload к текущей сессии — тогда можно будет увидеть, как выглядела страница в момент сбоя.

Изоляция через Suspense

Suspense-границы не только показывают fallback при загрузке. Если hydration mismatch случается внутри границы, React может ограничить восстановление этим поддеревом, а не переключать весь root на клиентский рендер.

Оберните поочерёдно основные секции. Если страничная ошибка исчезает после оборачивания конкретной секции, баг почти наверняка внутри неё.

Сравнение HTML и DOM

Получите серверный HTML через curl с нужными куками:

В Chrome DevTools после загрузки страницы скопируйте живой DOM:

Сохраните результат в /tmp/client-render.html и сравните:

Этот метод хорошо ловит HTML-слой, но может пропустить расхождения на уровне reconciler-а и RSC payload. Если raw HTML совпадает, проверяйте Client Components и браузерное состояние.

Профилактика

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

1. Server Component должен быть детерминированным: одни и те же входные данные дают одни и те же выходные HTML и RSC payload.
2. Все browser-only API, куки, заголовки, локаль и время должны оставаться за границей 'use client' или читаться через request-time API на сервере.
3. Для клиентского UI сначала рендерите стабильный baseline, а улучшения добавляйте в useEffect после гидратации.
4. Валидируйте HTML из внешних источников до того, как React его увидит.
5. Тестируйте hydration на production-сборке в CI.

Пример: стабильный baseline + клиентское улучшение

Скелетон — это стабильная базовая разметка. Карточки товаров появляются после монтирования. Сервер и первый клиентский рендер совпадают, а пользователь получает нужный контент чуть позже.

Smoke-тесты в CI

Ручное тестирование пропустит регрессии. Добавьте Playwright-тест на критичные маршруты.

Запускайте такой тест только против production-сборки, никогда против next dev. Сделайте его обязательной проверкой для маршрутов, где hydration failure критичен: продуктовые страницы, дашборды, чекаут, личный кабинет.

FAQ

Выводы

Hydration mismatch — не придирка React, а реальный баг производительности и корректности. Каждое несовпадение означает, что приложение могло отбросить серверный HTML, за который уже заплатило ресурсами.

В приложениях с React Server Components, где цель — меньше клиентского JavaScript и более ранний стриминг полезного UI, hydration failures тихо отменяют эти преимущества. Поэтому важно держать браузерную логику за границей 'use client', рендерить стабильные серверные baseline и проверять гидратацию в production-условиях до того, как ошибку найдут пользователи.

Hydration errors should be fixed, not ignored — официальная позиция React.

Источник: LogRocket Blog — How to fix RSC hydration mismatches in Next.js.

Проверьте свои критичные маршруты на production-сборке, настройте телеметрию и не давайте hydration-ошибкам копиться в консоли.

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

Деструктуризация — инструмент, а не норма. Её стоит применять там, где она правда упрощает код, а не просто экономит символы.

Объект хранит контекст. project.status понятнее, чем голая переменная status, особенно в больших функциях.

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

Деструктурируйте позже, а не раньше. Сохраняйте исходный объект до тех пор, пока он действительно не понадобится в разобранном виде.

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

Деструктуризация — не религия

Несколько лет назад Мэтт Смит деструктурировал почти всё: объекты, пропсы, параметры, возвращаемые значения. Если встречался объект — он его раскладывал. Это перестало быть осознанным решением и превратилось в привычку: так пишет «современный JavaScript».

Сейчас он всё ещё использует деструктуризацию, но уже не автоматически. Причина простая: возвращаясь к старому коду, Смит тратит больше времени, чем ожидает, чтобы понять, откуда взялась та или иная переменная. Ему приходится мысленно собирать исходный объект обратно, прежде чем разобраться, что происходит.

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

Не бойтесь повторов

Один из самых распространённых паттернов — вынесть поля из объекта, а потом передать их как пропсы в компонент:

С этим ничего не случилось. Но сегодня автор с большей вероятностью напишет так:

Да, здесь повторяется post. Но когда он вернётся к этому коду через месяц, ему не придётся вспоминать, откуда взялись title или author. Контекст остаётся на виду.

Объект несёт контекст

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

А сто строк ниже встретили такой код:

Моментальная пауза: «archived»… что именно? Сравните с вариантом, где объект сохраняет свою форму:

Объект по-прежнему несёт полезный контекст. Лишние символы редко замедляют чтение. А вот необходимость помнить, к какой сущности относится переменная, замедляет гораздо сильнее.

Вложенность лучше раскрывать поэтапно

Раньше автор считал вложенную деструктуризацию элегантной. Сейчас она часто кажется попыткой понять всю структуру объекта ещё до того, как начал решать задачу.

Автор предпочитает писать иначе:

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

Деструктурируйте позже, а не раньше

С параметрами компонентов ситуация похожа. Для маленьких компонентов деструктуризация пропсов отлично работает:

Но по мере роста компонента автор чаще пишет так:

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

Каждая переменная — цена для читателя

Каждая локальная переменная просит читателя запомнить ещё одно имя. Иногда это стоит того, иногда — нет.

Если новая переменная обозначает осмысленную концепцию, автор с удовольствием её вводит. Имя вроде billingAddress становится частью словаря функции.

Но если автор просто превращает project.status в status, уверенности, что код стал читабельнее, нет. Полезное правило большого пальца: если деструктуризация даёт коду лучший словарь — использует её. Если она только экономит несколько символов — обычно нет.

Когда деструктуризация всё ещё уместна

Всё вышесказанное — не аргумент против деструктуризации. Автор по-прежнему применяет её постоянно.

Эти случаи локальны, сфокусированы и убирают шум. Есть и другие исключения. При маппинге массива я спокойно пишу:

Объект существует всего несколько строк, поэтому автор не чувствует, что теряет контекст. Иногда имеет смысл даже переименовать извлечённое свойство: const { status: projectStatus } = project;.

Такое имя сохраняет больше контекста, чем просто status. Но если автор всё равно несёт имя объекта в переменную, часто оказывается, что project.status читается естественнее. Не нужно придумывать новое имя, а связь с объектом остаётся очевидной.

Разница в том, что автор больше не деструктурирует просто потому, что объект существует.

Главный вопрос

Автор всё ещё любит деструктуризацию. Есть множество мест, где она заметно очищает код. Просто он больше не хватается за неё автоматически.

Перед тем как убрать объект, он спрашивает себя: удаление объекта действительно облегчает понимание или просто делает код короче?

Если деструктуризация даёт коду лучший словарь — автор её использует. Если она только экономит несколько символов — обычно нет.

Выводы

Деструктуризация остаётся одним из самых полезных синтаксических улучшений JavaScript. Но удобство записи не должно превращаться в удобство только для автора. Читаемость кода измеряется не количеством символов, а скоростью, с которой человек понимает, что происходит.

Сохраняйте объекты там, где они несут контекст. Раскрывайте вложенность поэтапно. Вводите переменные, только если они добавляют смысла. И не забывайте главный вопрос: вы делаете код понятнее или просто короче?

Источник: Matt Smith — I stopped destructuring everything

Разбираем ситуацию по материалу Pragmatic Engineer — охватывает технические подробности vinext, экономику и последствия для коммерческого open source.

Cloudflare выпустила vinext — замену Next.js на базе Vite, которая деплоится в Cloudflare Workers одной командой.

Один инженер + ИИ-агент OpenCode + Opus 4.5 = одна рабочая неделя вместо нескольких лет инженерного труда.

По заявлению Cloudflare: сборка до 4 раз быстрее, клиентские бандлы на 57% меньше.

vinext покрывает 94% API Next.js, но официально экспериментальна: не прошла нагрузочного тестирования.

ИИ удешевил переписывание сложного ПО примерно в 100 раз — под угрозой оказались проприетарные «рвы» коммерческих open source-проектов.

Vercel ($9 млрд оценка) потеряла ключевое конкурентное преимущество: уникальный формат билда Next.js.

Next.js и Vercel: как устроен коммерческий «ров»

Next.js — самый популярный полностековый React-фреймворк. По данным Stack Overflow Developer Survey 2025, его используют около половины разработчиков на React. Проект открытый, но содержится преимущественно силами Vercel.

Хитрость в том, что Next.js собирает проекты с помощью Turbopack — опционального инструмента Vercel, написанного на Rust (используется прежде всего в dev-режиме). Результат сборки — проприетарный, недокументированный формат. Инженер Netlify Эдуардо Боукаш объяснял это так:

Формат вывода сборки Next.js является проприетарным и недокументированным — он используется в деплоях Vercel для инициализации нужной инфраструктуры. Это означает, что любые другие хостинг-провайдеры вынуждены опираться на недокументированные API, которые могут менять поведение без предупреждения в минорных и патч-релизах.

В итоге сложилась система: Next.js бесплатен и открыт, но наилучший опыт разворачивания — только на Vercel. Альтернативные провайдеры вынуждены угадывать поведение недокументированного формата. Это умная стратегия, превращающая open source-проект в воронку монетизации.

Чтобы сломать эту схему, нужно заменить Turbopack на стандартный инструмент — например, Vite, который лидирует в экосистеме JS по данным State of JS 2025. Именно это и сделал Cloudflare.

Что такое vinext и как его создали

Идея проста: убрать Turbopack, поставить Vite, сделать так, чтобы приложения на Next.js собирались в стандартный формат и деплоились на любой платформе — в том числе на Cloudflare Workers.

Cloudflare публично заявила, что на это ушла одна рабочая неделя одного инженера, который использовал агент OpenCode (open source coding agent) совместно с моделью Claude Opus 4 (в источнике — «Claude Opus 4 (в источнике — «Opus 4.5»)»; такой модели в публичном портфеле Anthropic нет, по всей видимости имеется в виду Opus 4):

На прошлой неделе один инженер и модель ИИ с нуля пересобрали самый популярный front-end фреймворк. Результат — vinext (произносится «ви-некст»): drop-in замена Next.js на Vite, которая деплоится в Cloudflare Workers одной командой. В ранних бенчмарках сборка production-приложений ускорилась до 4 раз, а клиентские бандлы уменьшились до 57%. И у нас уже есть клиенты, которые запустили его в production. Вся работа обошлась примерно в $1 100 на токены.

Ядро Next.js за 10 лет выросло примерно до 194 000 строк кода. vinext занимает около 67 000 строк — более компактная реализация, которая не поддерживает устаревшие API и охватывает 94% публичного API Next.js. Оставшиеся 6% — сложные граничные случаи.

Что именно сделал Cloudflare

• Взял публичный API Next.js
• Переписал поведение через Vite
• Создал формат вывода сборки, совместимый с поведением оригинала
• Добавил Agent Skill для миграции существующих Next.js-проектов одной командой

Миграционный скилл — отдельная деталь, показательная для эпохи ИИ. Он работает с Claude Code, OpenCode, Cursor, Codex и другими агентами:

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

ИИ делает «невозможное» тривиальным

До появления современных ИИ-агентов переписать Next.js «с нуля» было теоретически возможным, но практически исключённым. Это требовало бы многолетних усилий команды инженеров. При этом сообщество сомневалось бы в долгосрочной поддержке любого форка — Vercel доказывала свою надёжность 10 лет, а любой новый игрок не имеет этого кредита доверия.

Теперь ситуация изменилась. По оценке Pragmatic Engineer, ИИ ускорил создание vinext примерно в 100 раз. Cloudflare завершила проект, измеряемый в инженерных годах, за одну инженерную неделю.

Важно, что всеобщий рост продуктивности от ИИ в среднем куда скромнее. По данным The Pragmatic Summit (Сан-Франциско, 2026), самооценка разработчиков даёт около 10% прироста. Ключевое условие для 100-кратного ускорения — наличие полного тестового покрытия, которое позволяет ИИ-агентам верифицировать каждый шаг.

ИИ во много раз эффективнее на «механических» задачах, где корректность можно проверить тестами, по сравнению с открытыми задачами или теми, что требуют творчества.

Сам факт, что Next.js имеет исчерпывающее тестовое покрытие — это одновременно его сила и слабость: ИИ использовал тест-сюит как спецификацию для переписывания. Cloudflare даже поблагодарила команду Vercel в объявлении:

Мы хотим отметить команду Next.js. То, что их API хорошо задокументирован, а тест-сюит настолько полный, — один из главных факторов, которые сделали этот проект возможным.

Качество под вопросом: экспериментальность vs маркетинг

Cloudflare открыла своё объявление сильным тезисом: «клиенты уже запустили в production». Vercel немедленно указала на уязвимости в безопасности, а CEO Гильермо Рауч связал проект со стереотипом «вайб-кодинга» — небрежной работы без понимания деталей.

Претензия оказалась обоснованной: важная деталь про «production» была закопана в тысяче слов после начала объявления:

Мы хотим быть честными: vinext экспериментален. Ему ещё нет недели, и он не прошёл реального нагрузочного тестирования. (...) Мы работаем с National Design Studio на одном из их бета-сайтов, CIO.gov.

«Клиент в production» у Cloudflare — это бета-сайт без значимого трафика. Это нетипично для компании, обычно отличающейся точностью формулировок. Vercel имела право поднять вопрос безопасности.

Тем не менее это не отменяет главного вывода: ИИ способен снизить стоимость разработки примерно в 100 раз и выдать работоспособный результат за приемлемую сумму. Доработка безопасности и надёжности потребует дополнительного времени — но это уже другой разговор.

Новая угроза для коммерческого open source

Cloudflare и Vercel — известные соперники в борьбе за платформу разработчиков. CEO обеих компаний регулярно обмениваются ударами в публичном пространстве.

Но реальная ставка здесь — бизнес-модель коммерческого open source. Стратегия Vercel была классической:

1. Создать и поддерживать Next.js, обеспечив лучший developer experience.
2. Оптимизировать Vercel под специфический (и недокументированный) формат вывода Next.js.
3. Большинство разработчиков, выбравших Next.js, деплоят на Vercel — ради лучшей интеграции.
4. Повторять годами, пока бизнес не оценят в $9 млрд (оценка октября 2025 года).

В основе стратегии лежали два предположения: (1) переписать Next.js дорого и (2) даже если кто-то это сделает, разработчики усомнятся в жизнеспособности альтернативы. ИИ обнулил оба предположения.

Аналогия с WordPress и WP Engine

Похожая история произошла с WordPress и WP Engine в 2024 году. WP Engine «пиратила» усилия Automattic: почти не вкладывалась в R&D, зато продавала WordPress как managed service — дешевле, чем Automattic, тратящая на разработку сотни миллионов.

Разница в том, что Vercel удавалось избегать «фрирайдеров» — благодаря проприетарному формату билда. Теперь этого барьера больше нет: Cloudflare будет синхронизировать каждое обновление Next.js с vinext через ИИ-агентов, и это не потребует серьёзных инвестиций.

Как защититься: стратегии для коммерческих open source-проектов

Если ИИ позволяет конкурентам тривиально переписать ваш продукт, каковы варианты защиты?

Закрыть тест-сюит

Один из очевидных ответов — сделать тесты приватными. SQLite, например, держит свой наиболее полный тест-сюит (TH3) закрытым и продаёт доступ к нему как сервис. Open source-проект для визуального редактирования tldraw объявил о переносе тестов в закрытый репозиторий (хотя потом оказалось, что это была шутка).

Саймон Виллисон прокомментировал тренд:

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

Другие варианты защиты

• Уменьшить open core, увеличить закрытую часть. Перенести расширенные сервисы из source available в полностью закрытый код.
• Профессиональный support. ИИ может повысить качество поддержки при правильном применении — а это сложно скопировать.
• Живое сообщество. Meetup'ы и реальная аудитория создают связь, которая выходит за рамки кода. Трудно представить встречи vinext-пользователей — а встречи Next.js-разработчиков уже существуют.
• Инфраструктура как ров. В мире, где ПО легко скопировать, владение и управление инфраструктурой становится важнейшим преимуществом: меньшая задержка, выше надёжность, лучшая цена.

Что это значит для индустрии

Для не-коммерческого open source перспективы выглядят иначе. ИИ упрощает создание и поддержку форков, перенос проектов на другие языки и добавление новых функций. Это может означать расцвет открытых проектов, которые не зависят от коммерческой логики.

С другой стороны, появится класс «миграционных агентов», которые провайдеры будут создавать для перетягивания клиентов. Cloudflare уже встроила такой агент в vinext. Это «AI-native» стратегия захвата рынка, которую скопируют другие.

Конкуренция в технологической индустрии становится жёстче и быстрее. По словам Laura Tacho с The Pragmatic Summit:

ИИ — это ускоритель, мультипликатор, и он движет организации в разных направлениях.

В частном случае vinext — пока неясно, насколько популярным он станет и насколько глубок «ров» Vercel вокруг экосистемы Next.js в целом. Переписать фреймворк — не то же самое, что стать жизнеспособной платформой-as-a-service. Доверие, стабильность, поддержка и developer experience накапливались 10 лет.

Выводы

Cloudflare переписала Next.js не из любви к open source, а чтобы разрушить конкурентное преимущество Vercel. Это честная бизнес-война. Но побочный эффект оказался важнее самого конфликта: стало ясно, что ИИ-агенты превращают переписывание сложного ПО из многолетней инвестиции в задачу одной недели.

Для разработчиков это хорошая новость: экосистема Next.js получила стандартизированный формат сборки, а деплой на разные платформы станет проще. Для компаний, строящих бизнес на коммерческом open source, — сигнал тревоги: проприетарные технические «рвы» больше не защищают так, как раньше.

Что по-настоящему защищает — живое сообщество, инфраструктура мирового класса, качество поддержки и репутация, накопленная годами. vinext может стать удобной альтернативой деплоя. Но стать полноценной заменой экосистемы Next.js — задача несравнимо более сложная.

Как вы оцениваете угрозу, которую ИИ создаёт для коммерческого open source? Читайте также: другие материалы об ИИ и open source на tproger.ru.

Источники: Pragmatic Engineer — The Pulse; Cloudflare блог — объявление vinext; State of JS 2025.

ИИ я использую. Но в этом проекте он был исключительно быстрой документацией — особенно когда добрался до selection/range API, про которые до этого знал чуть меньше чем ничего. Реализация все равно была за мной.

Так вот — ReadGen. Блочный конструктор README-файлов. Месяц, 2-3 часа в день, React и TypeScript и небольшая пачка дополнительных библиотек для разумного облегчения жизни. Важно понимать что это не коммерческий продукт и не претендует на решение чьей-то боли. Просто техническая задача которую я давно хотел разобрать.

Демо: readgen-eight.vercel.app

Репозиторий: github.com/islamxm/readgen

Почему

contenteditable — старый добрый дед среди браузерных API. То что он старый - это да, а вот доброта - под вопросом.

Он искренне хочет помочь, сам расставляет <div> и <br>, сам решает что делать с Enter, сам форматирует как считает нужным. Проблема в том что его никто не спрашивал. Когда тебе нужен предсказуемый блочный редактор с контролируемой структурой данных — такая самодеятельность становится основным источником боли.

Готовые текстовые движки эту боль скрывают. Я хотел её почувствовать лично. Понять где именно браузер начинает делать по-своему и что с этим делать. Это и был настоящий вопрос проекта.

Поначалу казалось что задача не супер сложная, но довольно быстро понял что полноценный текстовый редактор это бесконечные edge cases которые не влезут ни в какой месяц. Граница была проведена жёстко: плоская структура блоков, никакой иерархии. Всё остальное — потом, в другой жизни.

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

Три OM

Между реальным DOM и виртуальным DOM React затесался ещё один — MOM, Markdown Object Model. Пафосное название для того что по сути является flat map структурой документа. Но только по сути — на деле это целое ядро, состоящее из парсера, валидатора, гардов, движка, сериализатора. Это по сути модули без внешних зависимостей (кроме dexie.js в подмодуле storage) которые принимают данные, делают свое дело и отдают, впрочем как и принято в среде порядочных разработчиков.

Архитектурно MOM живёт как отдельный изолированный модуль — ведёт себя как shared слой в FSD, но это не набор утилит а самостоятельное ядро. Всё остальное приложение построено на гибриде FSD и layered подхода, но MOM существует по своим правилам.

Один DOM, два хозяина

Вот где настоящий конфликт. Структурой документа, порядком блоков, состоянием UI управляет React. Но внутри редактируемых блоков он полностью отступает. Там нет react рендеринга, только innerHTML и чистый DOM. Синхронизация происходит в эффекте, источник истины — содержимое contenteditable, и именно оттуда формируется MOM.

Два хозяина поделили территорию. React взял всё снаружи, DOM взял всё внутри. С одной стороны казалось бы все круто, так и должно быть, но на самом деле это порождает новый пласт проблем.

Отдельная история внутри этой истории — курсор. Позицию нужно постоянно сохранять и восстанавливать через selection/range API, и синхронизировать это с React. Это отдельная боль внутри общей боли.

Деструктивная синхронизация DOM — innerHTML = '' перед каждой манипуляцией выглядит грубо, зато работает. Можно было конечно написать свой reconciliation но учитывая исходные рамки по времени я решил отказаться.

Генераторы в сериализаторе

Экспорт документа в .md — финальная точка всей архитектуры. MOM → Serializer → файл. Впервые за все время своего осознанного программирования я решил тут применить генераторы в деле.

Каждый тип узла имеет свою функцию-генератор. Первый yield — контент блока, второй yield "" — пустая строка-разделитель. Тут мы избавляемся от аккумулятора который нужно тащить в глубь и код делаем более плоским и понятным. Array.from(gen).join("\n") в конце собирает всё в строку.

Drag and drop на Pointer Events

Кастомный drag and drop с анимацией как отдельный хук. И тут я познакомился с довольно таки мощными событиями класса pointer

о существовании которого я знал но почему то всегда обходился с touch

и mouse ивентами.

Pointer Events унифицируют всё что раньше требовало отдельных mouse и touch обработчиков. Без pointercancel drag зависает если браузер решает прервать жест сам. setPointerCapture — чтобы события не терялись когда курсор уходит за пределы контейнера.

Компромиссы

MOMRaw — честное признание границы. Все что не попало в текущую версию движка (таблицы, инлайн-картинки, инлайн-код и т.д.) живёт в одном компромиссном блоке. Вставляй сырой Markdown или HTML, смотри превью через внешнюю библиотеку в изолированном Shadow DOM.

То же самое с блоком кода - MOMCode. Для этого я подключил библиотеку uiw, думаю в будущем заменю его на более современное и понятное решение.

Виртуализации нет, README на 10 000 блоков не существует в природе, проблема надуманная ну или просто не успел (выбирайте сами).

Мелочи которые просто есть и работают: менеджер глобальных шорткатов, тултипы для вставки блоков, эмодзи и форматирования текста, миниатюры документов через modern-screenshot, хранение в IndexedDB без бэкенда.

Заключение

Месяц закончился. contenteditable я теперь знаю лично — и он знает меня. Selection/Range из страшного незнакомца превратился в рабочий инструмент. Понял где React уместен, а где лучше отойти и дать DOM делать своё дело. Нашёл наконец задачу где генераторы оказались не паттерном ради паттерна а реально лучшим решением.

Демо: readgen-eight.vercel.app

Репозиторий: github.com/islamxm/readgen

В материале на блоге LogRocket разобран один из самых частых React-паттернов, который в неподходящем контексте оказывается одним из самых дорогих, — передача inline-объектов, массивов и колбэков прямо в месте вызова компонента. Контролируемый эксперимент с 200 memoized строк показывает, как это превращает один keystroke в коммит на 243,9 мс — и как простой рефактор возвращает время до 6 мс.

React.memo сравнивает по ссылке. Внутри React работает Object.is: {padding:16} и {padding:16} — это разные ссылки, значит «изменилось».

Inline-объекты в JSX обнуляют memo. Каждый рендер родителя создаёт новый объект/функцию, мемоизированный дочерний компонент видит «новые пропсы» и перерисовывается заново. Оптимизация, которую вы планировали, не срабатывает.

Цена в живом коде. Эксперимент: 200 memoized строк, поиск, inline style и onAddToCart. После 6 нажатий — счётчик рендеров каждой строки = 14, на keystroke коммит 243,9 мс.

Фикс простой. Статичный объект — в module scope. Динамический колбэк — в useCallback с пустыми зависимостями. После: коммит 6 мс, счётчик рендеров = 2, Why Did You Render молчит.

React Compiler не отменяет понимания. Он автоматизирует много memoization, но useMemo/useCallback остаются escape hatch для случаев, когда нужен точный контроль (например, dependency для Effect).

Как работает bailout у React

React.memo оборачивает компонент в memoization-границу. Когда родитель ререндерится, React не пропускает дочерний автоматически только потому, что он мемоизирован. Вместо этого сравниваются новые пропсы со старыми. Если каждый пропс считается равным — bail out, переиспользуем предыдущий результат. Если хотя бы один не равен — рендер. По умолчанию React сравнивает попропсово через Object.is.

Эта деталь критична, потому что для объектов и функций Object.is — это, по сути, проверка по ссылке:

Содержимое выглядит идентичным, но ссылки разные. React поэтому считает их изменёнными. Именно по этой причине inline-объекты и колбэки оказываются скрытой причиной того, что мемоизированный дочерний компонент продолжает ререндериться.

Та же логика объясняет, зачем нужны useCallback и useMemo. По документации React, useCallback кеширует определение функции между рендерами, а useMemo — результат вычисления. Оба помогают только тогда, когда зависимости остаются достаточно стабильными, чтобы React переиспользовал предыдущее значение. Если положить в массив зависимостей нестабильный объект, React видит новую зависимость на каждом рендере и пересчитывает заново.

Это и объясняет, почему баг ощущается запутанным в реальном приложении. Значения «выглядят» неизменными для человека: у style-объекта те же ключи, тело колбэка идентично, config всё ещё говорит то же самое. Но React не сравнивает намерение или структуру — он сравнивает идентичность.

Когда inline-пропсы реально становятся проблемой

Стоит провести границу между теоретической и практической ценой. Inline-колбэк сам по себе — не баг производительности. Если ребёнок дешёвый, частота рендера низкая и memoization-границы вокруг нет, измеримого отрицательного эффекта может вообще не быть. И в документации React, и в гайдах LogRocket по производительности — общее место: оптимизация работает там, где есть реальные узкие места, а не гипотетические.

Проблема начинается, когда сходятся три условия одновременно:

• Родитель ререндерится часто (поиск, скролл, фильтры, анимация, live data).
• Дочерний компонент или поддерево большое — лишняя работа заметна.
• Вы уже добавили memoization и ждёте, что React пропустит работу, когда «ничего важного не изменилось».

В такой связке нестабильные inline-ссылки не просто добавляют немного оверхеда — они обнуляют ту оптимизацию, которую вы намеренно ввели. И этот паттерн коварен в продакшене: он не объявляет себя багом. UI работает, исключений нет, предупреждений нет, и без профилировщика часто нет очевидного запаха. Цена проявляется иначе: тормозящая фильтрация списков, лаг ввода, шумные flame-графы и компонентные деревья, которые продолжают перерисовываться, даже когда осмысленные данные не менялись.

Контролируемый эксперимент: 200 memoized строк

Чтобы не спорить «плохо или нормально», автор поста собрал контролируемый тест: поисковый список товаров с 200 memoized строками, где каждая строка получает одинаковые логические значения, но новые ссылки на объект и функцию на каждом рендере родителя. Это позволяет напрямую увидеть, делает ли React.memo bail out или всё поддерево ререндерится на каждое нажатие клавиши.

Представьте storefront UI с 200 memoized ProductRow. Родитель — ProductList — хранит searchTerm в state. Каждое нажатие апдейтит state, ререндерит ProductList и снова прогоняет JSX, который мапает отфильтрованные товары. В эксперименте каждая ProductRow обёрнута в memo и помечена whyDidYouRender = true, но получает два inline-пропса в месте вызова:

Это ровно тот случай, о котором React предупреждает при передаче функций в memoized-компоненты: свежая функция или объект, созданные во время рендера, не пройдут сравнение пропсов, если ссылку не стабилизировать.

В эксперименте эффект становится виден почти мгновенно. Объект style и колбэк onAddToCart пересоздаются каждый раз, когда ререндерится ProductList, поэтому memo-обёртка видит изменённые пропсы для каждой строки на каждом нажатии. Счётчик рендеров делает это конкретным: после шести нажатий каждая видимая строка показывает Renders: 14. React Profiler затем показывает рантайм-цену ошибки: одно нажатие порождает коммит, в котором ProductList занимает 243,9 мс и все 200 row-fibers светятся в flame-графе.

Здесь React Developer Tools отрабатывают по полной. По официальной документации, React DevTools позволяют инспектировать компоненты, редактировать пропсы и state, а также находить проблемы производительности. Профайлер также доступен программно через <Profiler>, но интерактивный вид DevTools обычно используется командами для отладки.

Why Did You Render делает корневую причину ещё нагляднее. Пакет модифицирует React и сообщает о потенциально избегаемых ререндерах. В этом примере он рапортует props.style как «different objects that are equal by value» и props.onAddToCart как «different functions with the same name» — ровно тот референциальный мисматч, который мы и ожидаем. Это диагностический инструмент только для разработки, не для прода, но крайне эффективный для выявления этого класса багов.

Рефакторинг, который реально решает проблему

Чтобы остановить каскад рендеров, нужны стабильные ссылки. Концептуально фикс прост: значения, которые не меняются, не должны пересоздаваться во время рендера; колбэки, которым нужно жить через рендеры, должны быть memoized, когда ребёнок зависит от референциальной стабильности.

Вынос ROW_STYLE в module scope решает проблему на самом дешёвом уровне: React никогда не видит новую ссылку на объект, потому что он создаётся один раз вне компонента. Использование useCallback для handleAddToCart даёт ребёнку стабильную ссылку на функцию между рендерами, пока массив зависимостей не меняется. Это и есть тот случай, для которого React документирует useCallback при передаче функций в мемоизированных детей.

В эксперименте стабилизация ссылок восстанавливает bail-out. Измеренный результат впечатляет: ProductList падает с 243,9 мс до 6 мс, бейджи рендеров остаются на 2 сколько ни печатай, и Why Did You Render замолкает — избегаемых референциальных мисматчей больше нет.

Когда стабилизировать ссылки, а когда — нет

Это часть, которая часто теряется в дискуссиях про производительность. Урок не «никогда не используй inline-объекты» и не «оборачивай всё в useCallback». Урок: memoization — это контракт. Если ребёнок полагается на референциальное равенство, чтобы пропустить работу, родитель обязан этот контракт уважать и передавать стабильные ссылки.

Но это не значит, что каждому компоненту нужна агрессивная мемоизация. Современные рекомендации React всё ещё трактуют memoization как точечную оптимизацию, а не дефолтный стиль. Если рендер дешёвый, поддерево маленькое или ребёнок не memoized, стабилизация ссылок может добавить сложности без реальной выгоды. Поэтому большинство гайдов по React performance, включая обзоры LogRocket, акцентируют профилировку прежде, чем механически оптимизировать.

Полезное правило большого пальца: сначала перенеси, потом мемоизируй. Если значение статично — вынеси его за пределы тела компонента, прежде чем тянуться к хукам. Это даёт референциальную стабильность почти без когнитивной или рантайм-нагрузки. useCallback и useMemo — только когда значение реально динамическое и ребёнок выигрывает от стабильной идентичности.

Меняет ли это React Compiler

Один актуальный нюанс — React Compiler. Документация описывает его как стабильный билд-тайм инструмент, который автоматически оптимизирует React-приложения и по умолчанию мемоизирует код на основе анализа и эвристик. Это уменьшает потребность в ручных useMemo, useCallback и React.memo, особенно в новом коде.

Но это не делает референциальную стабильность нерелевантной. Документация также отмечает, что useMemo и useCallback остаются полезными как escape hatch для случаев, когда разработчику нужен точный контроль — например, чтобы держать memoized-значение стабильным как зависимость для Effect. Так что даже в кодовых базах, переходящих на React Compiler, всё равно полезно понимать, как нестабильные ссылки влияют на ререндеры, результаты профайлера и кейсы, где ручной контроль ещё нужен.

Итог

Inline-объекты и inline-колбэки — не плохой React-код по умолчанию. Чаще всего это просто обычные JavaScript-выражения внутри JSX. Проблема появляется, когда они пересекают memoization-границу и вы ждёте, что React воспримет «то же значение» как «тот же пропс». По умолчанию React сравнивает пропсы и зависимости хуков через Object.is, поэтому для объектов и функций новой ссылки достаточно, чтобы React счёл значение изменившимся.

Этот паттерн заслуживает большего внимания, чем обычно получает. Это не пустяковая микрооптимизация. Это один из самых простых способов случайно обнулить React.memo — особенно в фильтруемых списках, дашбордах, search-heavy UI и компонентных деревьях с дорогими потомками. Код выглядит чистым, приложение работает, но оптимизация, на которую вы рассчитывали, исчезает.

Практический вывод для команд, строящих быстрые React-интерфейсы: профилируй сначала. Если memoized поддерево всё ещё ререндерится слишком часто — проверь пропсы прежде, чем винить React. Перенеси статичные объекты из render-пути. Мемоизируйте колбэки только тогда, когда ребёнок реально выигрывает. Используй React DevTools и Why Did You Render, чтобы подтвердить, что именно изменилось и почему. Делай это последовательно — и React.memo перестанет быть декоративным куском кода и начнёт делать свою работу.

Источник: The React pattern everyone uses that quietly kills performance — LogRocket Blog.

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза "end-to-end encryption"? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

В статье расскажу, как работает E2EE изнутри: как устанавливается сессия через X3DH, как каждое сообщение получает отдельный ключ через Symmetric Ratchet, почему сервер хранит только зашифрованные конверты, и какие ошибки я допустил по дороге.

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Важная оговорка про web-E2EE

Когда я говорю, что сервер не может прочитать сообщения, я имею в виду backend, базу данных, WebSocket-слой и уже сохранённые ciphertext-конверты. У них нет ключей и plaintext.

Но у web-E2EE есть отдельная проблема: frontend-код тоже приходит с сервера. Теоретически скомпрометированный сервер может отдать изменённый JavaScript, который украдёт ключи или plaintext до шифрования. Это ограничение не конкретно моего проекта, а браузерной модели в целом.

Поэтому корректная формулировка такая: backend не получает ключи и не может расшифровать уже переданные или сохранённые сообщения. Защита от подмены клиентского кода — отдельный слой безопасности: подпись сборок, независимая верификация клиента, desktop/mobile-приложения, reproducible builds.

Почему обычный подход не работает

Большинство "мессенджеров" на GitHub выглядят примерно так:

Сервер знает всё. Видит каждое сообщение. Если БД утекла — утекла вся переписка. Если сервер взломали — читай что хочешь. Если завтра компания решит продать данные — технически ничего не мешает.

E2EE решает это радикально: backend не получает ключи и не хранит plaintext. Сообщение шифруется на устройстве отправителя до отправки в сеть, а расшифровывается только на устройстве получателя.

Это уже не вопрос политики конфиденциальности в стиле "мы обещаем не читать". Это архитектурное ограничение: если у сервера нет ключа, он не может превратить ciphertext обратно в текст.

Звучит как магия. На самом деле — два протокола и немного WebCrypto.

Главная идея: конверты

Представь что Алиса хочет написать Бобу. Вместо того чтобы положить письмо на стол и надеяться что никто не прочитает — она кладёт его в запечатанный конверт. Конверт может открыть только Боб своим ключом. Сервер просто передаёт конверт не заглядывая внутрь.

Именно так это работает в коде. В базе данных у меня это выглядит так:

Когда я впервые увидел

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

А вот что сервер возвращает при запросе списка чатов через API:

Не

. Не

. Буквально

(DevTools → Network → ответ API с

)

Откуда берутся ключи: X3DH

Главный вопрос: как Алиса и Боб получают общий секрет, если они никогда раньше не общались? И как сделать это так, чтобы сервер только помог передать публичные данные, но сам не смог вычислить итоговый ключ?

Для этого используется X3DH — Extended Triple Diffie-Hellman, протокол из экосистемы Signal. Его задача — установить общий секрет между двумя устройствами, используя долгосрочные и временные ключи.

Что хранится на сервере

Когда пользователь регистрирует устройство, он загружает на сервер пакет публичных ключей:

На сервер уходят только публичные части. Приватные ключи сериализуются и хранятся локально в браузере — и никогда не покидают устройство в сеть.

Здесь важно сказать честно: хранение приватных ключей в

Более строгий вариант — использовать Web Crypto API с

, чтобы приватный ключ жил внутри браузерного crypto runtime и его нельзя было экспортировать в байты. Но у этого подхода есть практическая сложность: ключи нужно переживать между перезагрузками страницы, синхронизировать с IndexedDB, аккуратно восстанавливать состояние устройства и не сломать UX.

В браузерных E2EE-приложениях обычно приходится выбирать между несколькими вариантами:

• Сериализуемые ключи в localStorage или IndexedDB — проще реализовать, но нужно очень серьёзно относиться к XSS и целостности frontend-кода.
• extractable: false + IndexedDB — безопаснее, но сложнее в реализации и восстановлении состояния.
• Нативное secure storage вроде Android Keystore или iOS Secure Enclave — лучший вариант для мобильных клиентов, но он недоступен обычному web-приложению.

В текущей версии Chaos Messenger используется первый вариант. Это осознанный компромисс для pet/open-source проекта и удобного запуска в браузере. Переход на non-extractable ключи и более строгую модель хранения стоит в roadmap.

Ключевой момент: backend всё равно не получает приватные ключи и не может расшифровать сохранённые ciphertext-конверты. Но защита ключей на клиенте — отдельная задача, и её нельзя честно замалчивать.

Установка сессии

Когда Алиса открывает переписку с Бобом впервые, происходит следующее:

В классическом X3DH четвёртая DH-операция с one-time prekey опциональна: она выполняется, если сервер выдал доступный OPK получателя. В моей реализации устройство публикует набор one-time prekeys при регистрации, поэтому первое сообщение обычно использует DH4. Если OPK закончились, сессию всё равно можно установить через остальные DH-компоненты, но это уже менее сильный вариант.

Боб, получив конверт с эфемерным публичным ключом Алисы, повторяет те же операции со своими приватными ключами и получает тот же самый

. Математика симметрична.

Сервер в этот момент видит только публичные ключи и зашифрованный конверт. Он помогает устройствам найти друг друга, но не участвует в вычислении секрета.

Получить

Как шифруется каждое сообщение: Symmetric Ratchet

X3DH даёт нам стартовый

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

Решение — симметричный ratchet. После каждого сообщения цепочка ключей продвигается вперёд:

Визуально это выглядит так:

используется для шифрования одного сообщения через AES-GCM, после чего уничтожается. Если атакующий компрометирует

— он прочитает только второе сообщение.

В рамках такой симметричной цепочки это даёт forward secrecy назад по цепочке: зная текущий или отдельный

Само шифрование сообщения:

А вот что уходит на сервер — живой пример из DevTools:

Сервер получает

и

. Расшифровать без

Важная оговорка: это ещё не полный Double Ratchet

В этом проекте реализован Symmetric Ratchet — цепочка, где из

для каждого сообщения выводится отдельный

Это защищает прошлые сообщения: если атакующий узнает текущий ключ или отдельный

, он не сможет откатить HMAC назад и получить старые ключи.

Но это не полный Double Ratchet из Signal Protocol.

В полном Double Ratchet есть ещё DH ratchet step: стороны периодически выполняют новый Diffie-Hellman обмен и обновляют root key. Это даёт break-in recovery — возможность восстановить безопасность будущих сообщений после компрометации части состояния.

В моей реализации DH ratchet step пока нет. Если атакующий получит актуальное состояние сессии на устройстве и сможет продолжать его читать, он сможет расшифровывать будущие сообщения до переустановки сессии. Это честное ограничение текущей версии, и оно стоит первым пунктом в roadmap.

Мультиустройство: один пользователь, несколько конвертов

Первый неочевидный момент: в E2EE сообщение адресуется не просто пользователю, а конкретным устройствам пользователя.

Если у Боба два устройства — телефон и ноутбук — нужен отдельный encrypted envelope для каждого устройства. Сервер не может взять один конверт, расшифровать его и "переупаковать" для второго устройства: у него нет ключей и он не знает plaintext.

Значит при отправке сообщения нужно зашифровать его отдельно для каждого устройства каждого участника чата.

Для чата где у каждого по 2 устройства — 4 конверта на одно сообщение. Для группы из 10 человек — потенциально 20 конвертов. Это нормально, это цена безопасности.

Сервер: хранение и доставка конвертов

На сервере сообщение создаётся с контентом

, а конверты сохраняются отдельно:

После сохранения — fanout по WebSocket. Каждое устройство получает свой конверт и только его:

Это важное отличие от обычного WebSocket-чата. В обычном чате сервер рассылает одно и то же событие всем участникам. В E2EE-чате сервер рассылает разные события разным устройствам: payload для каждого устройства содержит свой

Топик

— строго персональный. Устройство А не получает конверт устройства Б. Никакого broadcast — только адресная доставка.

Архитектура целиком

Баг который долго не замечал

В панели чатов показывается превью последнего сообщения. Я реализовал это через

Запускаю — в списке чатов у всех написано

.

Конечно. Сервер же не знает что там написано.

Я полчаса думал как решить это на сервере. Потом дошло: нельзя решить это на сервере — у него нет ключей. Решение только на клиенте.

После того как пользователь открыл чат и сообщения расшифровались — кешируем последнее в памяти:

Это хороший пример того, как E2EE меняет привычное мышление backend-разработчика. В обычном приложении preview — это поле в SQL-запросе. В E2EE-приложении preview — это локальное клиентское состояние, потому что только клиент видел plaintext.

Простое решение. Но чтобы к нему прийти нужно было полностью принять идею что сервер здесь просто не при делах — и перестать пытаться решить задачу на его стороне.

Rate limiting: дыра которую легко не заметить

Эндпоинт

отправляет SMS с кодом. Без защиты любой скрипт может дёргать его тысячи раз — это называется SMS pumping fraud, SMS стоят реальных денег.

Redis у нас уже был для хранения онлайн-статусов. Добавил rate limiting поверх него:

При превышении — HTTP 429 с заголовком

. Клиент знает через сколько секунд можно повторить.

Важный нюанс: в текущей реализации, если Redis недоступен, сервис не блокирует авторизацию полностью. Для pet-проекта это приемлемый компромисс: лучше рискнуть одним лишним SMS, чем положить вход в приложение.

В production я бы сделал строже: fallback in-memory лимит на инстанс, отдельные лимиты по IP и телефону, антифрод-логику и алерты на всплески отправки кодов.

Авторизация WebSocket

Отдельная история — авторизация WebSocket соединений. HTTP-эндпоинты защищены Spring Security автоматически, но WebSocket — другое дело. STOMP-соединение устанавливается один раз, и нужно проверять JWT при каждом подключении.

Отдельно важно не только проверить JWT, но и связать WebSocket-соединение с конкретным устройством. Пользователь может быть один, но устройств у него несколько, а encrypted envelope адресован именно

Поэтому при подключении я проверяю не только токен, но и

: устройство должно быть зарегистрировано и принадлежать текущему пользователю. Иначе легко случайно превратить per-device E2EE-доставку обратно в обычный broadcast по пользователю.

Что получилось — живые скрины

Что реализовано:

• E2EE-модель с per-device encrypted envelopes
• X3DH session setup + Symmetric Ratchet + AES-GCM
• Мультиустройство
• Личные и групповые чаты
• Realtime доставка через WebSocket/STOMP
• Статусы SENT → DELIVERED → READ
• Редактирование и soft delete сообщений
• Online presence, typing indicator
• Фото-вложения
• Поиск пользователей
• Rate limiting на SMS через Redis
• Prometheus метрики + Grafana дашборд
• Swagger UI с JWT авторизацией
• 24 backend-теста на Testcontainers, 12 frontend на Vitest, E2E на Playwright
• GitHub Actions CI

Что ещё не сделано:

• Полный Double Ratchet с DH ratchet step и break-in recovery
• Ротация signed prekey и аккуратное пополнение one-time prekeys
• Более строгая модель хранения приватных ключей на клиенте: non-extractable CryptoKey + IndexedDB
• Защита от подмены frontend-кода: подпись сборок, независимая верификация клиента, reproducible builds
• Android-клиент с Android Keystore
• Реальный SMS-провайдер вместо кода в backend-логах
• Push-уведомления без утечки содержимого сообщений
• Более строгая metadata-модель для групповых чатов

Главный инсайт

E2EE — это архитектурное решение, а не библиотека.

Нельзя взять обычный Spring Boot чат и просто "включить шифрование". Нужно с самого начала проектировать систему так, чтобы backend не был участником доверенной зоны: он не должен получать plaintext, не должен иметь ключи и не должен уметь пересобирать сообщение из данных в базе.

Это меняет почти всё:

• структуру БД — вместо текста появляются encrypted envelopes
• API — сервер отдаёт [encrypted], а не preview сообщения
• WebSocket — доставка идёт не по пользователю, а по конкретному устройству
• мультиустройство — одно сообщение превращается в несколько ciphertext-конвертов
• frontend — становится полноценной криптографической частью системы, а не просто UI

Второй инсайт: мессенджер — это не "чат с WebSocket". В E2EE-модели это система доставки зашифрованных конвертов с адресацией по устройствам. Как только это принимаешь, многие странные на первый взгляд решения становятся логичными.

Репозиторий

Код открыт: github.com/vaazhen/chaos-messenger

В репозитории есть README на русском и английском, диаграммы, скриншоты, security audit, Docker Compose и запуск одной командой.

Проект не претендует на уровень production-криптомессенджера вроде Signal. Это учебный и инженерный open-source прототип, цель которого — показать, как E2EE меняет архитектуру backend, frontend и realtime-доставки.

Если вы делали что-то похожее — особенно интересно сравнить подходы к ротации prekey-ов, хранению non-extractable ключей в браузере и реализации DH ratchet step. Вопросы и критика приветствуются.

Полгода назад я бы посмеялся над таким заголовком. TanStack? Это же ребята, которые делают React Query. Съедают экосистему? Я много лет пользовался React Query, любил его, рекомендовал всем — но воспринимал TanStack как одну библиотеку. Отличную библиотеку, не больше.

Потом я обновил проект в прошлом месяце и заметил кое-что. Я уже использовал TanStack Query, TanStack Router и TanStack Table. TanStack Form начал заменять React Hook Form в новых проектах. А TanStack Start полностью вытеснил мой Next.js-сетап. Я открыл package.json — и почувствовал странное: половина моего стека оказалась TanStack. Не потому что я так планировал, а потому что по одной библиотеке за раз, месяц за месяцем, TanStack просто становился лучшим выбором. И я шёл за лучшим выбором, не задумываясь, куда это меня ведёт.

• TanStack превратился из одной библиотеки (Query) в полноценную платформу из восьми взаимосвязанных продуктов: Query, Router, Table, Form, Start, Store, DB и AI
• По State of React 2026 (~3700 разработчиков) у TanStack Query 68% использования и всего 1% негатива, у Next.js — те же ~80% охвата, но в 17 раз больше негатива
• Главное отличие философии: все библиотеки TanStack headless — они делают логику, а UI и рендеринг остаются за вами
• TanStack Router и TanStack Start дают сквозную типизацию по всему приложению — от search params до server functions
• Реальность: TanStack Start ещё RC, TanStack DB — в бете, TanStack AI — в альфе. На прод сейчас безопасно только Query/Router/Table/Form/Store
• Рекомендация автора: Query ставьте уже сегодня, Router — на новом greenfield-проекте, Start — пока наблюдайте

Что сейчас вообще такое TanStack

Два года назад TanStack означал одно: React Query — лучшая библиотека для фетчинга данных в экосистеме React. Простая, мощная, решала реальную проблему. Сегодня TanStack — это восемь взаимосвязанных библиотек, которые вместе образуют полноценную фронтенд-платформу.

• TanStack Query — заменяет ручной fetch + useEffect. Стабильна, 68% использования
• TanStack Router — заменяет React Router и роутинг Next.js. Стабильна
• TanStack Table — заменяет все табличные библиотеки сразу. Стабильна
• TanStack Form — заменяет React Hook Form. Стабильна
• TanStack Start — заменяет Next.js и Remix. RC, активно растёт
• TanStack Store — заменяет Zustand и Redux. Стабильна
• TanStack DB — заменяет Firebase и Supabase-клиенты. Бета
• TanStack AI — заменяет AI SDK других вендоров. Альфа

Два года назад — одна библиотека. Сегодня — целая платформа, которая может заменить ваш фреймворк. И почему-то большинство разработчиков до сих пор спят.

Момент, который всё изменил

Восемь месяцев назад я дебажил проблему с роутингом в проекте на Next.js. Конкретно — URL search params. Это когда фильтры, пагинация и сортировка живут в URL, чтобы пользователи могли делиться ссылками, а кнопка «Назад» работала правильно.

В Next.js для этого нужно жонглировать тремя хуками:

Работало. Но многословно. И не типобезопасно: searchParams.get('category') возвращает string | null, и TypeScript не знает, какие значения валидны. А потом я увидел, как коллега делает ровно то же самое через TanStack Router:

TypeScript точно знал, какого типа category и page. Он упал бы при компиляции, если бы я попытался установить невалидное значение. Состояние URL и типы TypeScript были в идеальной синхронизации. Я долго смотрел на этот код, потом открыл новую ветку и начал миграцию.

Цифры — State of React 2026

Здесь история перестаёт быть моей личной и становится чем-то большим. Опрос State of React 2026 — более 3700 разработчиков, опубликован в феврале 2026 — дал показательные результаты.

Next.js, который когда-то казался стандартом для фулстек-React, широко используется, но не особо любим: 80% респондентов им пользовались, у 17% — негативное отношение, основные жалобы на избыточную сложность и слишком тесную интеграцию с главным спонсором (Vercel).

А вот цифры по TanStack Query: 68% использования, 42% позитивного отношения, 1% негативного. Один процент негатива у библиотеки, которой пользуется 68% React-разработчиков. Это ненормально хорошие цифры. Для сравнения: у Next.js в 17 раз больше негатива при примерно том же охвате. Экосистема говорит. Большинство просто пока не слушает.

Почему TanStack выигрывает

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

Философия звучит так: владей своим кодом, а не фреймворком. Каждая библиотека TanStack — headless by design, то есть без встроенного UI: она занимается логикой, а вёрстку и стили делаете вы. Нет никакого готового TanStack-компонента, который нужно подгонять под свой дизайн. Нет TanStack-стилей, с которыми нужно воевать. Нет мнения TanStack о том, как должно выглядеть ваше приложение.

Сравните это с Next.js — там ваши <Image>, шрифты, роутинг и серверное поведение контролируются фреймворком. Вы получаете мощь, но платите вендор-лок-ином. «Vendor lock-in, сложные API и слишком много шума в экосистеме Next.js — для меня это no-go», — так сформулировал один из респондентов опроса. Ответ TanStack на эту жалобу — архитектурный: это не фреймворк, а набор строительных блоков. Код — ваш, решения — ваши, а TanStack просто берёт на себя сложные части.

Ключевые библиотеки, которые стоит знать прямо сейчас

1. TanStack Query — вы наверняка уже им пользуетесь

Если вы ещё не используете TanStack Query — остановитесь и поставьте его прямо сейчас: npm i @tanstack/react-query плюс обернуть приложение в QueryClientProvider. Я подожду.

Кеширование, фоновые рефетчи, stale-while-revalidate (показываем старые данные, пока подгружаются свежие), оптимистичные обновления, бесконечный скролл, devtools — всё в комплекте. Это точка входа в экосистему TanStack — именно с Query начинают большинство.

2. TanStack Router — тот, который удивит больше всего

Это библиотека, которая окончательно перетянула меня на сторону TanStack. Полная сквозная типизация по всему слою роутинга — не только пути, но и search params, контекст маршрута, данные лоадеров — всё типизируется от маршрута до компонента.

Если у вас хоть раз был баг из-за того, что useParams() вернул undefined, а TypeScript не предупредил — TanStack Router и есть ответ.

3. TanStack Form — наследник React Hook Form

React Hook Form — отличная библиотека. TanStack Form — это то, чем был бы React Hook Form, если бы его писали сегодня, с TypeScript-first подходом. Никаких строковых register('email') — все имена полей проверяются типами.

4. TanStack Start — альтернатива Next.js, которую никто не ждал

Это самое новое и самое спорное пополнение. TanStack Start — это меньше магии и больше контроля: вы сами решаете, как грузятся данные, где они запускаются и что рендерится. Типобезопасность отличная, и Start прекрасно дружит со всей остальной экосистемой TanStack. Полноценный fullstack-фреймворк поверх TanStack Router — SSR, стриминг, server functions, всё как в Next.js, но без привязки к Vercel и с end-to-end типизацией.

Больше не нужно гадать, что возвращает ваш API: типы текут от базы данных до компонента без единой ручной аннотации.

5. TanStack DB и AI — будущее, которое строится прямо сейчас

У TanStack есть несколько проектов на ранних стадиях: помимо стабильных Query/Router/Table/Form/Store, в бете — TanStack DB, в альфе — TanStack AI, а ещё есть TanStack CLI со встроенным MCP-сервером (Model Context Protocol) для работы с ИИ-агентами.

TanStack DB — реактивное клиентское хранилище данных: что-то вроде Firebase, но без привязки к вендору. TanStack AI — унифицированный интерфейс к разным ИИ-провайдерам: один и тот же API, независимо от того, дёргаете ли вы Claude, GPT-4 или Gemini. И то, и другое пока не прод — но они показывают, куда движется TanStack. Это уже не библиотеки, это платформа.

Честный контраргумент

Я выставил TanStack серебряной пулей. Это не так. Если ваша команда хорошо знает Redux и React Router, потеря продуктивности на изучение новых инструментов может не окупиться. У Next.js годы боевой эксплуатации на проде. Redux-разработчиков на рынке больше, чем TanStack-разработчиков, — это важно для найма. Если вам нужна скучная и предсказуемая технология, оставайтесь на привычном стеке.

Ещё один момент: если вам нужны React Server Components с полной прод-поддержкой уже сегодня — Next.js всё ещё ответ. И если ваша команда глубоко в Redux, а переход на новое означает месяцы переобучения, — цена, возможно, не оправдана. TanStack — отличный инструмент, но не всегда правильный выбор. Используйте его, когда его сильные стороны совпадают с вашими задачами.

Так стоит ли переходить

Честная рекомендация после шести месяцев жизни в экосистеме TanStack:

• Ставьте Query уже сегодня. Если вы ещё не пользуетесь — это самое выгодное по ROI изменение, которое можно сделать в React-кодбазе. Минимум риска, моментальный эффект, плюс это ворота в понимание философии TanStack
• Попробуйте Router на следующем greenfield-проекте (то есть новом, с чистого листа). Не мигрируйте существующее приложение — ценность яснее всего видна, когда вы стартуете с типобезопасности с первого дня
• Наблюдайте за Start. Он ещё не так стабилен, как Next.js. Но траектория понятна: разработчики, которые изучат его сейчас, получат заметное преимущество, когда он дойдёт до 1.0
• Следите за DB и AI. Оба слишком ранние для прода. Но они показывают амбиции команды TanStack — и, судя по её послужному списку, получатся отлично, когда будут готовы

Что всё это значит

TanStack выигрывает не потому, что маркетит себя лучше Next.js, и не благодаря виральным твитам или докладам на конференциях. Он выигрывает, потому что решает проблему, которая реально болит у React-разработчиков в 2026 году: слишком много магии, слишком много вендор-лок-ина, слишком много сложности, которая живёт не в вашем коде, а в фреймворке.

TanStack возвращает вам контроль. Полную типобезопасность. Никакого скрытого поведения. Никакой зависимости от вендора. Просто хорошо спроектированные примитивы, которые делают ровно то, что написано на коробке. В эпоху, когда ИИ пишет всё больше кода за нас, эта ясность важнее, чем когда-либо: ИИ-инструменты работают лучше с явным типизированным кодом, чем с магическими конвенциями фреймворков. TanStack не планировал съесть экосистему React. Он просто построил инструменты получше — и разработчики пошли за лучшими инструментами. Так экосистемы и меняются на самом деле — не анонсами, а пул-реквестами.

Источник: колонка TanStack is eating React's ecosystem and nobody is talking about it на dev.to. Автор: разработчик harsh2644. Перевод сокращён и адаптирован, авторские мнения сохранены.

Railway — облачная PaaS-платформа (аналог Heroku), которую используют десятки тысяч разработчиков для деплоя приложений. Их собственный фронтенд — дашборд, документация, маркетинговые страницы — работал на Next.js.

• Railway перевёл весь фронтенд с Next.js на Vite + TanStack Start
• Время сборки сократилось с 10+ минут до менее 2 минут
• Это часть тренда: крупные проекты всё чаще уходят с Next.js из-за сложности сборки и несоответствия App Router их архитектуре
• Railway — не первые: с Next.js публично уходили Kent C. Dodds и другие команды

Почему ушли с Next.js

По словам команды Railway, основные проблемы были связаны с временем сборки и сложностью инфраструктуры. Next.js-приложение Railway разрослось до такого масштаба, что каждый билд занимал более 10 минут — это тормозило CI/CD-пайплайн и замедляло итерации.

Дополнительные факторы:

• Несоответствие App Router модели Railway — у них client-first продукт, а App Router ориентирован на server-first подход
• Сложность конфигурации Next.js для нестандартных кейсов — когда приложение выходит за рамки «блога на Vercel», настройка становится нетривиальной
• Размер бандла и время cold start при серверном рендеринге

Что получили

После миграции время сборки упало с 10+ минут до менее 2 — ускорение более чем в 5 раз. Для команды, которая деплоит десятки раз в день, это означает экономию часов ежедневно.

Публикация вызвала бурное обсуждение на Hacker News (206 очков, 188 комментариев). Мнения разделились: одни поддержали решение, другие указали, что проблема не в Next.js, а в архитектуре конкретного приложения.

Часть тренда

Railway — не первые, кто публично уходит с Next.js. За последний год аналогичные решения приняли:

• Kent C. Dodds — публично отказался от Next.js в пользу Remix, который позже влился в React Router 7
• Многие команды переходят на Vite + React или SvelteKit для ускорения сборки

Общая тенденция: Next.js отлично подходит для проектов, которые деплоятся на Vercel и укладываются в стандартные паттерны. Для крупных client-first приложений с нестандартной инфраструктурой издержки фреймворка начинают перевешивать преимущества.

Для фронтенд-разработчиков это повод задуматься: фреймворк — инструмент, а не религия. Если сборка тормозит, DX деградирует, а большая часть фич фреймворка не используется — возможно, пора пересмотреть стек.

React — JavaScript-библиотека для создания пользовательских интерфейсов, разработанная Meta (ранее Facebook). Vue.js — прогрессивный фреймворк для создания UI, созданный Эваном Ю (Evan You). Оба инструмента используют компонентный подход и виртуальный DOM, но различаются в философии, синтаксисе и экосистеме.

— React лидирует по npm-загрузкам (429 млн/мес против 47 млн у Vue) и рынку вакансий

— Vue проще в освоении и имеет более целостную экосистему «из коробки»

— React 19.2 принёс Activity, Performance Tracks и useEffectEvent

— Vue Vapor Mode обещает производительность без виртуального DOM

— Для крупных корпоративных проектов React остаётся безопасным выбором

— Для быстрого старта и небольших команд Vue даёт преимущество в скорости разработки

React в 2026 — что нового

React продолжает эволюционировать. В 2025–2026 годах произошло несколько значимых событий, которые определили направление развития библиотеки.

React 19 и Server Components

React 19 стал самым масштабным обновлением со времён хуков. Server Components (RSC) — компоненты, которые рендерятся на сервере и не увеличивают клиентский бандл — перешли из экспериментального статуса в стабильный. Это позволяет снизить объём JavaScript, отправляемого клиенту, на 30–50% в типичных приложениях.

Ключевые нововведения React 19:

• Actions — встроенная обработка форм с серверными и клиентскими экшенами
• useOptimistic — хук для оптимистичных обновлений UI
• use() — новый хук для чтения промисов и контекста в рендере
• Нативная поддержка метаданных — title, meta, link можно рендерить прямо в компонентах
• Улучшенная поддержка Web Components — полная интеграция с кастомными элементами

React 19.2 и Compiler v1.0

Вышедший в 2026 году React 19.2 добавил экспериментальные фичи: Activity (управление жизненным циклом скрытых компонентов), React Performance Tracks (интеграция с DevTools для профилирования) и useEffectEvent.

Отдельное событие — выход React Compiler v1.0. Компилятор автоматически мемоизирует компоненты, устраняя необходимость ручного использования useMemo, useCallback и React.memo. По данным Meta, это сократило количество ре-рендеров в их приложениях на 40%.

React Foundation и Linux Foundation

В 2025 году React перешёл под управление React Foundation при Linux Foundation. Это означает более открытое управление проектом и снижение зависимости от одной компании. Для разработчиков это сигнал долгосрочной стабильности.

Vue в 2026 — что нового

Vue тоже не стоит на месте. Хотя темп обновлений ниже, чем у React, каждый релиз Vue приносит продуманные и обратно совместимые улучшения.

Vue 3.5 — стабильность и производительность

Вышедший в сентябре 2024 года Vue 3.5 ("Tengen Toppa Gurren Lagann") сфокусирован на внутренних улучшениях производительности. Реактивная система была оптимизирована для более точного отслеживания зависимостей, а потребление памяти снижено на 56% по данным бенчмарков команды Vue.

Ключевые улучшения Vue 3.5:

• useTemplateRef() — типобезопасные ссылки на элементы
• Deferred Teleport — телепортация контента с отложенным рендерингом
• Lazy Hydration — ленивая гидратация для SSR-приложений
• useId() — генерация стабильных уникальных ID для SSR
• Улучшенный watch — deep watch с поддержкой паузы и возобновления

Vapor Mode — будущее без виртуального DOM

Vapor Mode — экспериментальный режим компиляции Vue, который генерирует код без виртуального DOM. Вместо создания виртуального дерева и его сравнения (diffing) Vapor Mode компилирует шаблоны в прямые DOM-операции. Это аналог подхода Svelte, но с сохранением API Vue.

По предварительным бенчмаркам, Vapor Mode показывает прирост производительности в 2–3 раза на операциях обновления. Проект находится в активной разработке на GitHub (2400+ звёзд), но пока не рекомендован для продакшена.

Nuxt 4 — полная переработка

Nuxt 4 вышел в 2025 году и уже добрался до версии 4.4. Это полная переработка мета-фреймворка для Vue с улучшенной архитектурой, нативной поддержкой серверных компонентов и обновлённым Nuxt UI v4. Для Vue-экосистемы Nuxt 4 — это то же, что Next.js для React.

Сравнение по критериям

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

Критерий / React / Vue

Производительность

В стандартных бенчмарках (js-framework-benchmark) React и Vue показывают сопоставимые результаты. React с Compiler v1.0 автоматически оптимизирует ре-рендеры, Vue 3.5 имеет более эффективную реактивную систему. На практике разница в производительности редко становится решающим фактором — оба фреймворка достаточно быстры для подавляющего большинства задач.

Реальная разница появляется в экстремальных сценариях: Vue Vapor Mode (когда выйдет из эксперимента) обещает преимущество за счёт отказа от виртуального DOM, а React Server Components снижают нагрузку на клиент, перенося логику на сервер.

Порог входа

Vue традиционно считается более дружелюбным к новичкам. Однокомпонентные файлы (SFC) с секциями <template>, <script> и <style> интуитивно понятны. Документация Vue — одна из лучших в индустрии.

React требует понимания JSX, хуков и однонаправленного потока данных. С приходом Server Components и Compiler порог входа вырос — нужно разбираться, какие компоненты серверные, а какие клиентские. По данным State of JS 2024, React назвали "избыточно сложным" чаще других фреймворков.

Экосистема

React обладает самой большой экосистемой в мире фронтенда. Next.js, Remix, React Native, тысячи UI-библиотек (Material UI, Ant Design, Chakra UI, shadcn/ui) — для любой задачи найдётся готовое решение. Обратная сторона — проблема выбора: для одной задачи существует десяток конкурирующих библиотек.

Vue предлагает более целостный подход. Официальные решения покрывают большинство потребностей: Vue Router, Pinia (стейт-менеджмент), Nuxt (SSR/SSG), Vuetify и PrimeVue (UI). Меньше выбора, но меньше и головной боли.

Рынок вакансий

По данным npm, React скачивают 429 млн раз в месяц против 47 млн у Vue — разрыв примерно в 9 раз. На GitHub суммарно у React 244 000 звёзд, у Vue — 263 000 (с учётом Vue 2 и Vue 3 репозиториев). Однако звёзды на GitHub не отражают реальное использование в продакшене.

На рынке труда React доминирует. По данным Stack Overflow Developer Survey 2024, React используют на работе значительно чаще, чем Vue. На hh.ru и LinkedIn вакансий с React в 3–4 раза больше, чем с Vue. Это важно для тех, кто строит карьеру.

Размер бандла

Минифицированный и сжатый (gzip) размер:

• React (react + react-dom): ~44 КБ
• Vue 3: ~33 КБ

Vue компактнее на ~25%. С React Server Components часть кода не попадает в клиентский бандл вовсе, что может нивелировать эту разницу. Vue Vapor Mode в будущем обещает ещё меньший размер за счёт tree-shaking рантайма виртуального DOM.

Поддержка TypeScript

Оба фреймворка отлично работают с TypeScript, но подходы различаются.

Vue 3 написан на TypeScript и предоставляет первоклассную типизацию «из коробки». <script setup lang="ts"> в SFC — лаконичный и типобезопасный способ писать компоненты. IDE-поддержка через Volar (теперь часть Vue Language Tools) значительно улучшилась.

React исторически использует .tsx файлы и имеет зрелую систему типов через @types/react. Типизация хуков и контекста может быть многословной, но хорошо документирована. React Compiler v1.0 полностью поддерживает TypeScript.

Когда выбрать React

React — оптимальный выбор в следующих ситуациях:

• Крупный корпоративный проект — максимальная экосистема, проще найти разработчиков
• Нужен React Native — единая кодовая база для веб и мобильных приложений
• Server-side rendering — Next.js с React Server Components даёт лучший в классе SSR
• Большая команда — огромное сообщество, много документации и готовых решений
• Карьерные перспективы — React-вакансий на рынке в 3–4 раза больше
• Сложные интерактивные интерфейсы — дашборды, real-time приложения, графические редакторы

React подходит тем, кто готов инвестировать время в изучение экосистемы и не боится "усталости от выбора" (framework fatigue). Если команда уже знает React — смена на Vue ради смены не имеет смысла.

Когда выбрать Vue

Vue — лучший выбор, когда:

• Быстрый старт проекта — от идеи до прототипа за минимальное время
• Небольшая команда — целостная экосистема снижает время на принятие решений
• Постепенная миграция — Vue можно внедрять по частям в существующий проект
• Обучение фронтенду — низкий порог входа, отличная документация
• Проекты на Laravel/Django/Rails — Vue традиционно хорошо интегрируется с серверными фреймворками
• Китайский рынок — Vue крайне популярен в Китае (Alibaba, Baidu, Xiaomi используют его)

Vue идеально подходит для команд, которые ценят прагматичность и хотят сфокусироваться на продукте, а не на выборе инструментов. Если проект не требует React Native или React-специфичных библиотек — Vue даст результат быстрее.

Выводы

В 2026 году и React, и Vue — зрелые, стабильные инструменты с активным развитием. Спор «что лучше» не имеет универсального ответа — выбор зависит от контекста проекта, команды и задач.

React и Vue решают одну задачу разными способами. Важен не фреймворк, а то, как вы его используете. Выбирайте инструмент под задачу, а не задачу под инструмент.

Выбирайте React, если вам нужна максимальная экосистема, React Native, Server Components или вы ориентируетесь на рынок труда. Выбирайте Vue, если цените скорость разработки, целостный developer experience и низкий порог входа.

Оба фреймворка продолжают развиваться: React движется в сторону серверного рендеринга и компиляции, Vue — в сторону максимальной производительности через Vapor Mode. Следите за обновлениями обоих проектов и выбирайте то, что делает вашу команду продуктивнее.

WordPress часто не любят backend-разработчики, и у каждого на это есть свои причины. Кому-то не нравится функциональный стиль разработки, кто-то критикует form-builder и экосистему плагинов. У других WordPress как CMS и PHP как язык программирования до сих пор ассоциируются со стереотипами 10–15-летней давности - будто они устарели и уступают современным технологиям.

При этом реальность такова, что и PHP, и WordPress - отличные и современные инструменты, которые очень хорошо выполняют свои задачи. Опустим PHP - статья не об этом. Что же можно сказать про WordPress как про продукт и как CMS?

WordPress по‑прежнему остаётся самой популярной системой управления контентом. Согласно данным команды WordPress, платформа обслуживает более 43% всех веб-сайтов и занимает долю в 61% на рынке CMS. Также статистика показывает, что WordPress используется примерно на 59% сайтов, где известна CMS (это около 42% всего веба).

Данные были взяты из официального блога WordPress и сайта w3techs.com:

• https://wordpress.com/blog/2025/04/17/wordpress-market-share/
• https://w3techs.com/technologies/overview/content_management
• https://w3techs.com/technologies/details/cm-wordpress

При этом, традиционный WordPress объединяет CMS, шаблоны на PHP и монолитные темы. Такая связка усложняет разработку с использованием современных JS фреймворков, а также затрудняет независимое масштабирование фронтенда и бэкенда, и оптимизацию производительности и безопасности. Жёсткая связка страниц, устаревшие PHP‑функции и не самый удобный девелоперский опыт часто заставляют команды искать альтернативы.

Headless WordPress решает эти проблемы: CMS становится админ-панелью для управления контентом, а отдельный фронтенд отвечает за UI. Такое разделение обязанностей даёт несколько преимуществ: четкое разделение ответственности, независимое масштабирование интерфейса и CMS, упрощенную локальную разработку и CI/CD. CMS превращается в API‑ориентированное хранилище, а современные фреймворки вроде Next.js берут на себя маршрутизацию и рендеринг.

Headless WordPress с использованием WPGraphQL

Чтобы использовать WordPress как headless‑CMS, нужен API. Также есть интересный пост про headless wordpress в их официальном блоге.

В WordPress из коробки есть REST API, но для frontend и mobile приложений часто удобнее использовать GraphQL. WPGraphQL - это open source плагин, который добавляет GraphQL API в WordPress. Используя WPGraphQL, мы получаем:

• Гибкие запросы к таким сущностям, как посты, страницы, произвольным типам постов, таксономиям и пользователям.
• Систему расширений которая позволяет расширять функционал GraphQL бекенда и таким образом поддерживать популярные плагины, тем самым позволяя возвращать дополнительные поля которые не относятся к стандартным полям Wordpress.
• GraphQL API, который даёт очень удобный формат для интеграции фронтенд фреймворков таких как Next.js, Astro и SvelteKit.
• Оптимизацию производительности, поскольку клиент запрашивает только нужные поля и данные делая один запрос вместо группы REST запросов + отдельный фронтенд забирает на себя часть запросов.

В дополнение к доступному функционалу WPGraphQL можно добавлять дополнительные плагины-расширения, такие как WPGraphQL Yoast SEO и WooGraphQL (WPGraphQL для WooCommerce). Таким образом добавив несколько плагинов в базовую инсталляцию CMS можно из коробки получить полностью функциональный GraphQL бекенд, который может покрыть запросы для блога, сео функционал, онлайн-магазин и тд.

Важно отметить, что изначальная идея использовать WPGraphQL пришла из статьи в блоге Vercel.

Фронтенд на Next.js

Next.js - production-ready React-фреймворк, который разрабатывается компанией Vercel. Многие используют его по умолчанию для разных headless‑проектов. Наш пример headless-wordpress не исключение. Фреймворк предлагает удобную маршрутизацию на базе файловой системы, где любой файл в папке pages автоматически становится маршрутом и поддерживает несколько стратегий рендеринга:

• Server‑side rendering (SSR) позволяет генерировать HTML при каждом запросе.
• Статическая генерация (включая [Incremental Static Regeneration])
• React Server Components, стратегия которая дает гибкость в балансировании производительности и кэширования.

Это делает Next.js хорошей платформой для работы с GraphQL API и рендеринга страниц React‑компонентами. Если у вас нет опыта с Next.js и React, то это не повод не попробовать набросать POC в свободное время. Современные Next.js и React templates + хороший AI agent помогут адаптировать UI под GraphQL для вас.

Почему Cloudflare?

Vercel очень часто является платформой по умолчанию для Next.js‑приложений. Более того Next.js адаптирован для запуска из коробки на серверах Vercel. При этом нужно добавить, что идея этой статьи не в том чтобы как-то компрометировать Vercel. Что же нужно знать про Cloudflare чтобы обратить внимание на этот сервис с точки зрения альтернативы для хостинга Next.js?

Согласно статистике, реверс-прокси сервисы Cloudflare используются примерно на 21,9% всех сайтов в интернете, а это более 82% сайтов, где используется прокси‑сервисы в принципе. Такая распространённость говорит о масштабе, надежности и глобальном охвате сервиса. Но Cloudflare - это не только reverse-proxy. Компания разрабатывает целую группу облачных сервисов, включая такие сервисы, как Cloudflare Pages - альтернатива Github Pages, Workers - Serverless functions (по аналогии с AWS Lambda), Контейнеры, Очереди, AI сервисы, R2 Object Storage, и другие. В дополнение ко всему, компания предоставляет такие сервисы, как защита сайта (site-protection), VPN и капча (human-detection captcha). Такое разнообразие сервисов делает сервис очень распространенным.

Лимиты бесплатного тарифа Cloudflare

Одним из самых интересных аргументов в пользу Cloudflare можно считать их бесплатный тариф. Защита от DDoS, Universal SSL и глобальную CDN доступны бесплатно. Также бесплатный тариф включает большинство из вышеперечисленных облачных сервисов. Например, Cloudflare Workers, который можно использовать для хостинга Next.js-проектов, бесплатно даёт 100,000 запросов в день. Или R2 object storage - альтернатива S3 по умолчанию дает 10GB пространства, которое можно использовать для хранения статики или других данных. Этого более чем достаточно чтобы поэкспериментировать на выходных с новым стеком и вполне достаточно для того, чтобы бесплатно хостить ваш проект до тех пор пока у вас не пойдет серьезный трафик. Ниже приведена таблица с некоторыми из Cloudflare сервисов и что включено в бесплатный тариф.

Запуск Serverless функций на edge-серверах

Cloudflare Workers позволяют запускать серверлесс‑код по всей сети Cloudflare. Ниже приведено изображение показывающее как работает Edge CDN, когда например статика продублирована на все доступные сервера и таким образом пользователь получает ресурсы с самого близлежащего сервера.

Эта картинка хороша тем, что аналогично CDN статике на этих же серверах можно запускать и Workers (Lambda) функции, тем самым ускоряя вашу инфраструктуру еще больше.

Одной из интересных особенностей Workers-функций является отсутствие cold-starts. Любой cloud provider обычно подымает docker container или виртуализированное окружение в момент первого запуска программы, а это всегда задержка. Минусом Workers-функций является тот факт что их Runtime API требует чтобы код мог использовать их Web platform APIs. А это в свою очередь ограничивает выбор языка программирования: Javascript, Typescript и WebAssembly. Но благодаря такому подходу Workers используют изолированную модель запуска и могут быть прогреты еще до момента запуска кода этого воркера. Прогрев начинается еще на этапе TLS-соединения между клиентом и серверами Cloudflare. Полный текст статьи можно почитать в их блоге.

Воркеры выполняются на edge-серверах, которые находятся ближе всего к пользователям, тем самым уменьшая задержку и разгружая origin‑сервер (в нашем случае WordPress backend). По аналогии с другими cloud-провайдерами, код внутри Workers Runtime может использовать другие сервисы Cloudflare, такие как:

• Cache API - позволяет читать и записывать данные в глобальный edge‑кэш через caches.default, что удобно для кэширования GraphQL‑ответов или страниц Next.js.
• Workers KV - распределенное key‑value‑хранилище для конфигурации и небольших наборов данных; можно хранить и получать данные глобально с низкой задержкой.
• Cron Triggers - можно сопоставить cron‑выражение с обработчиком scheduled(), чтобы запускать периодические задачи, например, уборку кэша или обновление данных. Триггеры выполняются на малоиспользуемых машинах, максимизируя эффективность.

Наличие доступа к дополнительным сервисам, таким как базы данных (D1), объектное хранилище (R2), очереди и AI даёт свободу строить более сложные и гибкие архитектуры, что очень полезно в дальнейшем на больших масштабах.

OpenNext: мост между Next.js и Cloudflare

Самостоятельный деплой Next.js на разные платформы непрост, поскольку среда исполнения Vercel отличается от других. Можно поднять Next.js на Node‑сервере, но его работа отличается от edge‑режима Vercel. OpenNext - это проект с открытым исходным кодом, который адаптирует Next.js для разных серверлесс‑платформ. Важно сказать что у Next.js нет нативного способа само разворачивания на других платформах, кроме Vercel; существующие отдельные адаптеры разрознены и сложны в поддержке. OpenNext объединяет усилия в одном адаптере, переводя выход сборки Next.js в формат, совместимый с основными облачными платформами. Проект поддерживают сообщество SST (AWS), команда Cloudflare и Netlify. Соответственно, с помощью OpenNext можно развернуть Next.js на Cloudflare Workers, сохраняя SSR, статическую генерацию и API‑маршруты.

Cloudflare‑адаптер устанавливается через @opennextjs/cloudflare. Далее следует установить Wrangler, настроить wrangler.toml с вашим Account ID и создать open-next.config.ts для управления кэшем и ассетами. Адаптер собирает приложение Next.js под среду Cloudflare, создает edge‑воркер и конфигурирует кэш для статики и ISR‑страниц (например, используя R2). После публикации Git‑интеграция Cloudflare автоматически разворачивает приложение при каждом пуше в GitHub или GitLab, а для pull‑request создает превью.

Кэширование и уровни производительности

Архитектура headless WordPress + Next.js + Cloudflare обычно включает несколько уровней кэша:

1. Кэш браузера - стандартный HTTP‑кэш на стороне клиента.
2. Кэш edge‑рантайма - Cache API Cloudflare Workers сохраняет HTML‑страницы или GraphQL‑ответы рядом с пользователем; при попадании в кэш контент отдаётся мгновенно, а промахи идут к воркеру или origin.
3. Кэш ISR Next.js - технология Incremental Static Regeneration сохраняет отрендеренные страницы на сервере и обновляет их по запросу, снижая нагрузку на WordPress API.
4. Кэш GraphQL - API WPGraphQL может реализовывать кэширование по времени или тегам (например, через WPGraphQL Smart Cache), чтобы управлять сроком жизни ответов.

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

Пример конечной архитектуры показан на изображении ниже.

Автоматизация периодических задач

Headless‑сайтам часто требуются периодические действия - например, обновление кэша ISR или синхронизация данных. Cron Triggers Cloudflare позволяют планировать запуск воркера по cron‑выражению. Обработчик scheduled() срабатывает по расписанию и подходит для обслуживания и получения сторонних данных. Триггеры выполняются на малоиспользуемых машинах по всему миру и легко управляются через Wrangler или панель Cloudflare.

Модернизация PHP‑стека с Roots toolkit

Хотя headless WordPress переносит рендеринг на JavaScript, CMS всё ещё нужно поддерживать. В качестве бонуса хочется порекомендовать экосистему Roots, которая предлагает современный инструментарий для разработки на WordPress:

• Bedrock - шаблон WordPress, которая устанавливает ядро, плагины и темы через Composer. Таким образом Bedrock дает современную для PHP проектов структуру проекта, улучшает структуру папок, использует концепты Двенадцать факторов для конфигурации приложения с помощью .env‑файлы и тд. Более того, управление зависимостями через Composer повышает надежность и позволяет делать деплой приложения на разные сервера без страха что-то забыть или упустить.
• Sage - стартовая тема WordPress, использующая Blade от Laravel для шаблонов и интегрирующая Tailwind CSS. Sage автоматически генерирует theme.json из конфигурации Tailwind, поддерживает live preview блокового редактора с Vite и позволяет создавать компоненты на Blade. Это помогает фронтенд‑разработчикам отойти от устаревших подходов для разработки тем Wordpress с нуля.
• Trellis - DevOps‑инструмент на базе Ansible, который поднимает серверы и автоматизирует деплой. Trellis предоставляет LEMP‑стек (Ubuntu 24.04, Nginx, PHP 8.3, MariaDB), выполняет деплой без downtimes и из коробки поддерживает SSL‑сертификаты. CLI помогает создавать и настраивать серверы, а также разворачивать проекты с атомарными релизами и откатами.
• Acorn - интеграция, позволяющая использовать функционал Laravel в WordPress. С Acorn становятся доступны такие инструменты как Blade‑шаблоны, миграции, роутинг, кэширование и Artisan‑подобный CLI внутри WordPress. Это позволяет разработчикам строить плагины и фичи WordPress с использованием современных PHP‑подходов и современного фреймворка .

Эти инструменты показывают, что экосистема WordPress продолжает развиваться и хорошо сочетается с современными подходами. Иными словами, WordPress - отличное решение, если знать, как его правильно готовить.

Собираем всё вместе

Архитектура приложения headless WordPress + Next.js + Cloudflare выглядит приблизительно так:

1. WordPress (headless) - работает на традиционном сервере или в контейнере. Редакторы управляют контентом в админке. WPGraphQL и его расширения предоставляют GraphQL‑endpoint с данными, SEO и другой информацией, например данными о магазине.
2. Next.js фронтенд - React‑приложение, которое получает данные через GraphQL, рендерит страницы на сервере (SSR) или статически (ISR/SSG) и обрабатывает маршрутизацию и взаимодействие с клиентом. Код хранится в Git и автоматически разворачивается благодаря Git‑интеграции Cloudflare.
3. Cloudflare Workers - размещают приложение Next.js на edge через OpenNext. Workers исключают cold-starts и работают по аналогии с CDN как можно ближе к пользователю. Они также выполняют кэширование, обрабатывают API‑маршруты и запускают cron‑задачи.
4. Кэш на edge и в браузере - несколько уровней кэша гарантируют быструю отдачу статики и отрендеренных страниц. KV, R2 или D1 могут хранить дополнительные данные вроде сессий или объектов.

Заключение

Headless‑архитектура объединяет универсальность WordPress и гибкость современных JavaScript‑фреймворков. Экспонируя контент через WPGraphQL и потребляя его в Next.js, можно получить больше контроля над рендерингом и тем самым улучшить производительность. Размещение фронтенда на Cloudflare Workers через OpenNext позволяет приблизить фронтенд код к пользователям, устраняет cold-starts, позволяет использовать free-tier и продвинутые уровни кэширования. Инструменты вроде Bedrock, Sage, Trellis и Acorn модернизируют PHP/Wordpress‑сторону и делают CMS такой же удобной в работе, как и современный Next.js/React-фронтенд. Вместе эти технологии создают мощный стек для создания быстрых, масштабируемых и безопасных сайтов, будь то хакатон, pet‑проект или серьёзный продакшн.

Пользователь может транслировать презентацию через "AI Кликер", а сервис будет записывать и транскрибировать речь спикера и аудитории. Спикер может переключать слайды простыми голосовыми командами или ключевыми словами, привязанными к конкретным слайдам.

Интеграция LLM позволяет реализовать интеллектуальные функции - переключение слайдов по описанию, контексту, генерация нового контента в реальном времени. Целевая аудитория — учителя, преподаватели и спикеры, на постоянной основе работащие с презентациями.

Архитектура решения

Наша команда использует JavaScript с React на фронтенде и Python c FastAPI на бэкенде. Мы используем PosgtreSQL как базу данных и S3 как объектное хранилище для хранения презентаций. Мы строим микросервисную архитектуру в нашем приложении.

Первый сервис - REST API для авторизации, управления личным кабинетом и контентом пользователя. Развернут на отдельном дешевом сервере за прокси NGINX, запросы шифруются HTTP

Второй сервис - API трансляции презентации. Двустороннее взаимодействие браузера и этого сервиса (передача звука и отдача команд по переключению слайдов) идет по протоколу WebSocket Secure. Отдельный сервис для трансляции позволяет нам динамически управлять дорогими серверами с GPU, уничтожать их, поднимать, экспериментировать с конфигурациями, не переживая о сохранности основного приложения. Модель OpenAI Whisper используется для транскрибации речи и GigaChat от Сбера как LLM для анализа контекста выступления и генерации команд и контента.

Работа Whisper

В AI-кликере распознавание речи - фундамент всей системы. Пока человек говорит, система должна получить текст, проверить команды, сопоставить с ключевыми словами, передать в LLM. Для этого обычного Whisper недостаточно — он отлично работает с файлами, но плохо подходит для живого потока.

Поэтому в проекте используется связка Whisper + WhisperLiveKit — библиотека, которая позволяет кормить модель аудио чанками в реальном времени, а не загружать готовые записи.

Байпас: ручное управление голосом

Одна из ключевых фич — байпас-режим. Это механизм, который позволяет управлять презентацией жёсткими голосовыми командами, в обход всей нейросетевой логики.

Когда Whisper отдаёт текст, он сначала проверяется не через LLM, а через механизм сопоставления фраз:

Дальше всё работает просто:

• если пользователь сказал фразу, похожую на “кликер вперёд” → слайд листается вперёд;
• если “кликер назад” → слайд листается назад.

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

Ключевые слова: автоматический переход на нужный слайд

Вторая важная часть — режим ключевых слов. Это уже не просто “вперёд/назад”, а сопоставление речи с конкретными слайдами.

Логика такая:

1. Для презентации загружается набор ключевых фраз, который группируется по номеру слайда.
2. Когда приходит новый фрагмент речи — он сравнивается с ключевыми словами и в случае успеха отправляет команду на переключение:

То есть фактически система работает как голосовой навигатор по презентации:

• сказал фразу, связанную со слайдом 5 → система предлагает перейти на 5;
• сказал фразу из блока 10 → прыжок сразу туда

При этом переход отправляется в очередь и дополнительно проверяется по порогу уверенности:

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

Работа с LLM (Гигачат) - промпты, контексты, очереди

Если Whisper в AI-кликере отвечает за то, чтобы услышать, то GigaChat отвечает за то, чтобы понять, о чём сейчас говорит спикер и какой слайд этому соответствует. Вся работа с LLM построена асинхронно: распознанная речь не блокирует систему, а складывается в очередь и обрабатывается в фоне. Каждый фрагмент речи:

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

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

В чём возникла основная проблема?

Текущая концепция работы LLM строится на предугадывании номера слайда по смыслу речи. И именно здесь в реальных условиях всплыла главная боль проекта. На живых выступлениях выяснилось, что GigaChat может путаться между похожими слайдами и менять своё решение от фразы к фразе. В итоге презентация иногда начинала хаотично перелистываться, даже если спикер говорил последовательно и спокойно. Для пользователя это выглядит как будто “нейросеть сошла с ума и живёт своей жизнью”.

Пока проблема не решена полностью, в системе есть страховочный механизм — временное отключение GigaChat при ручном управлении. Если пользователь даёт жёсткую голосовую команду (байпас), то нейросеть временно игнорируется, а управление полностью возвращается человеку. Через несколько секунд автоматика включается обратно, что позволяет не ломать выступление даже в моменты, когда LLM начинает вести себя нестабильно

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

• было - нейросеть угадывает номер следующего слайда.
• станет - нейросеть находит слайд по его описанию. После определенной команды, система слушает пользователя, пока он не закончит предложение (как умная колонка) и тогда один раз выбирает и переключает слайд. Это снижает вероятность случайных переключений и делает поведение системы более предсказуемым.

Итоги

Мы продолжаем реализацию проекта и планируем скорый выход на рынок. Реализация местами еще сырая, но мы стараемся тестировать решение с фокус-группой профессионалов, работающих с презентациями, чтобы выработать лучшие решения, удобные для них. У нас получилось выиграть небольшой студенческий грант на реализацию, это поможет нам оплатить сервера и работу разработчиков.

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

Как изменилась профессия и что теперь требуют от фронтендера

Если лет пять назад от вас ждали уверенную верстку, JavaScript и один фреймворк, то сегодня к этому прибавились архитектура, серверные рендеринги, работа с AI-инструментами и понимание, как всё это уживается на проде. Современный фронтенд стал более инженерным: теперь вы не просто “собираете интерфейс”, а участвуете в создании части системы.

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

Стек, который в 2025 уже обязателен

Начнём с основы — технологий, без которых трудно представить работу фронтендера.

TypeScript окончательно стал стандартом. Это уже не “приятное дополнение”, а часть культуры. Большие команды без типизации работать не могут — слишком дорого обходятся ошибки и непредсказуемые зависимости.

JavaScript тоже не стоит на месте: ежегодно появляются полезные нововведения, которые упрощают работу с асинхронностью, структурами данных и синтаксисом. Те, кто следят за ECMAScript, всегда ощущают себя увереннее остальных: код становится чище, а решения — элегантнее.

Во фронтенде всё больше внимания уделяется браузерным API. WebGPU, новые возможности Storage, нативные анимации — всё это сильно снижает потребность в тяжёлых библиотеках и позволяет делать вещи, которые раньше были попросту невозможны. Чем лучше вы понимаете браузер, тем реже сталкиваетесь с ограничениями.

Фреймворки: что происходит, и куда всё движется

React по-прежнему доминирует, но теперь уже невозможно говорить о React в отрыве от Next.js или серверных компонентов. Это целая новая парадигма, где часть логики уезжает на сервер, а приложение начинает работать быстрее и экономнее. Для многих разработчиков переход на RSC становится точкой, где React ощущается как совершенно другой инструмент.

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

Angular в 2025 году остаётся выбором крупных компаний и проектов, где важны строгая структура и предсказуемость. Благодаря встроенному DI, мощному CLI и единому стилю разработки он помогает быстрее масштабировать команды и поддерживать большие приложения.

Архитектура: что фронтендер обязан понимать в 2025

Современная разработка уже не обходится без SSR, SSG или ISR. Рендеринг стал частью оптимизации, а значит нужно понимать, почему одни страницы стоит отдавать с сервера, а другие — генерировать заранее.

Edge-функции — еще одно направление, которое стремительно набирает обороты. Когда код выполняется ближе к пользователю, интерфейс работает быстрее, а логика становится гибче. Если раньше подобные вещи интересовали только backend-разработчиков, то теперь это важный элемент фронтенд-экосистемы.

Микрофронтенды остаются актуальными для крупных команд. Они не всегда нужны, но если продукт растет, а структура усложняется, этот подход заметно снижает хаос.

Как AI меняет работу разработчика

AI перестал быть экспериментом — он стал полноценным участником рабочего процесса. Хорошие специалисты уже воспринимают его не как угрозу, а как инструмент.

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

Компании в 2025 году всё чаще спрашивают не “умеете ли вы пользоваться AI”, а “как именно он встроен в ваш рабочий процесс”.

Ключевые навыки, без которых сейчас не обойтись

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

Второе — доступность. A11y перестала быть “бонусом”. Это требование. Интерфейс должен быть удобен всем пользователям, независимо от их ограничений, и компании всё чаще контролируют этот аспект.

Третье — автоматизация. CI/CD, базовая работа с пайплайнами, понимание, как собирается и проверяется код — всё это экономит время и снижает число ошибок. Чем сильнее разработчик в автоматизации, тем надёжнее продукт.

Софт-скиллы, о которых всё чаще говорят

Поскольку команды становятся более распределенными, важным навыком стала коммуникация — умение четко формулировать свои мысли, обсуждать решения и объяснять сложные вещи так, чтобы вас понимали.

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

И, конечно, продуктовое мышление. Хороший фронтендер давно перестал цениться только за чистый код. Намного важнее, когда вы понимаете, какие решения действительно улучшают продукт, а какие — лишь выглядят технологично.

Заключение

2025 год стал переломным для фронтенда. Порог входа вырос, но вместе с этим вырос и потенциал — теперь разработчик может влиять на продукт намного сильнее. “Самое нужное для фронтендера в 2025” — это не столько конкретный стек, сколько способность мыслить шире: понимать архитектуру, разбираться в инструментах, не бояться AI и постоянно развиваться.

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

Проект выглядит как ChatGPT, но под капотом — работа через OpenRouter и цепочка из трех этапов: сбор ответов, взаимная оценка и «решение совета» .

Карпати честно пишет, что это «на 99% вайб-кодинг», субботний хак для души. И он не планирует развивать проект. Но сообщество уже разнесло репозиторий по соцсетям — идея демократичного «совета ИИ» оказалась вирусной.

Как работает LLM Council

По задумке Карпати, механизм должен показать, как разные модели видят одну и ту же задачу — и что они думают о чужих ответах.

1. Первая стадия — мнения. Каждая модель получает вопрос и генерирует свой ответ. В интерфейсе они показываются в отдельных вкладках, чтобы можно было сравнить.

2. Взаимные ревью. Затем модели получают ответы своих «коллег», но с анонимизацией имен, чтобы не было фаворитизма. Каждая модель ранжирует остальные по точности и полезности .

3. Финальное решение. Выбранный «председатель» — любая из моделей, которую укажет пользователь — собирает всю критику, мнения и свои выводы в итоговый ответ. Получается что-то вроде консенсуса.

Что внутри

В README Карпати описывает минималистичный стек:

• Backend: FastAPI + async httpx, работа через OpenRouter API.
• Frontend: React + Vite, рендеринг через react-markdown.
• Хранилище: JSON-файлы в data/conversations/.
• Управление проектом: uv для Python, npm для фронтенда .

Пользователь добавляет свой OPENROUTER_API_KEY и при желании меняет «состав совета». По умолчанию туда входят GPT-5.1, Gemini 3 Pro Preview, Claude Sonnet 4.5 и Grok-4.

Зачем это вообще нужно

Карпати пишет, что пилил проект для совместного с LLM чтения книг и сравнения, как разные модели анализируют один и тот же материал. Но по факту инструмент получился куда интереснее:

• это способ быстро оценить качество моделей;
• это визуализатор «множественного ИИ-мышления»;
• это мини-демонстрация того, как устроены будущие агентные системы, где несколько моделей принимают решения совместно.

И да, все это — буквально субботний хак, который уже набрал несколько тысяч звезд на GitHub.

Помимо стандартной редакции Workstation, обновление получили и все спины, лаборатории и атомарные сборки.

Пользователи Fedora 42 уже начали получать уведомления о доступности апдейта, но при желании систему можно обновить вручную — через GNOME Software или с помощью командного обновления.

Новый веб-инсталлятор Anaconda WebUI

Главное нововведение Fedora 43 — это новый веб-инсталлятор Anaconda WebUI, который теперь используется по умолчанию во всех сборках дистрибутива.

Ранее он тестировался только в Fedora Workstation 42, а теперь стал стандартом. Новый интерфейс написан с нуля на React и PatternFly и работает через локальный веб-сервер.

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

Разработчики отмечают, что Anaconda WebUI будет проще адаптировать под новые сценарии — например, автоматическую установку на серверах или в контейнерах.

GNOME теперь только на Wayland

Fedora 43 полностью отказалась от Xorg в пользу Wayland. Это изменение следует за решением GNOME upstream, где X11 был отключен на этапе сборки GNOME 49.

Теперь Fedora Workstation запускается исключительно на Wayland, что должно улучшить безопасность, поддержку HiDPI-экранов и работу с сенсорными устройствами.

При этом Xwayland по-прежнему остается в системе для совместимости со старыми приложениями.

Что нового под капотом

• Fedora 43 перешла на RPM 6.0, что принесло новые механизмы безопасности, включая поддержку мультиподписей пакетов — шаг к внедрению постквантовых криптографических ключей OpenPGP.
• Обновления Fedora CoreOS теперь распространяются только в формате OCI-образов, а устаревший механизм OSTree окончательно выведен из обращения.
• Улучшена интеграция с Flatpak и Podman, а также ускорена работа DNF при разрешении зависимостей.

Как установить Fedora 43

Пользователи Fedora 42 могут выполнить обновление в несколько кликов через центр обновлений GNOME или в терминале командой:

Для чистой установки рекомендуется воспользоваться Fedora Media Writer — он доступен для Windows, macOS и Linux.

Есть веская причина, по которой многие разработчики задумываются, прежде чем использовать в JavaScript методы .sort(), .reverse() или .splice(): эти методы изменяют исходный массив. Такой побочный эффект может привести к скрытым, трудноуловимым ошибкам — особенно в приложениях с общим или реактивным состоянием.

Хорошая новость в том, что за последние пару лет в JavaScript появились новые методы работы с массивами, которые делают этот процесс более безопасным и чистым, полностью избегая мутаций:

• toSorted()
• toReversed()
• toSpliced()

Эти методы возвращают копии массивов, вместо того чтобы изменять оригинал. Это небольшое, но важное обновление синтаксиса — особенно для разработчиков на React, где неизменяемость данных (immutability) — ключ к правильному управлению состоянием.

Проблема методов, изменяющих массив «на месте»

В JavaScript традиционные методы, такие как .sort(), .reverse() и .splice(), модифицируют сам массив, на котором были вызваны:

В таких фреймворках, как React, это может привести к непредсказуемому поведению при обновлении состояния, поскольку прямое изменение массивов не вызывает повторный рендер.

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

• Для сортировки вместо arr.sort(), который изменяет исходный массив, теперь можно использовать arr.toSorted(), возвращающий новый.
• Для обратного порядка вместо arr.reverse() следует применять arr.toReversed(), чтобы сохранить оригинал.
• Для удаления или вставки элементов вместо arr.splice() можно использовать arr.toSpliced(), который создаёт копию массива с изменениями, не трогая исходный.

Эти новые методы работают так же, как и их «изменяющие» аналоги, но вместо модификации исходного массива возвращают новый.

⚠️ Важно: это поверхностные копии, поэтому если массив содержит объекты, сами объекты останутся теми же ссылками, а не новыми экземплярами.

Решение: безопасные, не изменяющие оригинал методы

В стандарте ES2023 появились новые версии привычных методов массивов, которые не изменяют исходный массив:

toSorted() — создаёт отсортированную копию массива, не затрагивая оригинал.

Вы также можете передать собственную функцию сравнения — точно так же, как в методе .sort():

toReversed() — возвращает обратную копию массива, не изменяя исходный порядок элементов в оригинале.

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

toSpliced() — это более безопасная альтернатива методу .splice(). Она возвращает новый массив с добавленными или удалёнными элементами, не затрагивая оригинал.

Напоминание: метод .splice() возвращает удалённые элементы, а .toSpliced() — обновлённый массив.

Почему это важно в React

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

Новые методы позволяют работать с массивами как с неизменяемыми структурами данных, не прибегая к использованию structuredClone() или сложных обходных решений для глубокой копии.

Практический пример: сортировка задач в React

Вот как можно использовать toSorted() или toReversed() в компоненте, чтобы безопасно отображать динамические списки, не изменяя исходные данные:

Такой подход избегает изменения массива tasks, что особенно важно, если он передан через props или вычисляется из state — в противном случае могут возникнуть ошибки. Кроме того, использование операторов опциональной цепочки (?.) и объединения с null (??) помогает предотвратить сбои, если tasks окажется undefined.

И это ещё не всё! Оба этих оператора — опциональная цепочка и nullish coalescing — улучшения синтаксиса, делающие код более надёжным и устойчивым к ошибкам во время выполнения, приближая его к современному стандарту JavaScript.

Маленькое изменение в синтаксисе — большое улучшение

Эти методы не требуют нового подхода к мышлению — это просто безопасные, неизменяемые версии уже привычных вам инструментов. Если вы работаете в современной среде (или используете сборщики вроде Babel или SWC), вы можете начать применять их уже сегодня.

Поддержка браузерами

Методы toSorted(), toReversed() и toSpliced() поддерживаются во всех современных средах:

✅ Chrome / Edge — с версии 110+

✅ Safari — с версии 16+

✅ Firefox — с версии 115+

✅ Node.js — с версии 20+

Для старых окружений можно использовать полифил, например, из библиотеки core-js.

Основные выводы

Метод .toSorted() возвращает отсортированную копию массива, не изменяя оригинал. Метод .toReversed() создаёт новый массив в обратном порядке, также без мутаций исходного. Метод .toSpliced() возвращает изменённую копию массива — с добавленными или удалёнными элементами, но оригинальный массив остаётся нетронутым.

ES2023 принёс не только заметные обновления вроде опциональной цепочки и top-level await, но и такие, казалось бы, мелкие улучшения, которые делают код чище, понятнее и безопаснее. Попробуйте использовать новые методы в своих проектах — и вы больше не будете смотреть на .sort() с тем же доверием.

Теперь Bun официально позиционируется как full-stack платформа для фронтенда и бэкенда. И она объединяет сервер, сборщик, менеджер пакетов вместе с тест-раннером в одном инструменте.

В новую версию добавлены десятки ключевых функций: встроенные клиенты для Redis, MySQL, PostgreSQL и SQLite, единый SQL API, улучшенные WebSocket-модули, переработанный тест-раннер и поддержка VSCode Test Explorer.

Full-stack по-умному

Главное новшество — режим full-stack Bun.serve() с поддержкой роутинга, cookies и WebSockets.

Теперь фронтенд и бэкенд можно запускать в одном процессе без проблем с CORS, а приложение собрать в единый исполняемый файл с помощью bun build --compile.

Разработчики могут напрямую импортировать HTML, запускать React-приложения с хот-перезагрузкой и собирать проект одной командой bun init --react. По данным команды, скомпилированные React-приложения в Bun работают до 1,8 раза быстрее, чем через nginx.

Новый SQL и встроенный Redis

Bun 1.3 представил унифицированный Bun.SQL API — теперь один и тот же код работает с MySQL, PostgreSQL, SQLite и MariaDB. Добавлен хелпер sql.array() для работы с массивами в PostgreSQL, улучшена поддержка JSON и Unix-сокетов.

Кроме того, в рантайм встроен Redis-клиент, который поддерживает 66 команд, автоматическое переподключение, очереди сообщений и Pub/Sub. По данным разработчиков, он значительно быстрее ioredis, а поддержка кластеров и Lua-скриптов появится в будущих релизах.

Новые возможности

Среди прочих улучшений — Zstandard-сжатие, нативная поддержка YAML, API для безопасного хранения секретов (Bun.secrets), и серьезный прирост производительности: операции с криптографией ускорены до 400х, установка пакетов — до 2,5х.

Также обновлен менеджер пакетов с интерактивным bun update, изолированными установками и API для проверки безопасности зависимостей.

Почему это важно

Bun 1.3 превращает экспериментальный рантайм в полноценную платформу для веб-разработки, способную заменить Node.js, Vite и Redis-CLI одновременно.

Разработчики называют релиз «началом новой эпохи», цель которой — сделать Bun лучшим способом писать и развертывать JavaScript-приложения.

GPT-5 — флагманская reasoning-модель с упором на агентные сценарии, кодинг, интеллект и управляемость. «Из коробки» она хорошо решает широкий спектр задач, но качественные промпты (подсказки) заметно повышают стабильность, скорость и соблюдение инструкций. Ниже — проверенные практики, готовые шаблоны и заметки по параметрам API (reasoning_effort, verbosity, Responses).

Предсказуемость агентного рабочего процесса

Используйте API Responses для агентов

Responses сохраняет логические следы между вызовами инструментов: это снижает задержку, экономит токены и повышает качество планов за счёт механизма previous_response_id.

Контролируйте «рвение» агента

Сдержанный режим (меньше вызовов, ниже задержки):

• Установите reasoning_effort=low|medium.
• В подсказке ограничьте глубину поиска контекста и задайте ранние критерии остановки.

Проактивный режим (больше автономии и настойчивости):

• Поднимите reasoning_effort.
• Включите явное требование «не возвращаться к пользователю до полного решения».

Если вы готовы к максимально строгому регулированию, то можете установить фиксированный бюджет на вызовы инструментов, как показано ниже. Бюджет, естественно, может варьироваться в зависимости от желаемой глубины поиска.

При ограничении основного поведения сбора контекста полезно явно предоставить модели запасной вариант, облегчающий выполнение более короткого этапа сбора контекста. Обычно это делается в виде условия, позволяющего модели продолжать работу в условиях неопределенности, как «even if it might not be fully correct» в примере выше.

С другой стороны, если вы хотите поощрить автономность модели, увеличить настойчивость в вызове инструментов и сократить количество уточняющих вопросов или иных случаев возврата информации пользователю, рекомендуется увеличить reasoning_effort и использовать такой промпт, чтобы поощрить настойчивость и тщательное выполнение задачи:

Хорошая практика — чётко указать условия остановки задач агента, обозначить безопасные и небезопасные действия и определить, когда, если это вообще возможно, модель может вернуть данные пользователю. Например, в наборе инструментов для покупок инструменты оформления заказов и оплаты должны явно иметь более низкий порог неопределённости, требующий пояснений пользователя. В то же время инструмент поиска должен иметь чрезвычайно высокий порог; аналогично, в конфигурации кодинга инструмент удаления файлов должен иметь гораздо более низкий порог, чем инструмент поиска grep.

«Преамбулы» к инструментам (чтобы пользователь понимал, что происходит)

GPT-5 обучен предоставлять чёткие предварительные планы и последовательные обновления о ходе работы с помощью сообщений «преамбулы инструмента».

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

Вот пример преамбулы инструмента, которая может быть выведена в ответ на такой запрос. Такие преамбулы могут значительно улучшить способность пользователя следить за работой вашего агента по мере её усложнения:

Усилия рассуждения и повторное использование контекста

• reasoning_effort регулирует интенсивность размышлений и готовность к вызову инструментов. Значение по умолчанию — medium. Но для многошаговых задач повышайте этот показатель.
• Разбивайте сценарий на несколько ходов агента с сохранением previous_response_id в Responses — модель не тратит токены на перестройку плана.
• Настоятельно рекомендуют использовать API Responses в GPT-5, чтобы улучшить потоки агентов, снизить затраты и повысить эффективность токенов в приложениях. Авторы отмечают, что наблюдали статистически значимые улучшения в оценках при использовании API Responses по сравнению с завершением чата. Например, рост оценки Tau-Bench Retail с 73,9% до 78,2% был только благодаря переходу на API Responses и включению previous_response_id (функции передачи предыдущих элементов рассуждений в последующие запросы). Это позволяет модели ссылаться на предыдущие трассировки рассуждений, экономя токены и устраняя необходимость перестраивать план с нуля после каждого вызова инструмента, что снижает latency. Эта функция доступна всем пользователям API Responses.

Максимизация продуктивности в кодинге

GPT-5 умеет работать с крупными кодовыми базами, накатывать многофайловые изменения, рефакторить и строить новые приложения.

Рекомендованный стек для фронтенд-приложений

• Фреймворк: Next.js (TypeScript), React, HTML
• Стили/UI: Tailwind CSS, shadcn/ui, Radix themes
• Иконки: Lucide / Heroicons / Material Symbols
• Анимации: Framer Motion
• Шрифты: Inter, Geist, Mona Sans, IBM Plex Sans, Manrope

Разработка приложений с нуля

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

Соответствие стандартам разработки

При внедрении постепенных изменений и рефакторинга в приложения, код, написанный на основе модели, должен соответствовать стандартам стиля и дизайна и максимально аккуратно вписываться в кодовую базу. Без специальных подсказок GPT-5 автоматически ищет справочный контекст в кодовой базе, например, читая package.json для просмотра уже установленных пакетов. Но это поведение можно улучшить с помощью подсказок, обобщающих ключевые аспекты, такие как принципы разработки, структура каталогов и передовой опыт кодовой базы.

Фрагмент подсказки ниже демонстрирует один из способов организации правил редактирования кода для GPT-5: не стесняйтесь изменять фактическое содержание правил в соответствии со своими предпочтениями в программном дизайне.

Форматирование Markdown

По умолчанию GPT-5 в API не форматирует свои окончательные ответы в Markdown, чтобы обеспечить максимальную совместимость с разработчиками, чьи приложения могут не поддерживать рендеринг Markdown. Тем не менее, запросы, подобные следующему, в значительной степени успешно обеспечивают иерархические окончательные ответы в Markdown.

Иногда соблюдение инструкций Markdown, указанных в системном запросе, может ухудшаться в течение длительного разговора. Если вы столкнулись с такой ситуацией, стабильное соблюдение инструкций Markdown будет работать при добавлении их к каждому 3–5 пользовательскому сообщению.

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

Компании платят огромные деньги за ИИ-продукты, а потом ищут фрилансеров, чтобы починить их.

«Код ужасен»

Другой разработчик из Сан-Франциско признался, что ему пришлось удалить 90 файлов из 100 в React-проекте, созданном дизайнером через ИИ-редактор Cursor.

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

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

Давление и технический долг

Многие компании требуют от программистов «ускоряться с ИИ», но не умеют оценивать последствия. В итоге растет количество ошибок и технический долг — исправление становится дороже, чем ручная разработка.

Эксперты советуют ужесточить ревью и использовать ИИ не для написания, а для анализа кода. Первое правило — не доверять искусственному интеллекту ядро системы. «Пусть делает рутину, но не логику», — заявляют многие опытные разработчики.

Новый рынок

Парадоксально, но именно происходящее создает новый рынок: спрос на специалистов, способных «расчистить» ИИ-проекты, стремительно растет.

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

Почему скорость сайта так важна

В мире, где внимание пользователей рассеивается за восемь секунд, быстрая загрузка сайта становится критически важной. Статистика подтверждает: 53% мобильных пользователей покидают сайт, если он грузится дольше 3 секунд, а 70% потребителей отмечают, что скорость влияет на их решение о покупке. Walmart, например, зафиксировал рост конверсий на 2% за каждую секунду сокращения времени загрузки.

Быстрые сайты обеспечивают:

• Долгое пребывание пользователей на сайте;
• Больше просмотров страниц благодаря быстрой навигации;
• Меньше отказов из-за медленных загрузок;
• Выше конверсии и доходов, так как скорость напрямую влияет на покупки;
• Лучшую удовлетворенность и удержание пользователей;
• Рост органического трафика, так как Google учитывает Core Web Vitals в SEO-ранжировании;
• Экономию на CDN и трафике, ведь оптимизированные сайты потребляют меньше данных;
• Повышение качества рекламы в Google Ads, так как быстрые страницы снижают стоимость кликов.

Оптимизация фронтенда — это не просто техническая задача, а способ повысить лояльность пользователей и бизнес-показатели.

Как измерить производительность сайта

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

• Google PageSpeed Insights: быстрый аудит Core Web Vitals с рекомендациями.
• Chrome Lighthouse: встроенный в DevTools инструмент для анализа производительности, SEO и лучших практик.
• WebPageTest: детализированные метрики, визуализация загрузки и советы по оптимизации.
• GTmetrix: анализ скорости загрузки с рекомендациями.
• CrUX в Google Search Console: реальные данные пользовательского опыта (Core Web Vitals) для SEO.

Лабораторные инструменты дают контролируемые метрики, а мониторинг реальных пользователей (через Web Vitals JS, SpeedCurve или Calibre) показывает, как сайт работает в реальных условиях. Это поможет определить приоритеты для оптимизации.

Чек-лист оптимизации фронтенда 2025

Производительность — это командная работа. Бэкенд должен быть масштабируемым, UX-дизайнеры — балансировать визуал и скорость, а фронтенд-разработчики — реализовывать оптимизированный код. Этот чек-лист подходит для любой платформы: от Next.js и Astro до WordPress и PHP. Адаптируйте его под ваш проект, уделяя внимание ключевым метрикам, таким как LCP, CLS и INP (новый показатель, заменивший FID в 2024 году).

HTML

HTML — основа страницы, и его оптимизация ускоряет загрузку и улучшает пользовательский опыт.

• Приоритизируйте критический HTML: доставляйте HTML для верхней части страницы первым, чтобы браузер начал рендеринг. Фреймворки вроде Next.js или Astro с SSR/SSG рендерят HTML на сервере, улучшая First Contentful Paint.
• Удаляйте лишний код: уберите ненужные теги, комментарии и пробелы. Компактный HTML загружается быстрее, особенно в мобильных сетях.
• Включите сжатие: используйте GZIP или Brotli, чтобы уменьшить размер HTML. Большинство серверов и CDN это поддерживают.
• Оптимизируйте загрузку ресурсов: размещайте CSS в <head> для быстрого рендера, а скрипты — перед </body> или с атрибутами async/defer, чтобы не блокировать разбор HTML.
• Минимизируйте iframe: они загружают дополнительные страницы, замедляя сайт. Используйте loading="lazy" для iframe ниже линии сгиба или загружайте их по клику.

Совет: держите DOM компактным. Например, Astro разбивает страницы на «островки», минимизируя гидратацию JavaScript, что ускоряет рендеринг.

CSS

CSS может блокировать рендеринг, если не оптимизирован. Вот как сделать стили быстрее:

• Удаляйте неиспользуемый CSS: используйте PurgeCSS или Chrome DevTools, чтобы убрать мертвый код, особенно в проектах с Tailwind.
• Модуляризуйте стили: разделяйте CSS по страницам или функциям, загружая только необходимое. Критические стили встраивайте в <head>, остальное загружайте асинхронно.
• Избегайте @import: он создает дополнительные запросы и блокирует рендеринг. Используйте <link rel="stylesheet"> или объединяйте CSS при сборке.
• Используйте критический CSS: встраивайте стили для верхней части страницы в HTML, а остальное загружайте позже (например, через media="print"). Инструменты вроде Critical помогут это автоматизировать.
• Минимизируйте CSS: убирайте пробелы и комментарии с помощью Clean-CSS или cssnano.
• Предварительно загружайте ключевые стили: используйте <link rel="preload" as="style"> для важных CSS-файлов.
• Упрощайте селекторы: избегайте сложных вложенных цепочек, чтобы ускорить вычисления стилей. Например, .headline лучше, чем body div#main article h1.
• Применяйте современный CSS: используйте content-visibility: auto для отложенного рендера контента за пределами экрана. Это ускоряет начальную загрузку и снижает потребление памяти.

JavaScript

JavaScript часто замедляет страницы из-за объема и времени выполнения. Оптимизируйте его так:

• Заменяйте JS на HTML/CSS: используйте CSS-анимации, <details> или валидацию форм вместо JS, где возможно.

• Минимизируйте фреймворки: избегайте тяжелых библиотек для простых задач. Проверяйте сторонние скрипты (аналитика, реклама) и удаляйте ненужные.
• Разделяйте код: используйте динамический import() или возможности фреймворков для загрузки JS по необходимости.
• Предварительно загружайте важные скрипты: используйте <link rel="preload" as="script"> для ключевых JS-файлов.
• Применяйте async/defer: добавляйте эти атрибуты к <script>, чтобы не блокировать рендеринг. Defer сохраняет порядок выполнения, async подходит для независимых скриптов.
• Минимизируйте JS: используйте UglifyJS или tree shaking для удаления неиспользуемого кода. Настраивайте сборку для ES-модулей.
• Обновляйте зависимости: новые версии фреймворков (esbuild, SWC) часто быстрее. Используйте Renovate или Dependabot для автоматизации.
• Выбирайте подходящий фреймворк: Next.js с React Server Components или Astro с «островковой» архитектурой сокращают объем JS на клиенте, ускоряя загрузку.

Изображения

Изображения — один из главных факторов загрузки страниц. Оптимизируйте их так:

• Используйте правильный размер: не загружайте изображения больше, чем нужно для отображения. Инструменты вроде ImageMagick или Sharp помогут автоматизировать ресайз.
• Применяйте адаптивные изображения: используйте <img srcset> или <picture> для доставки изображений в зависимости от устройства.
• Сжимайте изображения: используйте ImageOptim, mozJPEG для JPEG, PNGQuant для PNG или SVGO для SVG.
• Предварительно загружайте ключевые изображения: используйте <link rel="preload" as="image"> или fetchpriority="high" для баннеров, влияющих на LCP.
• Откладывайте загрузку: добавляйте loading="lazy" для изображений ниже линии сгиба.
• Используйте WebP/AVIF: эти форматы обеспечивают лучшее сжатие, чем JPEG/PNG. CDN и фреймворки вроде Next.js автоматизируют конвертацию.
• Указывайте размеры: добавляйте width и height или CSS aspect-ratio, чтобы избежать сдвигов макета (CLS).
• Автоматизируйте оптимизацию: используйте Next.js <Image>, Astro или CDN (Cloudinary, Imgix) для автоматической обработки изображений.

Видео

Видео могут быть тяжелее изображений, поэтому требуют особого внимания:

• Сжимайте видео: используйте Handbrake для MP4/WebM, снижая битрейт или разрешение (например, 720p вместо 1080p).
• Используйте современные кодеки: WebM (VP9) или AV1 обеспечивают лучшее сжатие, чем MP4 (H.264).
• Настройте предварительную загрузку: используйте preload="metadata" или none для видео, чтобы не загружать лишние данные.
• Откладывайте загрузку: применяйте loading="lazy" для iframe или загружайте видео по клику/прокрутке.
• Удаляйте ненужное аудио: уберите звуковую дорожку из фоновых видео с помощью FFmpeg.
• Используйте потоковую передачу: для длинных видео применяйте HLS или DASH для адаптивной загрузки.
• Оптимизируйте сторонние видео: используйте облегченные встраивания (например, lite-youtube-embed) для YouTube/Vimeo.

Шрифты

Пользовательские шрифты улучшают брендинг, но могут замедлить рендеринг. Оптимизируйте их так:

• Ограничьте количество шрифтов: используйте минимум семейств и начертаний, чтобы сократить запросы.
• Применяйте WOFF2: этот формат компактнее TTF или WOFF и поддерживается всеми браузерами.
• Предварительно подключайтесь к источникам: используйте <link rel="preconnect"> для Google Fonts или других хостов.
• Используйте font-display: swap: это предотвращает FOIT (невидимый текст) и улучшает пользовательский опыт.
• Избегайте сдвигов макета: подбирайте резервные шрифты с похожими метриками или используйте font-size-adjust.
• Рассмотрите переменные шрифты: один файл заменяет несколько начертаний, снижая объем данных.
• Используйте системные шрифты: они не требуют загрузки и работают мгновенно.

Хостинг и сервер

Конфигурация сервера напрямую влияет на скорость загрузки:

• Используйте HTTPS: это не только безопасно, но и быстрее, благодаря HTTP/2+. Google учитывает HTTPS для SEO.
• Сократите HTTP-запросы: удаляйте ненужные ресурсы и минимизируйте сторонние скрипты.
• Перейдите на HTTP/2 или HTTP/3: HTTP/2 поддерживает мультиплексирование, HTTP/3 (QUIC) ускоряет соединение, особенно на мобильных сетях.
• Используйте CDN: кэшируйте ресурсы на серверах по всему миру для снижения задержек.
• Настройте кэширование: используйте Cache-Control для статических ресурсов и кэширование на уровне приложения.
• Оптимизируйте сервер: держите TTFB ниже 200 мс, оптимизируя запросы к базе данных и вычисления.
• Применяйте статическую генерацию: используйте SSG или ISR (Next.js) для доставки готовых HTML-страниц через CDN.

Быстрые улучшения

Эти небольшие оптимизации дают заметный эффект:

• Избегайте сдвигов макета: резервируйте место для изображений, iframe и динамического контента, чтобы минимизировать CLS.
• Используйте приоритеты: применяйте fetchpriority="high" для ключевых ресурсов и low для некритических.
• Сократите сторонние запросы: откладывайте загрузку аналитики или рекламы до взаимодействия пользователя.
• Используйте один протокол: избегайте смешанного контента (HTTP/HTTPS).
• Настройте кэширование: используйте длительный max-age для статических ресурсов с хэшами в именах файлов.
• Предварительно загружайте страницы: используйте <link rel="prefetch"> для вероятных переходов.
• Применяйте Service Workers: кэшируйте ресурсы для мгновенной загрузки и оффлайн-доступа.

Оптимизация фронтенда — это непрерывный процесс, который требует внимания всей команды. Скорость сайта напрямую влияет на пользовательский опыт, SEO и бизнес-показатели. Используйте этот чек-лист, чтобы выявить слабые места и сократить миллисекунды загрузки. Комбинируйте лабораторные тесты и мониторинг реальных пользователей, чтобы отслеживать прогресс. Сделайте скорость приоритетом — ваши пользователи и бизнес скажут спасибо!

1. TabNine

Если вам важна скорость — TabNine стоит попробовать хотя бы ради этого. Расширение — лёгкий AI-ассистент, который работает как умный автодополнитель кода, непохожий на аналоги вроде Codeium или Copilot.

TabNine обучен на миллионах строк открытого кода и умеет предсказывать, что вы напишете дальше, с учётом контекста проекта и языка. Отлично справляется с рутинными вещами: автозавершает функции, переменные, конструкции — всё быстро и чаще всего в тему.

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

Плюсы:

• Работает из коробки, не требует тонкой настройки;
• Есть локальная версия — удобно для закрытых проектов;
• Поддерживает большинство языков и фреймворков.

Чем полезен: экономит время на повседневной разработке — особенно когда вы не хотите отвлекаться на документацию или поиск нужной переменной в другом файле.

2. GitLens

GitLens встраивает историю изменений прямо в VSCode — и делает это максимально удобно. Показывает, кто и когда изменил строку, коммит-месседж, хэш, ветку и другие детали. Можно не уходить в консоль или отдельный Git-клиент для поиска информации.

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

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

Плюсы:

• Информация о коммитах отображается прямо в редакторе под строкой;
• Есть таймлайн изменений файла;
• Удобный diff по коммитам, авторам, веткам и даже фрагментам кода.

Чем полезен: помогает быстрее разбираться в чужом коде, искать причины бага или откатывать ошибки. Особенно ценится за то, что делает Git прозрачным и доступным прямо в процессе разработки.

3. Error Lens

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

Можно настроить отображение: выделять ошибки цветом, добавлять иконки или даже показывать краткие подсказки с предложениями по исправлению. Поддерживает большинство языков и линтеров, включая ESLint, TypeScript и других.

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

Плюсы:

• Ошибки и предупреждения отображаются прямо в редакторе, рядом со строкой кода;
• Гибкая настройка стилей и уровня детализации сообщений;
• Ускоряет процесс отладки, особенно при работе с большими файлами.

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

4. Path Intellisense

Path Intellisense — одно из тех расширений, которое просто работает и экономит кучу времени. Оно автоматически подсказывает пути к файлам, папкам и модулям в вашем проекте, как только вы начинаете их набирать. Поддерживает абсолютные и относительные пути, учитывает структуру проекта и форматирует предложения так, как это принято в выбранном языке.

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

Кому подойдёт: всем, кто устал вручную прописывать длинные relative-пути или путаться в структуре проекта. Особенно выручает на фронтенде, где модулей десятки и легко ошибиться в названии.

Плюсы:

• Подсказки появляются автоматически при наборе пути;
• Поддерживает большинство языков и фреймворков;
• Учитывает jsconfig.json и tsconfig.json при работе с alias-ами.

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

5. TODO Highlight

TODO Highlight подсвечивает комментарии с задачами (например, TODO, FIXME, NOTE) прямо в коде, делая их заметными и удобными для отслеживания. Расширение помогает не терять важные заметки, которые вы оставляете в коде, и быстро находить места, требующие доработки.

Можно настроить ключевые слова, цвета подсветки и даже добавить свои собственные метки. Работает с любыми языками программирования и интегрируется с панелью задач VSCode для удобного обзора всех TODO в проекте.

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

Плюсы:

• Яркая подсветка TODO-комментариев прямо в редакторе;
• Гибкая настройка ключевых слов и стилей;
• Интеграция с панелью задач для быстрого обзора.

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

6. Prettier – Code formatter

Prettier — расширение, которое автоматически приводит ваш код к единому стилю, избавляет от ручной правки отступов, кавычек и переносов. Оно поддерживает множество языков (JavaScript, TypeScript, CSS, HTML и другие) и интегрируется с линтерами, чтобы ваш код был не только красивым, но и консистентным.

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

Кому подойдёт: разработчикам, которые хотят экономить время на форматировании, и командам, стремящимся к единообразию кода.

Плюсы:

• Автоматическое форматирование при сохранении или по хоткеям;
• Поддержка множества языков и кастомных настроек;
• Интеграция с ESLint и другими инструментами для проверки кода.

Чем полезен: убирает рутину ручного форматирования, снижает количество ошибок в стиле кода и помогает сосредоточиться на логике, а не на внешнем виде. Идеально, чтобы ускорить работу и поддерживать чистоту в больших проектах.

7. Live Server

Live Server запускает локальный сервер прямо из VSCode, позволяя просматривать изменения в HTML, CSS и JavaScript в браузере в реальном времени. После сохранения файла страница автоматически обновляется, что исключает необходимость ручного перезапуска или обновления браузера.

Поддерживает кастомные порты, HTTPS, и работает с любыми фронтенд-проектами, от простых HTML-страниц до сложных приложений на React или Vue. Можно настроить, чтобы сервер открывался автоматически при запуске проекта.

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

Плюсы:

• Автоматическое обновление страницы при изменении кода;
• Простая настройка и поддержка HTTPS для безопасного тестирования;
• Лёгкий запуск сервера прямо из редактора.

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

8. Project Manager

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

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

Кому подойдёт: разработчикам, которые ведут сразу несколько проектов, часто переключаются между ними и устали искать нужный путь через File > Open Folder.

Плюсы:

• Быстрое переключение между проектами через интерфейс или хоткеи;
• Поддержка избранного и тэгов;
• Можно автоматически подтягивать все папки из заданной директории.

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

9. Code Spell Checker

Code Spell Checker выявляет орфографические ошибки в комментариях, строках и именах переменных прямо в редакторе VSCode. Расширение подчёркивает опечатки волнистой линией и предлагает варианты исправления через Ctrl+. или Cmd+., что позволяет быстро исправить ошибки.

Поддерживает множество ЯП и словари для разных языков (английский, русский, немецкий — с дополнительными расширениями). Можно добавлять свои слова в пользовательский словарь или игнорировать определённые термины, чтобы адаптировать проверку под проект. Работает с camelCase и snake_case, не помечая их как ошибки.

Кому подойдёт: разработчикам, которые пишут много комментариев или документации в коде, и тем, кто хочет избежать опечаток в строках, API или логах, чтобы повысить читаемость.

Плюсы:

• Мгновенное обнаружение ошибок с подсказками для исправления;
• Гибкая настройка словарей и игнорируемых слов;
• Поддержка технических терминов и различных стилей написания кода.

Чем полезен: экономит время на поиск и исправление опечаток, особенно в документации или пользовательских сообщениях, которые могут повлиять на восприятие проекта.

10. REST Client

REST Client позволяет отправлять HTTP-запросы и просматривать ответы непосредственно в VSCode. Достаточно создать файл с расширением .http или .rest, написать запрос в простом текстовом формате, и вы увидите кнопку Send Request для моментального выполнения.

Поддерживает все типы запросов (GET, POST, PUT, DELETE и другие), авторизацию (Basic, OAuth, JWT), переменные окружения и даже генерацию кода на разных языках. Запросы можно сохранять в репозиторий, что удобно для командной работы. Расширение также позволяет использовать динамические переменные по типу {{$timestamp}} или {{$guid}}, всё для гибкой настройки запросов.

Кому подойдёт: тем, кто работает с REST API и хочет тестировать эндпоинты прямо в VSCode, сохранять запросы в проекте и почти не переключаться между инструментами.

Плюсы:

• Простая отправка запросов через .http или .rest файлы с кнопкой Send Request;
• Поддержка переменных окружения и авторизации для сложных API;
• Возможность сохранять запросы в репозитории для совместной работы.

Чем полезен: ускоряет тестирование API, устраняет необходимость в сторонних приложениях. Запросы хранятся рядом с кодом, что упрощает документирование и повторное использование, особенно в проектах, где API-вызовы нужно часто проверять или делиться ими с командой.

А какими расширениями пользуетесь вы? Пишите в комментариях!

Главные отличия Web3 от Web2

Перед тем как углубиться в код и практику, полезно увидеть основные различия между привычной Web2-разработкой и новой логикой Web3.

Представим себе простой сервис для задач. В классическом Web2 его работа привычна: сервер обрабатывает запросы, база данных хранит задачи, а пользователь авторизуется через почту и пароль. Всё централизовано и зависит от владельца сервера.

В Web3 логика сильно меняется. Пользователь входит в систему с помощью криптокошелька, например, MetaMask. Каждая задача создаётся транзакцией и записывается в смарт‑контракт, а значит становится частью блокчейна. Удалить её уже нельзя — только отметить статус выполнения. Такой подход даёт прозрачность: любой участник сети может проверить, что задача действительно существует, и её статус изменён честно.

Стек Web3: что понадобится на практике

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

• Блокчейн: Ethereum, Layer‑2 (Arbitrum, Optimism, Base, Polygon), Solana.
• Языки: Solidity (EVM), Rust (Solana), Go (инфраструктура и сервисы).
• Библиотеки: ethers.js, wagmi.
• Фреймворки: Hardhat, Foundry, Truffle.
• Хранилища: IPFS/Arweave для файлов и метаданных.
• Кошельки/подключение: MetaMask, WalletConnect (v2/WalletConnect Network), Web3Auth.

Точка входа для новичка — Alchemy, а также ethers.js.

Пример. Быстрое подключение кошелька (ethers.js).

Архитектура DApp: из чего состоит современное Web3‑приложение

Любое Web3‑приложение строится из нескольких слоёв, каждый со своей ролью. Фронтенд остаётся привычным SPA, но работает не с сервером, а напрямую с кошельком и смарт-контрактами. Контракты содержат бизнес‑логику и хранят ссылки на данные в децентрализованных хранилищах. Оракулы обеспечивают связь с внешним миром, например, передают цены или сообщения между разными блокчейнами. Важную часть играет off‑chain слой — сервисы вне блокчейна (индексаторы, аналитика), которые помогают быстрее искать и обрабатывать данные, при этом не перегружать сеть.

Пример. Возьмём DeFi‑приложение. Пользователь открывает фронтенд и инициирует операцию swap(). В ответ фронтенд обращается к смарт‑контракту, который выполняет обмен токенов. Чтобы определить курс, контракт тянет актуальные данные через оракул. При этом тяжёлые артефакты, изображения или отчёты не хранятся в блокчейне напрямую — они лежат в IPFS. Сам контракт содержит только контент‑идентификаторы CID. Таким образом, получаем баланс: блокчейн отвечает за логику и безопасность, а децентрализованное хранилище — за данные.

Практика: ваш первый DApp за вечер

Давайте попробуем собрать простейшее приложение своими руками.

Шаг 0. Подготовка

Сначала убедитесь, что у вас стоит Node.js LTS и Git. Также нужен браузер с установленным MetaMask, где можно создать тестовый аккаунт. Чтобы оплачивать транзакции в тестовой сети, заранее возьмите немного тестовых монет через faucet — например, для Sepolia или Polygon Amoy.

Шаг 1. Проект

Создадим новый проект и установим Hardhat вместе с тулзами. Эта среда нужна для компиляции и деплоя контрактов.

Шаг 2. Контракт

В папке contracts/ создаём файл TaskTracker.sol и копируем туда код смарт-контракта из первого раздела. Это и будет бизнес-логика нашего приложения.

Шаг 3. Сценарий деплоя

Пишем скрипт, который разворачивает контракт в сети. Это простой скрипт на JavaScript, который вызывает методы Hardhat.

Шаг 4. Конфиг сети

В файле hardhat.config.js добавляем настройки для подключения к тестовой сети. Используем RPC-URL от Alchemy или Infura и приватный ключ от тестового аккаунта — его можно экспортировать из MetaMask, но использовать только для тестовой сети.

Шаг 5. Деплой в тестнет

Теперь запускаем скрипт деплоя. После выполнения увидите адрес контракта — он понадобится для фронтенда.

Шаг 6. Фронтенд (React + ethers.js + wagmi)

Собираем простое SPA: форма, чтобы добавить задачи, и кнопка «complete». Здесь мы используем ethers.js для обращения к контракту. Сделайте вызовы addTask и completeTask.

Подводные камни Web3-разработки и что с ними делать

Комиссии (gas): любая запись в блокчейн стоит денег и иногда комиссия выше ценности операции — например, $10 за простую задачу.

• Что делать: использовать Layer-2 (Arbitrum/Optimism/Base/Polygon), выбирать сети с низкими комиссиями (Solana, Avalanche), оптимизировать контракты и батчи транзакций.

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

• Что делать: показывать «оптимистичный UI», кешировать данные, переносить часть логики off-chain, использовать быстрые сети (Solana, Near, Aptos).

Безопасность: код контракта неизменяем, и одна ошибка может стоить миллионов.

• Что делать: проходить аудит (CertiK, Trail of Bits), использовать проверенные библиотеки (OpenZeppelin), писать тесты в тестовых сетях (Goerli, Sepolia), внедрять баг-баунти и ролевую модель доступа.
• Ресурс: ConsenSys Diligence — Smart Contract Security Best Practices.

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

• Что делать: использовать аккаунт-абстракцию (ERC-4337), социальный логин, gasless транзакции через Paymaster, улучшать UI (подсказки, авто-фокус на MetaMask).

Регуляция: законы о Web3 пока разные в каждой стране. Легальное в одной юрисдикции может быть запрещено в другой (например, токенизация акций без лицензии).

• Что делать: консультироваться с юристами, следить за изменениями. Например, MiCA в ЕС — “Markets in Crypto-Assets Regulation” — это единый регламент по криптоактивам в Евросоюзе.

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

Карьерные возможности и перспективы

Web3‑разработчиков уже активно ищут: зарплаты в среднем предлагают выше, чем у Web2‑коллег. Кроме программистов, востребованы смежные роли: аудиторы смарт‑контрактов, специалисты по безопасности, а также продакт‑менеджеры и аналитики, которые понимают специфику блокчейна.

Чтобы войти в профессию, начните с изучения Solidity и базовых паттернов смарт‑контрактов. Сделайте пару пет‑проектов и выложите код в GitHub. Отличный вариант прокачки — участвовать в хакатонах и грантовых программах от Ethereum Foundation или Solana Grants. Это даёт и опыт, и контакты, и иногда финансирование.

Пара пет‑проектов + понимание блокчейна — хороший старт в Web3‑команду.

Будущее Web3

Web3 не вытеснит Web2 полностью, но поменяет привычный подход к разработке. Разработчику это открывает новые вызовы: комиссии, безопасность и UX, но одновременно и новые возможности — прозрачные данные, токенизация, децентрализованные бизнес‑модели.

Для тех, кто только входит в сферу, это шанс попасть в индустрию на раннем этапе и быстро нарастить экспертизу. Простые пет‑проекты, хакатоны и знакомство с инструментами дают ощутимый старт.

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

Если вы фронтенд-разработчик или только планируете им стать, эта публикация поможет вам сориентироваться в текущей ситуации:

• Узнаете, какие крупные изменения произошли в React, Vue и Angular за последние 5-10 лет.
• Поймёте, стоит ли учить новые фреймворки без виртуального DOM или лучше углубиться в проверенные решения.
• Разберётесь, почему компании продолжают требовать знание React, хотя Solid.js работает быстрее.

Тимлид и разработчики рассказали, как они видят будущее профессии. Объяснили, почему джуну недостаточно знать только JS, какие навыки помогут вам зарабатывать больше и оставаться востребованным специалистом.

ℹ️ После прочтения вы сможете принять взвешенное решение: продолжать углубляться в текущий стек, осваивать новые инструменты или развивать смежные навыки.

Как изменились React, Vue и Angular за последние 5-10 лет?

React

До 2019 года разработчики писали объёмные классы с методами жизненного цикла. Они управляли состоянием через setState и передавали данные через пропсы. Потом появились хуки — с тех пор логику помещают в функции, состоянием управляют через useState и useReducer, побочные эффекты контролируют через useEffect.

Серверные компоненты решили проблему первой загрузки. Тяжёлые части приложения обрабатывает сервер и отправляет клиенту уже готовыми. Конкурентный режим разбивает отрисовку на части и расставляет приоритеты для обновлений — интерфейс не виснет, когда нагрузка возрастает.

Vue

Composition API сделал организацию кода более гибкой. Логику теперь группируют по функциональности, а не по типам опций. Ещё реактивность переписали с нуля на прокси-объектах, что ускорило отслеживание изменений.

Компилятор научился оптимизировать шаблоны на этапе сборки. Телепорты решили проблему с модальными окнами и всплывающими подсказками — компоненты отрисовываются в нужном месте DOM-дерева независимо от родителя.

В какую сторону развивается Vue и есть ли ему современные альтернативы

Angular

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

Строгая типизация и декораторы сделали код более предсказуемым. Встроенные инструменты покрывают все потребности крупных проектов: формы с валидацией, маршрутизация с ленивой загрузкой, HTTP-клиент с перехватчиками.

Фреймворки уходят от сложных решений к более простым. Тренд последних лет — делать приложения быстрее для пользователей и удобнее для разработчиков.

Пока большая троица занималась «работой над ошибками», появился запрос на что-то более лёгкое и быстрое.

Фронтенд-фреймворки кажутся избыточными — возвращаемся к ванильному JS?

Тот, кто попробовал фреймворки, никогда не вернется к чистому ванильному JS 🙂 Меняются и развиваются сами фреймворки, но тренда на отказ от них точно нет.

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

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

Фреймворки — это ещё и способ стандартизации разработки в командах.

Фреймворки никогда не будут избыточными. Один из первых вопросов на собеседовании — инструмент, с которым ты умеешь работать. Больший пласт знаний сегодня — это фреймворк. Остальное, чаще всего, бизнес-логика того или иного проекта.

Из-за критики традиционных фреймворков появился новый класс решений. Больше всего ругают VDOM и гидратацию, хотя они считались неотъемлемой частью современных SPA.

Стоит ли переходить на фреймворки без VDOM и гидратации?

Solid.js и Svelte уже несколько лет развивают концепцию тонкой реактивности. В 2021 году появился Qwik, который вообще отказался от гидратации.

SolidJS хорош для аналогов десктопных приложений в браузере — Figma, Miro. Здесь приложение загружается один раз, а потом работает долго и должно быть максимально отзывчивым. Qwik отлично подойдёт, если вы создаёте сайт, куда пользователь приходит за контентом, и важно показать ему этот контент мгновенно.

При этом массового перехода на новые фреймворки пока не происходит. Компании продолжают искать React и Vue разработчиков — проекты на Solid.js и Qwik остаются экспериментальными.

Сами по себе фреймворки мало значат для коммерческой разработки без сторонних библиотек вокруг них. Вот когда критическая масса разработчиков популярных библиотек мигрирует на Qwik, а вместе с ними и сообщество, что-то сдвигается.

Проблема новых фреймворков — это отсутствие экосистемы. React и Vue окружены тысячами готовых библиотек для любых задач. На Solid.js и Qwik большинство решений придётся писать самостоятельно.

Без поддержки сообщества пользователей ни один инструмент не сможет стать массовым. Даже если работаешь в заказной разработке и есть возможность расширить кругозор команды, сомнительно брать на тест инструмент, под который придётся писать до 30% базового функционала.

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

У новых фреймворков высокий порог входа: вас ждёт переобучение команды и сложности ручной оптимизации.

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

Во времена DDR/DDR2 было сложно выполнять клиентский рендеринг, а вот серверам ресурсов хватало. Разработчики как могли воплощали подход, который сейчас называется SSR, и возвращали на клиент готовую разметку для компонентов. И никакого тебе VDOM.

Пока новые фреймворки остаются нишевыми инструментами. React, Vue, Angular продолжат доминировать в коммерческой разработке за счёт экосистемы и сообщества.

Как изменится роль фронтенд-разработчика в 2026 году?

В 2020 году джуниор находил работу, если знал HTML, CSS и основы JS. Сегодня работодатели требуют от новичков React или Vue, TypeScript, системы сборки — и это не конец списка. Ещё и вакансий на всех начинающих не хватает, компании сразу ищут мидлов.

Инструменты с искусственным интеллектом — Copilot, ChatGPT, Cursor — ускоряют работу. Они же повышают планку: если джун с помощью ИИ работает как мидл, то мидл должен демонстрировать более глубокие знания. Работодатели стали больше ценить тех, кто понимает принципы работы кода, а не просто копирует готовые решения.

Зная JavaScript и любой инструмент даже не из большой тройки, с использованием AI можно быстро погрузиться в другой нужный инструмент.

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

Какие навыки развивать разработчику, чтобы оставаться востребованным?

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

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

По мне так лучше быть фреймворк-агностиком, нежели фанатом одного, которого легко чем-то обидеть.

Архитектурное мышление отличает «сильного» разработчика:

• Как организовать код, чтобы его легко поддерживать?
• Как спроектировать API, чтобы оно не ломалось при изменениях?
• Как построить систему, которая выдержит рост нагрузки?

Те, кто решают эти вопросы, получают офферы с космическими зарплатами.

Софт-скиллы тоже влияют на карьерный рост:

• Объясните техническую проблему менеджеру простыми словами.
• Проводите код-ревью так, чтобы не обидеть коллегу, но улучшить код.
• Оценивайте сроки и управляйте ожиданиями.
• Аргументируйте выбор технологии.

Когда вы понимаете бизнес, вы становитесь партнёром. Почему мы делаем эту фичу? Как она повлияет на метрики? Какие есть альтернативы? Разработчик, который мыслит категориями бизнеса, становится незаменимым.

Рынок вынуждает постоянно учиться, потому что индустрия меняется каждый год. Кто застревает в зоне комфорта — отстаёт.

Как ChatGPT повлиял на ценность вашего труда? Успеваете подстраиваться под требования рынка, параллельно работать и пробовать новые технологии? Делитесь в комментариях.

«Выбор React — это рефлекс»

Автор утверждает, что команды слишком часто выбирают React не потому, что он подходит под задачи, а потому, что «все его знают».

Это, по его словам, убивает конкуренцию и мешает развитию альтернатив — таких как Svelte, Solid или Qwik. Эти фреймворки предлагают новые архитектурные модели, быстрее работают в ряде сценариев, но редко получают шанс, потому что выбор уже сделан заранее.

Технологии 2013 года в 2025-м

React до сих пор использует концепции, созданные более 10 лет назад: виртуальный DOM, эффект-хуки, ререндеринг через reconcile.

Хотя команда React продолжает развивать фреймворк (например, через Server Components и React Compiler), сам подход остается сложным и неэффективным — особенно в сравнении с конкурентами, которые перераспределяют нагрузку на этапе сборки и избегают избыточных вычислений в браузере.

Проблема — не в React, а в «React-по-умолчанию»

По мнению автора, React сам по себе не плох. Проблема — в «монокультуре», которая блокирует инновации.

Меньше внимания уделяется веб-стандартам, большинство вакансий требует именно React, а университеты ориентируются на рынок, а не на фундаментальные знания.

Что делать

Разработчик призывает руководителей и команды делать выбор не по инерции, а осознанно: оценивать реальные требования проекта, пробовать альтернативы, не бояться использовать Svelte, Solid или Qwik хотя бы в отдельных модулях.

В противном случае, предупреждает он, вся фронтенд-экосистема будет развиваться медленнее — а значит, в убытке окажутся все.

Последний рубеж React и Vue

Согласны, что VDOM превратился в бюрократическую прослойку? Изменили состояние в одном месте — получите полный пересчёт дерева компонентов. Фреймворки заставляют загружать всё сразу, тащат багаж служебного кода. И пока этот код не загрузится, пользователь смотрит на белый экран.

SSR ускоряет загрузку страницы: сервер рендерит HTML, пользователь видит контент и пытается с ним взаимодействовать. Но пока JavaScript не загрузится, ничего не заработает.

Потом JS наконец подгружается и начинает гидратацию. По сути, он заново создаёт в памяти то же дерево компонентов, которое сервер уже отрендерил в HTML. Выполняется двойная работа. Кстати, в это время пользователь тыкает неработающие кнопки — дотерпит ли он до полной загрузки?

Системные проблемы не исправить очередным хуком или новой версией фреймворка, поэтому появление SolidJS и Qwik — было вопросом времени.

Поиск новых решений — здоровый признак развития фронтенда. В конце концов, и Vue был создан потому, что Эвану Ю не хватало облегченной альтернативы AngularJS. Большая тройка фреймворков решает огромный спектр задач, имеет колоссальную поддержку сообщества, но их нельзя назвать идеальным инструментом на все случаи жизни.

Обзор SolidJS

SolidJS во многом похож на React. Самое интересное — его подход к обновлению интерфейса:

• Отсутствие виртуального DOM — Solid напрямую обновляет только те DOM-узлы, которые действительно изменились.
• Компоненты как функции инициализации — каждый компонент вызывается только один раз для настройки реактивности.
• Сигналы вместо хуков — состояние управляется через createSignal(), который возвращает геттер/сеттер пару.

Например, когда срабатывает счётчик, Solid не перерисовывает весь компонент. Он точечно обновляет только текст внутри <p>, где используется count():

Преимущества SolidJS

👍 Производительность и размер бандла

Благодаря отсутствию виртуального DOM и мелкозернистым обновлениям, приложения работают быстрее аналогов на React.

👍 Простота освоения

Синтаксис SolidJS похож на React. Функциональные компоненты, JSX, концепции вроде Suspense и Error Boundaries — всё это есть в Solid. Изучение основ займёт 1-2 дня, если есть опыт с MobX/effector/RxJS.

👍 Стабильность

Фреймворк находится на стабильной версии 1.x. Это означает отсутствие кардинальных изменений API, в отличие, например, от ситуации со Svelte, где сосуществуют версии 4 и 5 с разными подходами.

👍 Совместимость с React

SolidJS совместим с экосистемой React. Можно переиспользовать дизайн-системы и компоненты в legacy-приложениях.

👍 Удобное управление состоянием

Функционал сигналов и сторов покрывают 90% потребностей в управлении состоянием без необходимости подключать внешние библиотеки.

Минусы SolidJS

👎 Ограниченная экосистема

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

👎 Кривая обучения

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

• Избегать условных конструкций непосредственно в компонентах.
• Не деструктурировать пропсы и сторы, чтобы сохранить реактивность.
• Не использовать асинхронный код внутри createEffect.

👎 Проблемы с инструментарием

Возникают сложности с настройкой компилятора в нестандартных окружениях — монорепозиториях, при запуске тестов или интеграции с другими инструментами. DevTools не дотягивает до аналога у React.

👎 SolidStart всё ещё развивается

SSR-решение SolidStart пока не достигло зрелости Next.js или Nuxt. Разработчики сообщают о проблемах с гидратацией и других сложностях при работе с серверным рендерингом.

Обзор Qwik

Qwik — это проект Мишко Хевери (создателя Angular). Идея фреймворка заключается в возможности возобновить работу приложения на клиенте без повторного выполнения кода, который уже был выполнен на сервере.

В Qwik радикально решили проблему гидратации — полностью отказались от неё. Время до интерактивности (TTI) падает в разы. Пользователь может кликать на кнопки сразу после загрузки HTML, без ожидания разогрева всего приложения.

Qwik автоматически разбивает код на мелкие чанки и загружает их только при необходимости. Символ $ в коде указывает на границы ленивой загрузки.

Плюсы Qwik

👍 Мгновенная загрузка

Практически нулевой JavaScript при первоначальной загрузке, следовательно отличные показатели Core Web Vitals.

👍 Автоматическая оптимизация

Оптимизация на уровне компилятора, умная предзагрузка критических ресурсов. Не нужно думать о разделении кода — Qwik делает это автоматически.

👍 Знакомый синтаксис

👍 Спасибо за SEO

Быстрая загрузка улучшает ранжирование за счёт полноценного SSR из коробки.

Минусы Qwik

👎 Молодая экосистема

Ограниченное количество библиотек, мало готовых решений и компонентов. Небольшое сообщество разработчиков (если сравнивать с React/Vue).

👎 Кривая обучения

Придётся изучать новые концепции. Из-за ленивой загрузки усложняется отладка.

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

👎 Сложность интеграции

Трудно интегрировать существующие React/Vue компоненты и ограниченная поддержка сторонних библиотек. Скорее всего, придётся с нуля переписывать код существующего проекта.

Экосистема и готовность к продакшену

Если сравнивать с React, то экосистема — самое слабое место обоих фреймворков.

SolidJS имеет SolidStart — метафреймворк с роутингом, SSR и серверными функциями. Документация качественная, сообщество активное. Большинство React-библиотек можно адаптировать без особых проблем, для популярных UI-китов есть готовые порты.

Qwik развивается в связке с Qwik City, который покрывает типовые задачи веб-разработки. Builder.io активно инвестирует в экосистему, регулярно выходят обновления и новые интеграции.

Риски есть, но они управляемые. Меньший размер сообщества означает меньше готовых решений и ответов на Stack Overflow. Если не боитесь изучать новое, то выигрыш в производительности перевесит неудобства.

Сравнение SolidJS и Qwik

SolidJS повышает производительность обновлений. Если данные меняются часто и непредсказуемо — графики, мониторинги, редакторы — Solid даст максимальную отзывчивость.

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

Медиа, блоги с жёсткими требованиями к TTFB/TTI/INP будут лучше работать на Qwik. Пользователи смогут читать и скроллить без задержки. Интерактив добавляется дозированно — это лучшая стартовая стоимость.

E-commerce, каталоги с SEO и карточками рекомендуется разрабатывать на Qwik. Особенно если на главной тяжёлые модули, а клиенты приходят с поисковиков. Вы выигрываете у конкурентов буквально на первом взаимодействии.

Сложный SPA или дашборд с живыми виджетами и апдейтами будет лучше работать на SolidJS. Точечная реактивность упростит жизнь и снизит цену апдейтов. Solid сияет в проектах, где происходят сотни мелких изменений в секунду.

Solid хорош для аналогов десктопных приложений в браузере — Figma, Miro. Здесь приложение загружается один раз, а потом работает долго и должно быть максимально отзывчивым. Также Solid будет хорош там, где важна плавность анимаций.

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

Оба фреймворка умеют SSR/SSG и стриминг. Solid снижает стоимость обновлений, Qwik — стоимость старта. Для LCP/TTI/INP в контентных сценариях выигрывает Qwik. Для интенсивных интерактивных сценариев Solid удерживает FPS и снижает CPU.

Оба дружат с серверными платформами. SolidStart имеет адаптеры для Vercel/Netlify, Qwik City — тоже.

Выбирайте Solid.js, если вы создаете сервис, куда пользователь заходит надолго, и ему важна отзывчивость после загрузки. Выбирайте Qwik, если вы создаете сайт, куда пользователь приходит за контентом, и важно показать ему этот контент мгновенно.

Немного выводов:

• Solidjs быстрее Qwik при рендеринге. Qwik быстрее Solidjs при загрузке страниц.
• У Solidjs документация лучше, чем у Qwik.
• С нуля код на Qwik писать проще и быстрее, чем на SolidJS.
• Typescript в SolidJS может быть головной болью, в Qwik об этом можно не беспокоиться.

Практические рекомендации по переходу на SolidJS и Qwik

1. Начните с аудита текущих проблем. Посмотрите метрики сайта: сколько времени занимает гидратация? Тормозят ли обновления интерфейса? Где именно проблема — на старте или в процессе работы?
2. Выберите изолированную часть проекта. Возьмите один виджет, одну страницу, один компонент и реализуйте его на новом фреймворке. Измерьте разницу в производительности и удобстве разработки.
3. Если проблема в медленной загрузке — попробуйте Qwik. Соберите прототип лендинга или каталога, включите SSG с resumability и протестируйте на медленном соединении.
4. Если проблема в тормозах интерфейса — попробуйте Solid. Перепишите самый страдальный компонент с частыми обновлениями, уберите мемоизации и посмотрите на результат.

Оба фреймворка собираются через Vite, имеют TypeScript из коробки и хорошую интеграцию с популярными инструментами. Стоимость эксперимента низкая, а потенциальная выгода высокая.

Тенденция отказа от React/Vue

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

А вы что думаете? Готовы попробовать модные фреймворки SolidJS и Qwik в следующем проекте?

Новички, когда сталкиваются с пет-проектами, бросаются в две крайности. Создают очередной To-Do list, который ничем не выделяется, либо пытаются сделать что-то слишком сложное, например, убийцу Notion, и забрасывают работу на полпути. Так как же выбрать идею, которую получится довести до конца?

Ключевые нюансы при выборе идеи пет-проекта

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

Ваш «питомец» должен решать какую-то проблему и выделяться фишкой, иначе он никого не впечатлит.

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

Как-то я пришёл на хакатон — занимался рекомендательными системами. Тогда был пик популярности Word2Vec — это модель, которая переводит слова в векторы и позволяет находить между ними смысловую близость. Я посмотрел на статистику и увидел: на одном из сайтов 25% запросов не давали результатов. Тут возникла идея, как это улучшить.

Решил собрать демку и сделал прототип: например, на запрос «кресло из крокодиловой кожи» модель показывала зелёные кожаные кресла. Не крокодиловые, но всё равно релевантные запросу.

За неделю допилил прототип до презентабельного состояния, показал коллегам и руководителю. Они дали «зелёный свет», через 2 месяца была первая MVP, которую уже начали продавать существующим клиентам. Ещё через месяц — первый клиент, интеграция, запуск.

Спустя ~5 лет количество клиентов уже измерялось сотнями :)

Подумайте, какие навыки хотите показать

Если делаете проект для портфолио, то можно выбрать несколько вакансий, на которые вы претендуете. Какие там требования к стеку, какие нужны навыки?

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

Не затягивайте со сроками

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

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

Основная ошибка — это незаконченные, «сырые» решения. HR смотрят на проекты, в том числе, как на способность завершать начатое. Если в портфолио много таких работ, это наводит на мысли, что разработчик быстро теряет интерес, плохо планирует время или бросает задачи при первых трудностях.

Не используйте учебные работы, либо используйте их правильно

Многие онлайн-школы обещают готовое портфолио по окончании обучения, но оно обычно состоит из учебных проектов. В целом, это неплохо, но есть пара нюансов:

1. У вас и ваших одногруппников эти работы одинаковые. Представьте лицо HR, когда он увидит несколько похожих проектов в разных резюме.
2. Учебные проекты не совсем ваши, ведь вы повторяли код и основные конструкции за преподавателями. Работодателю важно, как вы пишете сами, а не копируете.

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

Всё равно не могу ничего придумать, что делать?

Если самостоятельно не получается что-то придумать, то можно спросить у ИИ.

ChatGPT и другие языковые модели отлично умеют генерировать идеи на заданную тему. Часто в ответах появляются нестандартные, свежие задачи, которые вам бы и не пришли в голову. Даже если сгенерированные проекты кажутся банальными — всегда можно докрутить, добавить свою логику или фишку. Но используйте ИИ как вдохновителя, не просите его написать код проекта за вас — это будет заметно и станет не преимуществом, а «красным флагом».

Пример промпта для идеи пет-проекта:

Возьмите задачу с фриланса

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

Спросите друзей или аудиторию в соцсетях

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

У меня был разработчик, уставший от хаоса в списках фильмов, которые он хочет посмотреть. Сделал пет-проект — личный медиапланировщик с нейтральным UI. Проект не стал стартапом, но в портфолио смотрелся отлично. Если сложно — можно взять существующую идею и улучшить. Например, сделать привычный To do-лист с уклоном в UX, нейросети или интеграции. Главное — показать свою силу, а не сделать ещё один клон.

Как довести пет-проект до конца и не забросить его

Вы выбрали идею для проекта, прикинули стек, сроки, пошли писать код и… забросили. Часто бывает, что вначале полны энтузиазма, а под конец либо ничего не получается, либо появляются мысли, что проект — пустая трата времени. Чтобы такого не было, лучше соблюдать следующие правила:

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

Определите для себя MVP — минимальный рабочий продукт, который точно сможете довести до релиза. Всё, что не критично для запуска, сразу откладывайте, иначе перфекционизм и погоня за новыми фичами утащат вас на дно.

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

Разбейте проект на задачи и подзадачи. Например, дизайн плеера, его вкладок, основная логика, подключение API, отладка.

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

Определитесь со сроками. Пусть они будут примерными — главное, чтобы был ориентир. Например, дать себе месяц на MVP, неделю на запуск базовой версии, пару дней на исправление багов. Без сроков любая задача может растянуться, а когда есть конечная точка, появляется стимул не бросать начатое.

Один из основных критериев — полезность продукта. Нет смысла изобретать велосипед. То, что вы создаёте, должно быть либо лучшего того, что уже есть, либо вообще уникальным. И тут не важно, в какой сфере вы решите это всё произвести, главное, чтобы было чёткое понимание, зачем это делается и какой будет итог. Проще говоря, без плана не нужно начинать, иначе велик риск всё забросить. Большая часть тех, кто начал и не закончил, как раз не прорабатывали свои идеи.

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

Конечно, это правило не абсолютное, использовать новые для вас технологии можно, просто это надо делать дозировано.

Если очень грубо, то ориентир выглядит так: 80% кода — это знакомый нам стек, 20% — место для экспериментов и обучения. Такой подход позволяет прокачать новые навыки и довести проект до финала без выгорания.

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

Лучше постараться выработать привычку и заниматься петом, например, каждый день по 30 минут. Не можете соблюдать эту привычку по каким-то причинам? Не проблема, вместо 30 минут найдите 5. Да, за это время вы ничего не успеете, но сохраните «регулярность» — на следующий день будет проще.

Делитесь результатами. Не держите всё в столе, делитесь ходом работы и результатом. Покажите ваш MVP друзьям, обсудите его на форуме, заведите репозиторий на GitHub. Без обратной связи можно легко что-то упустить.

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

А вот ещё несколько советов от Анастасии Егоровой — фронтенд-разработчика, автора программы курса SkillBox по Vue 3 и ведущей ютуб-канала CosyFrontend.

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

У некоторых разработчиков количество таких заброшенных и недоделанных проектов — десятки штук. Что можно придумать для того, чтобы большинство ваших домашних проектов доводились бы до конца?

1. Фиксировать прогресс, например, на доске Trello, чтобы самому видеть продвижение по проекту. Не забывать коммитить в гит. Некоторым разработчикам помогает отписываться о состоянии проекта в личный блог.

2. Избегать перфекционизма — сначала сделать рабочую версию, а потом постепенно ее улучшать.

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

P.S. Когда мы обсуждали тему пет-проектов и их забрасывания в одном из айтишных чатов, один из разработчиков отметил: «А никак не нужно доводить их до конца — пет-проекты для того и существуют, чтобы попробовать на них новую идею и забросить». Так что такое мнение тоже есть, но справедливо ли оно для вас — решайте сами 😀

Как оформить пет-проект

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

Поработайте над UI/UX. Приятный и удобный интерфейс — ваш первый плюс в глазах работодателя. Потратьте время на то, чтобы кнопки, цвета и структура приложения были понятны с первого взгляда.

Чтобы убедиться, что пользователям удобно использовать сервис — запросите обратную связь у знакомых, коллег и родственников. Учтите их замечания.

Упакуйте проект в GitHub. Если у вас пустой репозиторий, который называется my project, то проект никто не оценит. У HR большой поток откликов, иногда они принимают решение за пару секунд, поэтому очень важно, чтобы по вашему репозиторию как можно быстрее можно было понять, что вы сделали, как это работает и какие технологии вы использовали.

Сделайте подробное описание readme — в паре абзацев расскажите, что это за проект, для кого, какие проблемы решает. Добавьте описание стека архитектуры. Чем подробнее, тем лучше.

Добавьте скриншоты, гифки, видео работы сервиса. А ещё лучше его демоверсию.

Постарайтесь проработать структуру проекта, чтобы она была логичной. В нём не должно быть дублей и мусора. Если кто-то впервые откроет ваш репозиторий, ему должно быть понятно, что это за проект.

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

Опишите результаты по конкретным метрикам, если, конечно, это возможно. Опубликовали приложение в Google play и получили хорошее удержание пользователей? Расскажите об этом. Вашу фичу оценили в социальных сетях? Поделитесь приятным фидбеком. Метрик нет, делали проект только под себя? Расскажите, как он помог вам решить проблему.

Лучше всего оформить проект на GitHub с описанием задач, технологий и особенностей реализации. Выделяются разработчики, которые показывают, что не просто пишут код, но и обосновывают решение и объясняют, как всё устроено.

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

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

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

Главное, не делайте проект ради проекта, старайтесь принести какую-то пользу и здраво оценивайте свои возможности.

Представьте: пятница, 18:30. Релиз через час. Вы меняете один роут в конфиге — и внезапно половина приложения отлетает. Поздравляем, вы только что познакомились с классической болью фронтендеров.

Проблема кроется в самой природе JavaScript. Строковые пути вроде /users/profile/${id} существуют в коде как обычные строки — без проверок, автокомплита и гарантий корректности. Опечатался в /usres вместо /users — и твоя навигация сломалась, а TypeScript молчит как рыба.

Двадцать лет назад мы кликали по window.location.href, десять лет назад — радовались React Router, а сегодня пора переходить на типизированные решения.

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

Суть проблемы

Проблема очевидна: путь /admin/products размазан по всему коду. TypeScript не знает, что эти строки связаны с определенной директорией, поэтому не проверяет их корректность. Опечатка в product вместо products — и вылетает ошибка 404.

В больших проектах эта проблема критична. Приложение с 200+ путями, где навигация разбросана по сотне компонентов, превращается в минное поле. Один программист меняет структуру URL, а остальные даже не подозревают об этом. Команды используют TypeScript для типобезопасности, но навигация остается уязвимой.

Что такое типизированная навигация?

Типизированная навигация превращает строковые пути в типизированные объекты. Вместо /admin/products/123/edit программист работает с функциями, которые знают структуру приложения и проверяют корректность написания путей на этапе компиляции.

Представьте GPS-навигатор, который знает все адреса в городе. Вы не можете ввести несуществующую улицу — система сразу выдаст ошибку. Так работает типизированная навигация: TypeScript проверяет, что путь существует, параметры переданы правильно, а структура URL соответствует пути.

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

Польза зависит от уровня разработчика:

• Джуны получают защиту от опечаток и автокомплит — меньше глупых ошибок и быструю разработку.
• Миддлы ускоряют разработку благодаря надежному рефакторингу — можно смело менять структуру URL без страха что-то сломать.
• Сеньоры используют типизацию для построения архитектуры приложения — создают переиспользуемые компоненты навигации, проверяют параметры и строят масштабируемые системы путей и директорий.

Типизированная навигация превращает хрупкий код в надежную систему, где ошибки находятся до деплоя.

Как использовать React Router вместе с TypeScript

Для базовой типизации в React Router v6 сначала определите структуру путей. Создайте интерфейс, который описывает все пути в приложении:

Типизация параметров URL решает проблему с useParams. Вместо any получаете конкретные типы:

Query-параметры типизируются аналогично через useSearchParams. Создайте интерфейс для каждой страницы с query-параметрами и оберните хук.

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

Как внедрить типизированную навигацию в проекты

Централизованная система маршрутов облегчает управление навигацией в больших приложениях. Создайте отдельный файл с конфигурацией всех путей:

Конфигурация избавит от нужды дублировать код при генерации типов. TypeScript автоматически выведет все возможные пути и их параметры из одного объекта.

Современные библиотеки решают проблему из коробки. Например, Tanstack Router предоставляет полностью типизированную систему путей с автогенерацией типов, а Type-route создает типобезопасные пути через API.

Библиотека typesafe-routes внедряется даже в крупные проекты без необходимости менять сотни строк кода.

Выбор инструмента зависит от размера программы. Если у вас небольшое приложение — быстрее написать хук в пару строк. Но если разрабатываете сложный сервис — используйте библиотеки.

Как не сломать код при использовании типизированной навигации

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

Чеклист для код-ревью поможет не уронить прод:

• Все новые navigate() и используют типизированные версии;
• Параметры путей явно типизированы;
• Нет магических строк в навигации;
• Query-параметры описаны интерфейсами.

Важно: не используйте одновременно строки и типизированные пути — выберите один подход для проекта и не допускайте высокого уровня вложенности в объектах.

Автоматизация упрощает процесс. ESLint правило no-hardcoded-routes запретит использование строк в навигации. Код-генераторы создают типы из OpenAPI схем или конфигурации роутера.

Производительность не страдает — типы исчезают после компиляции. Теряется немного времени на компиляцию TypeScript, но экономия на отладке перекрывает затраты.

Где применять типизированную навигацию

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

E-commerce проекты выигрывают от типизации каталогов и фильтров. Пути вроде /catalog/:category/:subcategory?filters=price,brand содержат много параметров, которые легко сломать при рефакторинге.

Интеграция с Redux и Zustand упрощает синхронизацию состояния с URL. Типизированные селекторы автоматически обновляются при изменении роутов:

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

Типизированная навигация — стандарт современной разработки. Команды, которые до сих пор полагаются на строковые пути, тратят лишнее время на поиск багов. Программисты увереннее рефакторят код, не боятся мелких ошибок и не роняют прод в пятницу вечером из-за одного символа в пути.

Всё это — обычная история для быстрорастущих IT-компаний. Пока команда маленькая, хватает одного тимлида. Но когда людей становится больше, старые процессы начинают сбоить.

Здесь и появляются новые роли — Technical Owner и Unit-лид. Их задача — взять на себя куски ответственности, которые раньше выпадали из поля зрения команды.

В российских компаниях эти роли пока не получили широкого распространения, особенно в небольших и средних организациях, где функции часто распределены между тимлидами, продакт-оунерами и проектными менеджерами. Однако в крупных IT-компаниях и продуктовых командах, таких как Avito и другие, Unit-лид и Technical Owner становятся всё более востребованными, поскольку помогают разграничить ответственность и повысить прозрачность управления сложными продуктами и командами.

Technical Owner: кто это и зачем нужен

Представим ситуацию: компания разрабатывает маркетплейс на Python и React, всё вроде идёт по плану, пока менеджеры не просят срочно добавить новую систему оплаты. Они не вникают, что для этого придётся переделать схему платежей, разнести микросервисы, рискуя уронить старые заказы. Разработчики объясняют, что быстро не выйдет, но их не слышат — и в итоге проект зависает между требованиями бизнеса и возможностями команды. Именно в таких случаях нужен Technical Owner.

Кто это такой

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

Какие у него обязанности

Вот примерный список того, что делает ТО:

• Консультирует заказчиков и владельцев по техническим вопросам.
• Составляет дорожную карту развития проекта, с учётом требований к разработке.
• Помогает с разработкой решений, начиная с архитектуры.
• Участвует в расстановке приоритетов.
• Поддерживает команды и отслеживает их зависимости.

Это неполный список, и обязанности отличаются в разных компаниях, всё зависит от специфики продукта и процессов.

Чем отличается от продуктового менеджера, техлида и архитектора

Чем ТО отличается от продуктового менеджера

Продуктовый менеджер обычно больше фокусируется на управлении командой. Он отвечает за общее видение продукта, общение с клиентами, организацию и сроки. Но чем сложнее продукт и процессы, тем сильнее нужен человек, который сможет управлять и разработкой, и продуктом в целом. Для таких задач есть ТО, который, с одной стороны, понимает, куда движется продукт, какое его позиционирование, с другой — знает, какие нюансы в разработке могут возникнуть и как продукт лучше всего спроектировать.

Чем отличается от тимлида, техлида и архитектора

Тимлид, техлид — это руководители команды, которые отвечают только за её задачи. TO, хоть и глубоко понимает техническую сторону, но его роль шире — он связывает технику с бизнесом и даже консультирует клиентов. Technical Owner отвечает за общее техническое и архитектурное видение продукта. Масштаб его ответственности больше.

В отличие от архитектора, технический владелец не только принимает участие в проектировании, но и доносит эти решения до клиентов и руководства.

Technical Owner (Технический владелец) ответственен за долгосрочное здоровье и развитие конкретного компонента/системы/продукта. Фокус на технической стратегии, архитектуре, надёжности и поддержке в течение всего жизненного цикла.

Техлид руководит командой, отвечающей за разработку. Фокус на распределении задач, наставничестве и решении технических проблем.

Архитектор решений определяет технологический стек и взаимодействие компонентов. Фокус на общей структуре и дизайне решения.

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

Сколько зарабатывает и какие нужны навыки, чтобы стать ТО

Если мы сейчас пойдём на hh.ru и введём в поиск Technical Owner, то, в лучшем случае, найдём только пару вакансий. Technical Owner нужен для больших продуктов в крупных компаниях, поэтому должность встречается на рыке редко и пробиться туда сложно.

Зарплата и навыки зависят от конкретной компании, её процессов и задач. Обычно это что-то на уровне топ-менеджмента. Вот пример заработной платы в одной из вакансий от Яндекс 360:

А вот так выглядят обязанности и необходимые навыки:

Вот пример ещё одной такой вакансии от компании Itransition:

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

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

Кто такой Unit-лид, зачем он нужен

Кто это такой

Юнит-лид — это руководитель, который возглавляет «юнит» – объединение нескольких команд (обычно 3-5), работающих над частью общего продукта или бизнес-направления. Он отвечает за стратегию и бизнес-результаты своего юнита.

В последние полгода в нашей компании появилась новая управленческая роль — Unit Lead. Это ответственный руководитель,который координирует работу всего юнита: от стратегии до найма и развития сотрудников. Мы внедрили эту модель не просто ради структуры — она стала ответом на быстрый рост бизнеса и усложнение внутренних процессов.

Что такое юнит? Это самостоятельный бизнес-модуль, включающий несколько стримов (направлений). Каждый стрим, в свою очередь, состоит из команд по 5-10 человек. Таким образом, один юнит может объединять от 5 до 12 команд, представляющих разные IT-направления: фронтенд, бэкенд, мобайл и др.

Какие у него обязанности

Обязанности юнит-лида очень обширны и зависят от типа юнита:

Стратегическое развитие и планирование: юнит-лид определяет общую стратегию развития своего юнита, составляет планы проектов, согласовывает их со стейкхолдерами.

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

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

Ответственность за результаты: вся ответственность за вектор развития и конечный результат юнита лежит на юнит-лиде. Иногда на нём висит даже отчётность по финансовым результатам.

Разработка и развитие продуктов/инструментов: юнит-лиды могут адаптировать существующие инструменты, разрабатывать новые под потребности команд, а также создавать внутренние платформы и технически сложные продукты.

Чем отличается от продуктового менеджера и тимлида

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

Что делает продуктовый менеджер

Продуктовый менеджер (PM или Product Owner) отвечает за конкретный продукт или его отдельные части. Его главная задача — понять, что нужно пользователям и бизнесу, сформировать требования и приоритеты, а затем воплотить эти требования в жизнь. PM постоянно держит руку на пульсе метрик, проводит A/B-тесты и собирает обратную связь.

Что делает тимлид

Тимлид — это руководитель разработки внутри одной команды. Он отвечает за техническое качество кода, выполнение задач в срок и развитие команды. Его основная забота — чтобы код был качественным, архитектура — адекватной, а команда справлялась с поставленными задачами без перегрузок и постоянных авралов.

Чем занимается юнит-лид

Юнит-лид работает на другом уровне. Если представить компанию как армию, то тимлид руководит взводом, продуктовый менеджер отвечает за успешность операции, а юнит-лид — полковник, который решает, какие операции вообще нужны, какими силами их проводить и как это повлияет на общую картину. Он отвечает за бюджет, координацию нескольких команд и стратегическое развитие целого направления.

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

Две другие команды отдают цены в другие сервисы, организуют скидки, интегрируют новые категории товаров и услуг в систему.

Unit-лид — это такая гибридная роль, которая объединяет менеджерские навыки с техническим пониманием. От тимлида он отличается тем, что не погружается в код-ревью и техническую детализацию спринтов, а больше занимается координацией между командами.

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

В нашей практике в Юнисофт мы сталкивались с ситуацией, когда отсутствие такой роли приводило к хаосу и потере общего видения проекта.

Сколько зарабатывает unit-лид, какие нужны навыки и как им стать

Наткнуться на вакансию юнит-лида на просторах hh.ru тоже непросто. Это новая роль, которая нужна только для сложных продуктов в крупных IT-компаниях.

С зарплатой и обязанностями всё индивидуально, зависит от компании. Вот пример одной из вакансий от Купера:

Зарплата вполне на уровне топ-менеджмента. А вот обязанности и ожидания:

Как видим, помимо менеджерских навыков здесь тоже нужно понимание стека. Но в отличие от Technical Owner, юнит-лид больше сфокусирован на управлении продуктом, чем на его технической составляющей.

А вот ещё один пример обязанностей и ожиданий в другой вакансии, на этот раз от Яндекса:

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

Где и когда эти роли реально нужны (а где — нет)

Какие компании и проекты выигрывают от появления таких ролей

Technical Owner и Unit-лид подходят не всем. В стартапах и небольших командах, где каждый знает свои задачи и зоны ответственности, эти позиции будут избыточными и просто усложнят работу.

Но в крупных компаниях и быстрорастущих проектах, которые уже переросли старые схемы управления, эти роли реально помогают. Если проект вырос до нескольких команд, которые работают над разными продуктами или направлениями, то Unit-лид поможет держать фокус на стратегических целях. Technical Owner пригодится, когда задачи настолько усложнились, что нужен человек, который свяжет технические решения и требования бизнеса, предотвращая недопонимания.

Сигналы, что команде пора подумать о Technical Owner или Unit-лиде

Есть несколько явных признаков, когда стоит задуматься о введении этих ролей:

• Постоянные споры о том, кто должен заниматься интеграциями, техническим долгом и сложными архитектурными вопросами.
• Регулярные задержки и проблемы с релизами из-за несогласованности между командами.
• Непонимание между менеджерами и разработчиками: одни требуют невозможного, другие объясняют технические сложности.
• Наличие нескольких продуктовых направлений, для которых нужны люди, умеющие координировать работу сразу нескольких команд.

Создание этих ролей актуально, когда бизнес выходит за рамки одной команды и одного продукта. Если у компании несколько направлений, которые требуют отдельного фокуса и развития, то Unit-лид — необходимый управленец для децентрализации и роста.

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

1. МояДоска

«МояДоска» — это российский SaaS-сервис для совместной работы и визуализации идей. У онлайн-доски бесконечный размер: это значит, что вы можете размещать сколько угодно элементов и никогда не упретесь в границу. Так, команды, преподаватели и креативные специалисты могут проводить брейнштормы, планирования, презентации и обучение в одном пространстве.

Что под капотом

Фронт написан на React + PixiJS, а бэк — Node.js + PostgreSQL. Это обеспечивает быстрый и понятный интерфейс и стабильную работу даже при большом объёме объектов на доске. Команда выпускает обновления несколько раз в месяц, а о новинках можно узнать в Telegram-канале сервиса. Например, в недавнем апдейте появилась возможность превратить фрейм в таблицу или тетрадь за пару кликов, а еще задать нужное число столбцов, колонок, толщину границ и цвет.

Из главных функций:

• Понятный интерфейс
• Совместная работа в реальном времени
• Привычные инструменты: фигуры, стрелки, стикеры, текст, загрузка файлов, маркер, карандаш
• Обрезка фото прямо на доске, воспроизведение аудио, поддержка PDF
• Гибкое управление доступом
• Возможность повторного использования шаблонов
• Поддержка фреймов и создание логичных пространств для разных задач

Переезд на сервис

«МояДоска» интегрируется в процессы на разных этапах, упрощая жизнь команде. Например, сама команда сервиса перешла с Miro на свою доску для стратегического планирования. С помощью стикеров и стрелок они построили дерево решений, чтобы лучше расставить приоритеты. А одно маркетинговое агентство перевело все документы и сессии планирования на доску, отказавшись от Google Docs и таблиц. Это ускорило принятие решений: сотрудники работали с данными в одном формате, точно собрались в одном кабинете перед маркерной доской.

2. METEOR

METEOR — инструмент управления проектами. Это трекер задач с дашбордами, досками канбан, диаграммами Ганта и API, который работает в виде веб-приложения как в облаке, так и на своих серверах. Продукт создавался как универсальный центр управления задачами: он объединяет в себе все — от разработки и тестирования до маркетинга и поддержки. Сейчас его используют более 250 команд и свыше 2000 пользователей ежедневно.

Что под капотом

В основе — стек Ruby on Rails, React и TypeScript, PostgreSQL и Redis, плюс современная инфраструктура на Docker и Kubernetes.

Система разбита на микросервисы — за фоновую обработку, нотификации и работу с файлами отвечает отдельный функционал. Авторизация построена через OAuth 2.0 (Google, Yandex), а для аналитики используется Posthog и ELK-стек. Мониторинг реализован на Prometheus + Grafana. Обновления выходят каждую неделю, а обратная связь приходит разработчикам METEOR через Telegram-бот.

Вот главные функции:

• Гибкие доски задач (Kanban, Scrum) — 6 видов.
• Списки задач с группировками и иерархией.
• Автоматические отчеты (ежедневные/еженедельные сводки).
• Умные напоминания (Telegram-бот, email).
• Глубокая аналитика (время выполнения задач, загрузка команды).
• Потоковая автоматизация процессов

METEOR — мощный инструмент для автоматизации процессов, с триггерами, серверными функциями и ИИ-аналитикой. Он позволяет гибко настраивать сложные операции.

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

Разработчики используют METEOR для линковки задач с pull-requests и контроля бэклога. Менеджеры получают отчеты автоматически и не тратят часы, чтобы собрать всю информацию вручную. QA ведут тест-кейсы и баги в удобных досках, а DevOps отслеживают инциденты и шаги деплоя. Даже HR подключаются — через систему проходят кандидаты и стажеры.

Переезд на сервис

После внедрения METEOR команды замечают, что продуктивность их работы сильно повышается:

• скорость выполнения задач увеличивается в среднем на 25% — благодаря автоматическим напоминаниям и чётким процессам;
• количество потерянных задач снижается на 70% — исчезают хаотичные чаты и забытые письма;
• на составление отчетов и сбор метрик уходит не 5 часов, а всего 30 минут в неделю;
• а экономия времени — около 75 часов в месяц на команду из 10 человек.

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

3. Gitlife

GitLife — это универсальная платформа для хостинга репозиториев и построения полного DevOps-процесса внутри компании. Разработана с прицелом на закрытые контуры, импортозамещение и гибкость — подходит как для современных Git-проектов, так и для инфраструктур, где все еще используется SVN.

Помимо самого Gitlife, разработчики делают Gitlife AI, в котором есть доступ к топовым ИИ-моделям и инструментам, чтобы разрабатывать ИИ-решения.

Что под капотом

Внутри Gitlife собраны модули для:

• Кода — репозитории, ветвление.
• Задач — бэклоги, спринты, дашборды.
• Документации — совместное редактирование документов, управление правами.
• Аналитики — карты потока ценности, качество кода, метрики по инженерам.
• Пайплайны — модуль «Конвейер» управляет сборками и CI/CD.

Gitlife используется ИТ-отделами и R&D-подразделениями в компаниях с высокими требованиями к информационной безопасности. Подходит как для небольших команд, так и для распределённых корпораций с десятками проектов.

Что решает:

• Безопасный и полностью локальный хостинг исходного кода (Git + SVN)
• Управление задачами и CI/CD в одном месте
• Централизованный доступ, права, аудиты и история изменений
• Полная поддержка DevOps-процессов на российском ПО
• Альтернатива GitHub, GitLab и Bitbucket в условиях ограниченного доступа и санкционных рисков

Переезд на сервис

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

4. Cerebro

Cerebro — профессиональная система для совместной работы и управления проектами. Она помогает ставить задачи, планировать этапы, следить за выполнением, обмениваться файлами и комментировать их прямо в системе. Особенно полезна для команд, которые делают VFX, 3D, анимацию или дизайн — но при этом легко адаптируется и под другие команды.

Платформа охватывает полный цикл — от первых идей и планирования до комментирования финальных шотов (отдельных сцен или кадров в видео/анимации) и соблюдения дедлайнов. Такой подход помогает команде ускорить работу на 20%, сократить время на правки и держать весь процесс под контролем — от начала до сдачи проекта.

Cerebro подходит для команд от 1 до 1000+ человек с задачами на проекте от 1 до 10000+. Сервис работает с 2009 года, сейчас им пользуются более 400 команд в России и СНГ.

Что под капотом

Cerebro поддерживает десктоп (Windows, Mac и Linux), веб-версию и мобильное приложение, локальное, облачное и гибридное развертывание. Инструмент построен на клиент-серверной архитектуре — она гибкая, поэтому можно настраивать конфиги исходя из потребностей бизнеса.

Из технологий:

• Backend: C, C++, Python, SQL
• Frontend: JS, TypeScript, ReactJS, Qt, PyQt
• Мобильные клиенты: React Native
• БД: PostgreSQL с проприетарными расширениями + SQLite
• Файловое хранилище: Cargador
• Плагины: Tentaculo (встраивается в производственные программы)

Cerebro покрывает весь пайплайн — от идеи до финала. Вот основные возможности сервиса:

• Множественные уровни вложенности задач — подходит для сложных иерархий продакшена
• Планирование с помощью диаграммы Ганта и специального инструмента «План»
• Канбан-доска для визуального контроля задач
• Инструмент «Моё пространство» — для персонализированной фильтрации и отбора задач
• Уровни доступа и ролевое управление
• Расширенная статистика по проектам, командам, сотрудникам
• Совместная работа над большими файлами (видео, изображения, 3D) — Mirada позволяет комментировать, делать подрисовки, оставлять голосовые заметки
• Интеграция с пакетами Adobe, Autodesk и мессенджерами, возможность встраивать в любые пайплайны
• Удобное подключение фрилансеров

Переезд на сервис

Обычно внедрение начинается еще на этапе препродакшена — во время разработки концепции и четкого плана действий. Затем система сопровождает проект на всех стадиях, вплоть до постпродакшена (финального тестирования и релиза), где она закрывает 80-100% задач. Cerebro позволяет собирать всё в одном месте: задачи, правки, сроки, бюджеты, загрузку сотрудников и статус проекта в целом.

После переезда снимается много рутинных задач: больше не нужно вручную назначать исполнителей, комментировать медиаконтент, передавать файлы между программами и так далее. В среднем проекты выполняются на 20% быстрее, без потери качества. В больших студиях объем выпускаемых шотов может вырасти до 20+ тысяч — это уже работает у других клиентов, среди которых СберМаркетинг, Sinners, Black Point и другие. Cerebro также помогает переехать с других такс-трекеров и систем для управления проектами.

5. Replit Teams

Replit Teams — это платформа для совместной разработки в реальном времени. По сути, это интегрированная IDE + git-репозиторий + система управления задачами — и все доступно через браузер. Подходит как для командной работы в стартапах, так и для образовательных проектов, хакатонов и небольших продуктовых команд.

А главная фишка — встроенный ИИ, к которому можно обращаться прямо во время написания кода. Инструмент разработан с акцентом на простоту входа, командную работу и быстрое прототипирование. Поддерживает более 50 языков программирования и позволяет запускать полноценные веб-приложения в облаке.

Что под капотом

Внутри Replit Teams есть интерфейсы для:

• Кода — редактор с автокомплитом, подсветкой синтаксиса, терминалом и интеграцией с Git.
• Задач — встроенный таск-менеджер с распределением задач по участникам.
• Общения — встроенные комментарии в коде, возможность ревью и обсуждений.
• CI/DevOps — запуск и отладка приложений без настройки окружения.
• Доступа — гибкие роли, приглашения по ссылке, настройки приватности.

Переезд на сервис

Replit Teams позволяет моментально начать работу: не нужно ставить зависимости, конфигурировать CI или закупать сервера. Подходит как для быстрой прокачки навыков, так и для реальных командных проектов в продакшене.

Сейчас инструмент активно используют в стартапах — для быстрого MVP, парного программирования, хакатонов и удаленных командах — как замена локальным IDE и конфигурациям.

Рассказывайте в комментариях, какими сервисами пользуетесь вы.

Эта статья — подробная хроника эволюции программистов: какие языки и технологии они осваивали, как менялись их рабочие места, методы обучения и даже само восприятие профессии. Мы разберем ключевые этапы, от первых веб-гигантов до эпохи совместного программирования с ИИ, и попробуем представить, что ждет нас дальше.

2005-2009: Эпоха авторских решений и первых веб-фреймворков

В середине 2000-х типичный рабочий инструмент программиста — это громоздкий системный блок с процессором Intel Pentium 4 или новеньким Core 2 Duo. Мониторы с ЭЛТ-трубкой постепенно уступали место LCD-экранам с разрешением 1024×768 — именно на таких дисплеях создавались первые версии Wikipedia и набирающих популярность соцсетей. Оперативная память в 1-2 ГБ считалась нормой, а жесткие диски на 80-160 ГБ часто заполнялись до отказа — проекты редко весили меньше нескольких гигабайт.

Серьезная разработка велась преимущественно на стационарных компьютерах. Ноутбуки только начинали входить в обиход — их брали в офис, но для реальной работы предпочитали мощные десктопы. Операционная система Windows XP доминировала на рабочих станциях, в то время как серверы чаще всего крутили на Linux — Red Hat Enterprise или Debian.

Среды разработки того времени сегодня кажутся архаичными. Eclipse и NetBeans потребляли гигабайты памяти, Visual Studio 2005 требовала серьезных ресурсов. Многие разработчики предпочитали простые текстовые редакторы вроде Notepad++, а для отладки использовали примитивные методы вроде вывода значений переменных через print. Контроль версий только начинал входить в практику — Git появился в 2005 году, но большинство команд продолжали использовать SVN или вообще заливали файлы по FTP напрямую на продакшен.

Языковая экосистема этого периода вращалась вокруг трех основных технологий. PHP версий 4 и 4.3 доминировал в веб-разработке — на нем работало около 80% всех сайтов в интернете. Однако его объектно-ориентированные возможности были крайне ограничены до выхода PHP 5 в 2004 году.

Java в лице J2EE оставалась стандартом для корпоративных решений — банковских систем, крупных порталов и ERP-комплексов. Spring Framework только начинал набирать популярность, а Hibernate упрощал работу с реляционными базами данных. C++ сохранял свои позиции в разработке игр (особенно с использованием Unreal Engine), драйверов и высоконагруженных сервисов.

Фронтенд-разработка в те годы была невероятно простой по современным меркам. Верстали преимущественно таблицами, а всю динамику реализовывали через jQuery, который появился в 2006 году и быстро вытеснил нативный JavaScript из повседневной практики. AJAX-запросы казались революционной технологией, позволяющей обновлять части страницы без ее полной перезагрузки.

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

• «Философия Java» Брюса Эккеля;
• «Совершенный код» Стива Макконнелла;
• «PHP и MySQL. Разработка веб-приложений» Люка Веллинга.

Русскоязычное сообщество активно обсуждало вопросы разработки на форумах RSDN.ru и CyberForum.ru. В 2008 году появился Stack Overflow, который постепенно стал главной площадкой для профессиональных обсуждений.

Университетское образование давало хорошую теоретическую базу — алгоритмы, структуры данных, принципы ООП. Однако практическим навыкам приходилось учиться самостоятельно, методом проб и ошибок. Документацию часто скачивали в формате CHM-файлов или читали непосредственно на сайтах вроде php.net и MSDN.

Типичный стек начинающего разработчика в 2009 году:

• HTML/CSS с jQuery для фронтенда;
• PHP или Ruby on Rails для бэкенда;
• MySQL в качестве базы данных.

ORM-технологии еще не получили широкого распространения, поэтому SQL-запросы писали вручную. Многие проекты представляли собой монолитные приложения, где весь код хранился в единой кодовой базе без четкого разделения на модули.

Показательный кейс:

В 2007 году разработчик PHP-приложений из МЭСИ (Москва) столкнулся с типичной для того времени проблемой — SQL-инъекциями. Вместо стандартных решений он создал DLAC (Data Logic Access Component) — обертку для работы с базой данных, которая автоматически экранировала параметры запросов. Это выглядело революционно на фоне типичного кода того периода, где строки запросов часто собирали через конкатенацию с пользовательским вводом.

Компонент использовал новую для 2005 года технологию Generics в C#. Он генерировал параметризованные запросы, что резко снижало риски взлома.

Разработчики в университетской среде тогда редко задумывались о безопасности — многие проекты содержали уязвимости вроде SELECT * FROM users WHERE name = ‘.$_POST[‘name’].

DLAC стал локальным спасением для внутренних систем МЭСИ, пока в 2009 году не появился NHibernate — порт популярного Java-фреймворка Hibernate.

Этот кейс хорошо иллюстрирует дух эпохи: отсутствие готовых безопасных решений заставляло программистов изобретать велосипеды. Многие подобные наработки позже легли в основу ORM-библиотек, но тогда они рождались в муках — через пробелы в безопасности и километры самописного кода.

2010-2014: Мобильная революция и рассвет JavaScript

Начало нового десятилетия ознаменовалось стремительным ростом мобильных технологий. Выход iPhone 4 в 2010 году и Android 2.3 Gingerbread задал новые стандарты мобильной разработки.

Программисты массово переходили на MacBook Pro — не столько из-за преимуществ macOS, сколько благодаря появлению Retina-дисплеев в 2012 году, которые кардинально улучшили качество отображения кода.

Железо продолжало стремительно эволюционировать. Твердотельные накопители (SSD) начали вытеснять традиционные жесткие диски в рабочих станциях. Облачные платформы вроде AWS и Heroku стали реальной альтернативой локальным серверам, которые раньше часто стояли прямо под рабочими столами в офисах. Оперативная память в 8 ГБ стала стандартом для комфортной разработки, а четырехъядерные процессоры ускорили сборку крупных проектов.

Языковая палитра этого периода значительно расширилась. Objective-C стал основным языком для iOS-разработки и оставался таковым до появления Swift в 2014 году. Python 3 начал набирать популярность благодаря веб-фреймворку Django и научным библиотекам NumPy и Pandas, которые открыли дорогу для анализа данных в массовом сегменте.

JavaScript пережил настоящий ренессанс — после выхода AngularJS в 2010 и Node.js в 2009 году он перестал быть просто «языком для анимаций на сайте», превратившись в полноценную платформу для fullstack-разработки.

Важный факт. В 2011 году разработчик из Сан-Франциско Райан Даль представил Node.js — среду выполнения JavaScript на стороне сервера. За первые 24 часа после релиза проект собрал 10 000 звезд на GitHub, что для того времени стало рекордом. Многие скептически относились к идее использовать JavaScript вне браузера, но уже через год такие компании как LinkedIn и Walmart перевели части своего бэкенда на Node.js, получив прирост производительности в 2-3 раза по сравнению с традиционными решениями на Java и Ruby.

Образовательная сфера претерпела значительные изменения. В 2011 году запустилась Coursera с первым массовым курсом по программированию — Machine Learning от Эндрю Ына. В 2012 году в Кремниевой долине открылся Hack Reactor, ставший прототипом современных coding bootcamps (интенсивов по программированию). Эти форматы предложили альтернативу традиционному университетскому образованию, сделав акцент на практических навыках.

Параллельно в России:

• В 2012 году появился Hexlet — одна из первых русскоязычных платформ с практико-ориентированными курсами по программированию. Особенность: выполнение заданий в реальной среде разработки через браузер. Платформа до сих пор работает: на текущий момент 80% выпускников трудоустраиваются в IT, согласно исследованию ВШЭ. В 2012 этот показатель был еще выше.
• «Нетология» (основана в 2011) к 2013 году запустила курсы по веб-разработке с акцентом на JavaScript и Python, сотрудничая с российскими tech-компаниями. Их модель включала менторство и проектные работы.
• В 2013 году стартовал Stepik — платформа с открытыми курсами от ведущих вузов (ИТМО, МФТИ). Особенность: интерактивные задачи с автоматической проверкой кода, что было прорывом для местного рынка.

Курс «Введение в Linux» от Stepik (2014) за полгода собрал 50 тыс. студентов — рекорд для Рунета. Задания включали настройку виртуальных серверов, что сразу применялось в работе.

Эти проекты заложили основу для бума EdTech в России после 2015 года, доказав, что онлайн-формат может давать актуальные навыки быстрее вузов.

Типичный разработчик среднего уровня в 2014 году:

• понимал принципы REST API;
• начинал осваивать основы DevOps с появлением Docker в 2013;
• экспериментировал с микроконтроллерами вроде Arduino или Raspberry Pi, создавая собственные IoT-устройства.

В профессиональной среде начал формироваться консенсус о том, что PHP устаревает для сложных коммерческих проектов.

2015-2019: Эра больших данных и облачных технологий

Аппаратные возможности сделали очередной рывок вперед. Многоядерные процессоры Intel i7 и AMD Ryzen стали стандартом для рабочих станций. 16 ГБ оперативной памяти перестали быть роскошью, а мониторы с разрешением 4К стали доступны широкому кругу разработчиков. В 2015 году появился Visual Studio Code, который быстро обогнал по популярности Sublime Text и Atom благодаря удачному сочетанию функциональности и производительности.

Языковая экосистема продолжила развитие. TypeScript, представленный в 2014 году, предложил решение проблемы масштабируемости JavaScript-кода в крупных проектах. Go от Google, созданный еще в 2009, нашел свою нишу в разработке микросервисов и инструментов оркестрации вроде Kubernetes (2015). Rust от Mozilla начал завоевывать доверие системных программистов благодаря уникальной системе владения памятью.

JavaScript-сообщество столкнулось с первыми серьезными проблемами. В 2016 году инцидент с пакетом left-pad показал уязвимость экосистемы npm — удаление одного небольшого модуля привело к сбоям в работе тысяч проектов по всему миру. Это заставило разработчиков задуматься о зависимости от сторонних библиотек.

Типичный senior-разработчик в 2019:

• разбирался в микросервисной архитектуре и понимал, как избежать vendor lock-in (привязки к поставщику) при работе с облачными провайдерами;
• имел опыт работы с React или Vue.js;
• знал, что понимание принципов работы алгоритмов становится менее важным, чем развитие soft skills для работы в команде.

Ключевые технологии этого периода включали Kubernetes, который стал стандартом де-факто для оркестрации контейнеров, а также TensorFlow (2015) и PyTorch (2016), открывшие эру машинного обучения для широкого круга разработчиков. Появились первые серьезные инструменты для работы с большими данными — Apache Spark, Hadoop.

Ключевой момент. В 2016 году Netflix раскрыл детали своего перехода на облачную инфраструктуру AWS. Компания полностью перенесла все сервисы — от рекомендательной системы до биллинга — в облако за семь лет. Главным триггером стала катастрофа 2008 года, когда три дня простоя дата-центра оставили 8,4 млн подписчиков без доступа к сервису. Миграция потребовала перепроектирования архитектуры: инженеры разбили монолит на 500 микросервисов и внедрили Chaos Monkey — инструмент для тестирования отказоустойчивости, который случайно отключал серверы в продакшене.

Этот кейс стал хрестоматийным примером cloud-native подхода. Облачные технологии стали активно использоваться в разработке, а обращение с ними — обязательным навыком для прогеров.

2020-2024: AI-assisted разработка и новые парадигмы

Пандемия COVID-19 ускорила переход на удаленную работу. Программисты по достоинству оценили макбуки на чипах M1 (2020) за их энергоэффективность и производительность. Домашние офисы оснащались 32-дюймовыми 4К-мониторами и механическими клавиатурами, ставшими своеобразным профессиональным стандартом.

Языковая палитра продолжала обогащаться. Rust официально вошел в ядро Linux в 2022 году, подтвердив свой статус системного языка нового поколения. Zig появился как современная альтернатива «C» с акцентом на безопасность. WebAssembly (Wasm) позволил запускать ресурсоемкие приложения прямо в браузере, открыв новые возможности для веб-разработки.

Искусственный интеллект начал проникать в повседневную работу программистов. GitHub Copilot на базе GPT-3, представленный в 2021, изменил сам процесс написания кода, предлагая контекстные подсказки. Low-code платформы вроде Retool упростили создание внутренних инструментов для бизнеса.

Типичный lead-разработчик в 2024 году:

• умел эффективно работать в гибридных командах (офис + удаленка);
• автоматизировал рутинные задачи через ChatGPT API;
• следил за развитием квантовых вычислений, хотя практическое применение пока оставалось ограниченным.

Ключевой момент. В 2023 году GitHub Copilot, разработанный совместно с OpenAI, стал катализатором перемен в индустрии. За первый год после релиза инструмент использовали более 1,3 млн разработчиков — каждый десятый подписчик GitHub. Система анализировала контекст кода и предлагала целые функции: например, при написании SQL-запроса она автоматически генерировала соответствующую модель данных на Python. Amazon внедрил аналогичный инструмент Amazon Q Developer для внутренних команд — по заявлению CEO Энди Джесси, это сэкономило компании 4,500 человеко-лет работы и $260 млн ежегодно.

Но были и курьезы. В 2024 году разработчик из Берлина случайно отправил в продакшен код, полностью сгенерированный Copilot. Система использовала фрагмент из GPL-лицензированной библиотеки, что нарушило политику компании по открытому ПО. Инцидент заставил пересмотреть процессы ревью: теперь 78% команд требуют ручной проверки AI-кода перед мержем (слиянием).

Параллельно выяснилось, что Copilot в 40% случаев предлагает уязвимый код при работе с СУБД — это привело к взлому API стартапа через SQL-инъекцию. Такие кейсы показали, что ИИ пока не заменяет программистов, а требует от них новых навыков — критического анализа машинных предложений и понимания юридических аспектов кода.

2025: Современное состояние профессии

Современные рабочие станции программистов оснащены ноутбуками с процессорами Apple M4 (3 нм) или Windows-машинами на Snapdragon X Elite. Мониторы с разрешением 8К используются для разработки AR-приложений, а OLED-экраны с HDR стали стандартом для работы с графикой. Появляются первые экспериментальные IDE с нейроинтерфейсами, способные предсказывать код на основе анализа мозговой активности.

Среди языков программирования выделяется Mojo (2023) — «Python для GPU», набирающий популярность в сфере машинного обучения. Carbon как потенциальный наследник C++ пока остается в тени Rust. Квантовые языки вроде Q# и Cirq интересуют в основном энтузиастов и исследователей.

Профессия претерпела значительные изменения. ИИ стал не конкурентом, а помощником — по некоторым оценкам, около 60% рутинного кода в 2025 году (тесты, документация) генерируется автоматически. Знание английского языка стало важнее знания сложных алгоритмов — без него невозможно эффективно работать с современными AI-инструментами. Понятие «fullstack-разработчик» трансформировалось — теперь оно подразумевает владение фронтендом, одним бэкенд-языком и основами машинного обучения.

За два десятилетия программисты прошли путь от одиночек за CRT-мониторами до участников глобальных распределенных команд. Если в 2005 ключевым навыком было умение написать работающий код, то в 2025 главное — способность эффективно взаимодействовать с ИИ-ассистентами. Однако основы профессии остались неизменными — логическое мышление, способность к абстракции и желание автоматизировать рутинные задачи.

Будущее обещает новые трансформации. К 2030 году нейроинтерфейсы смогут заменить традиционные устройства ввода, а квантовые компьютеры — перевернуть основы криптографии. Но пока актуальными остаются проверенные временем принципы: изучать перспективные технологии (вроде Rust и Mojo), осваивать работу с ИИ и, конечно, совершенствовать главный навык любого программиста — умение быстро и грамотно гуглить.

Ты уже программист, если читаешь это! Больше о кодинге тут.

Откуда началось: мой путь в финтех

До Finance.kz я работал в казахстанских финтех-проектах — bai.kz и finbee.kz. Там понял, что рынок агрегаторов в Казахстане находится в зачаточном состоянии. Пользователи мучились, сравнивая предложения банков вручную, а сами финансовые организации не умели эффективно работать с цифровыми каналами привлечения клиентов.

Finance.kz существовал уже более 3 лет, но работал как классический сайт-витрина. Когда я пришёл в проект год назад, стало ясно: нужно полностью переосмыслить подход и создать технологическое решение нового поколения.

Состояние рынка: от монополии к жёсткой конкуренции

Казахстанский рынок агрегаторов финансовых продуктов переживает бум. Ещё два года назад здесь было 2-3 локальных игрока с простейшим функционалом. Сегодня ситуация кардинально изменилась — зашли зарубежные команды: vbr.kz, fintree.kz, moneypanda.com и другие.

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

Технологические вызовы: интеграция с госсервисами и банками

Главная боль при разработке агрегатора в Казахстане — это интеграции. В отличие от рынков СНГ, здесь нельзя обойтись простым партнёрским трафиком. Пользователи хотят получить продукт онлайн, полностью, без походов в офисы.

API-интеграции с банками и МФО

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

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

Интеграция с госорганами

Finance.kz интегрируется с государственными сервисами eGov и Палаты предпринимателей (ПКБ). Это позволяет автоматически подтягивать справки о доходах, данные о трудоустройстве и другие документы, необходимые для получения кредита.

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

Архитектура продукта: ставка на микросервисы

При проектировании архитектуры Finance.kz мы отказались от монолитного подхода в пользу микросервисов. Это решение диктовалось спецификой агрегатора — нам нужно было обеспечить высокую доступность при интеграции с десятками внешних систем.

Backend

Основные сервисы написаны на Node.js с использованием Express.js. Для работы с базами данных используем PostgreSQL для транзакционных данных и Redis для кэширования. Очереди сообщений реализованы через RabbitMQ — это критично для обработки заявок пользователей.

Отдельно выделили сервис интеграций, который отвечает за взаимодействие с внешними API. Он построен по принципу circuit breaker — если один из банков не отвечает, это не ломает работу всего агрегатора.

Frontend

Фронтенд построен на React с использованием Next.js для серверной отрисовки. Это важно для SEO — львиная доля трафика приходит из поисковых систем по запросам типа «кредит онлайн».

Стратегия «единого окна»: от поиска до получения

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

Для этого мы реализовали несколько ключевых функций:

• Умный подбор продуктов на основе данных пользователя и машинного обучения
• Предварительный скоринг для оценки вероятности одобрения ещё до подачи заявки
• Автоматическое заполнение анкет с подтягиванием данных из госсервисов
• Отслеживание статуса заявки в реальном времени

Монетизация: CPS как основа устойчивого бизнеса

Мы работаем по модели CPS (Cost Per Sale) — получаем комиссию только за успешно выданные продукты. Для кредитов это 2% от суммы, для микрозаймов — фиксированная сумма от 7 до 15 тысяч тенге.

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

Конкурентные преимущества: локализация против красивых интерфейсов

Главное отличие Finance.kz от зарубежных конкурентов — интеграция в казахстанскую финтех-экосистему. Пока они тратят месяцы на адаптацию готовых решений, мы изначально строили продукт под местную специфику.

Что даёт локальный подход:

• Знание рынка: мы понимаем особенности работы казахстанских банков и МФО
• Связи с регуляторами: легче договариваться об интеграциях с госорганами
• Техническая экспертиза: наша команда уже прошла путь интеграции с местными API
• Гибкая настройка продукта под изменения законодательства и требований ЦБ

Результаты и метрики

За год активного развития мы достигли:

• 150 000 уникальных пользователей в месяц
• Интеграция с 15+ финансовыми организациями
• Конверсия заявка-выдача на уровне 35-40% (против 15-20% у конкурентов)
• Средний чек по кредитам — 1,2 млн тенге, по микрозаймам — 85 тысяч

Планы на будущее: от агрегатора к экосистеме

Ближайшие 1-2 года будут критичными для всего рынка. Мы видим несколько ключевых направлений развития:

Расширение продуктовой линейки

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

Внедрение ИИ и машинного обучения

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

Международная экспансия

Рассматриваем возможность выхода на рынки Узбекистана и Кыргызстана. Наша технологическая платформа легко масштабируется на соседние рынки.

Собственные финансовые продукты

В долгосрочной перспективе планируем получить лицензию МФО и предлагать собственные займы наиболее качественным клиентам.

Уроки и выводы

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

Второй важный момент — команда решает всё. Мы собрали людей, которые понимают как технологии, так и специфику финансового рынка. Это даёт нам фору перед конкурентами, которые пытаются адаптировать готовые решения силами удалённых команд.

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

Почему код-ревью — не про власть, а про заботу

Код-ревью — процесс, который помогает проекту и команде расти. И подходить к нему стоит не с позиции «сейчас найду ошибку», а с установки «сделать вместе с разработчиком лучше». На зачем он вообще нужен?

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

Хорошее ревью по сути — это дополнительная пара глаз. Но часто оно воспринимается как экзамен, особенно у джунов. Почему? Комментарии звучат категорично, без объяснений, а ревью превращается в поиск опечаток, а не обсуждение архитектуры. В итоге весь процесс теряет смысл: вместо совместной работы над улучшением кода получается конфликт интересов. В таком случае оптику нужно менять.

Что на самом деле проверяется

В код-ревью обычно проверяется:

• Понятность и читаемость — сможет ли через месяц любой член команды понять, что происходит.
• Надёжность — не развалится ли всё, если пойти по нестандартному сценарию.
• Согласованность — насколько код вписывается в архитектуру и договорённости команды.
• Перспектива — насколько удобно будет этот код поддерживать, масштабировать или переписывать через год.

Задача здесь — дать взгляд со стороны, нащупать правильные вопросы, увидеть то, что автор кода мог не заметить. Но как это сделать правильно?

Чек-лист для ревьюера: что смотреть в коде, чтобы все прошло гладко

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

Логика: всё ли понятно и предсказуемо?

Проверка логики — про то, чтобы прочитать код и сразу понять, зачем он написан именно так. Без нужды лезть в историю коммитов или в личные сообщения к программисту. Вот на что стоит обратить внимание:

Код решает задачу или обходит её?

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

• «А зачем тут это условие?»
• «Можно ли решить задачу проще?»
• «Это бизнес-логика или побочный эффект бага?»

Всё ли предсказуемо?

Хорошая логика — это ожидаемое поведение. Когда видишь функцию getUserRoles, и она действительно возвращает роли пользователя, а не делает лишний лог (или хуже, мутирует глобальное состояние).

Нужно проверить:

• Есть ли неожиданные побочные эффекты?
• Не делает ли функция всё подряд?
• Можно ли использовать этот код повторно?

Учитываются ли граничные случаи?

Тестировать happy path — это приятно. Но ревью — момент, когда нужно быть немного параноиком и задавать себе вопросы:

• «А что, если в массиве будет null?»
• «Что вернётся, если база пустая?»
• «Что произойдёт, если API не ответит?»

Если логика ломается при первой же нестандартной ситуации — это нерабочая логика.

Видна ли связь между частями?

Чем сложнее фича, тем важнее понимать, как всё взаимодействует. Хороший код складывается в историю: ты читаешь файл, и у тебя в голове выстраивается картинка. Если же приходится постоянно прыгать между файлами и держать всё в голове — это тревожный сигнал.

Архитектура: насколько код ложится в общую картину?

Ревью — про то, как новая часть кода вписывается в уже существующую систему. Даже идеально написанное решение может быть неуместно, если оно идёт вразрез с архитектурой проекта. На что обращать внимание:

Живёт ли код в вакууме

Каждый новый модуль, компонент или класс должен:

• быть в нужном слое архитектуры (не пишем, например, SQL-запросы в React-компоненте),
• располагаться там, где его логически ожидаешь (не прячем бизнес-логику в утилитах),
• использовать существующие механизмы, а не дублировать их.

Следует ли код соглашениям команды

Хорошая архитектура держится на дисциплине. Если вы договорились, что у каждого эндпоинта есть слой сервисов — не нужно вызывать репозиторий напрямую из контроллера. Иначе проект превращается в сборную солянку: один разработчик пишет по паттернам, другой — по наитию.

Нужно проверить:

• используются ли принятые в команде подходы;
• поддерживаются ли слои;
• повторяет ли структура проекта предыдущие решения.

Безопасность: нет ли уязвимосей?

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

Пользовательский ввод

Всё, что приходит от пользователя (формы, параметры URL, тело запроса), требует внимания. Здесь могут возникнуть SQL-инъекции, XSS и т.д. Поэтому стоит проверить:

• Есть ли валидация данных на стороне сервера?
• Используются ли подготовленные запросы или ORM?
• Обрабатываются ли потенциально опасные символы?
• Предусмотрена ли защита от исполнения произвольного кода?

Доступ к данным и авторизация

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

• Есть ли проверка прав пользователя перед выполнением запроса?
• Реализована ли проверка не только на фронте, но и на сервере?
• Используются ли идентификаторы, которые нельзя легко перебрать?

Тесты: можно ли быть уверенным, что всё работает?

Хороший тест — реальная гарантия, что при следующем изменении код не сломается. Здесь важно понять, действительно ли тесты покрывают важные сценарии и защищают от регрессий:

Есть ли вообще тесты?

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

Проверяем:

• Есть ли новые юнит- или интеграционные тесты?
• Актуальны ли существующие — не остались ли висящими после изменений?
• Упали ли какие-нибудь тесты в CI — и если да, то почему?

Тестируется ли то, что нужно?

Иногда тесты есть, но проверяют слишком очевидное или не покрывают рисковые места. На что обратить внимание:

• Проверяются ли граничные случаи (например, пустой ввод, null, некорректные данные)?
• Есть ли тесты на негативные сценарии — когда функция должна вернуть ошибку?
• Покрыта ли новая логика?

Понятны ли сами тесты?

Тесты тоже часть кода, и их читают люди. Если логика проверок неочевидна, тесты будут мешать. При ревью задаем вопросы:

• Говорят ли названия тестов, что именно они проверяют?
• Можно ли по коду теста быстро понять, зачем он нужен?
• Нет ли странных чисел или непонятных моков?

Так, хороший код-ревьюер фокусируется на смысловых точках риска. Но как указывать на эти точки? Рассмотрим стратегии взаимодейтсвия с разработчиком во время код-ревью (чтобы последний не возненавидел любую возможность писать код и самого ревьюера).

Как давать комментарии и не звучать резко

Хорошее ревью — это про диалог, в котором оба участника заинтересованы в улучшении кода. Чтобы комментарии воспринимались конструктивно, а не как придирки, важно держать тон и структуру. Разберем четыре простых ориентира.

Начните с положительного: что в этом коде уже хорошо

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

К тому же, положительные комментарии помогают закрепить результат: человек будет знать, что именно сработало — и использовать это снова.

Что можно хвалить:

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

Примеры фраз:

• «Здорово, что ты вынес логику в отдельный хелпер — теперь это читается в разы легче».
• «Классная идея использовать (вставьте код),а не (вставьте код)— так гораздо понятнее».
• «Круто, что добавил тест на этот кейс — про него часто забывают».

Замечания: только по делу и с предложением, как исправить

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

Так НЕ надо:

• «Плохо читается».
• «Переделай»
• «Зачем???»

Так лучше:

• «Можно упростить, если разделить условие на два блока — сейчас выглядит довольно сложно».
• «Тут, кажется, можно обойтись без цикла: достаточно метода (вставьте метод)— он короче и лучше читается»..
• «В этом месте можно потенциально получить undefined. Может, стоит добавить проверку?»

Говорите прямо, без намёков и иронии

Код-ревью — не место для недосказанностей и полутонов. Комментарии вроде «Ну, если так РЕАЛЬНО работает — ок» звучат пассивно-агрессивно и только создают напряжение. Получивший такое замечание будет гадать: это одобрение, сарказм или тонкий намёк, что я всё сделал не так?

Вместо этого — формулируйте замечания ясно и по существу:

• «В этом месте поведение функции может быть неочевидным — можешь уточнить название или добавить комментарий?»
• «Пока непонятно, почему именно такое условие — можешь пояснить, пожалуйста?»
• «Похоже, тут можно упростить: если заменить на (вставьте код) логика станет короче».

Если вы не уверены, как ваша реплика будет воспринята — переформулируйте. В ревью лучше не пошутить, чем задеть человека, особенно если вы не на 100% уверены в уровне вашей взаимной иронии.

Делайте фокус на код, а не на человека

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

Так НЕ надо:

• «Ты опять забыл обработать ошибку».
• «Почему ты так сделал?!»
• «Это неправильно».

Лучше так:

• «Похоже, здесь не хватает обработки ошибки — может быть сбой».
• «Можешь, пожалуйста, уточнить логику? Кажется, тут может возникнуть исключение».
• «Вот так решение будет стабильнее: предлагаю…»

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

Как сделать код-ревью полезным и для себя

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

Учитесь новому: чужой код — тоже учебник

Читая чужие решения, можно заметить многое: библиотеку или инструмент, который вы раньше не использовали; необычную структуру функции или способ организации логики; паттерн, который вы обычно не применяете, но он к месту и т.д. Это особенно полезно, если вы работаете в мультистековой команде. Кто-то пишет на Python, вы — на C++, но идеи и архитектурные подходы легко переносятся между языками. Подмечайте, как другие подходят к задачам, даже если в целом всё вам понятно — детали часто дают самые интересные инсайты.

Заведите привычку задаваться вопросом: «Что здесь сделано хорошо и почему я сам так не пишу?». Или наоборот — «Почему мне этот кусок кажется странным и как бы я сделал иначе?». Такие наблюдения дают гораздо больше, чем кажется на первый взгляд.

Задавайте вопросы, даже если всё понятно

Иногда вы смотрите код — и вроде всё чисто, логично. Но это как раз повод не просто молча одобрить, а пообщаться с проггером. Почему? Потому что вопросы — не всегда сигнал о проблеме: иногда это инструмент обучения.

Например:

• «А почему решили использовать именно этот метод?»
• «Это кастомное решение или такой подход у нас принят в проекте?»
• «Я раньше делал по-другому — есть ли причины, почему здесь выбрали такой путь?»

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

Важно: вопросы должны звучать как приглашение к диалогу, а не как скрытая критика. Если вы спрашиваете «Зачем это вообще нужно?», лучше замените на «Помоги разобраться, почему выбрали такой подход — интересно сравнить с тем, как делал раньше».

Прокачивайте навык объяснять

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

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

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

Почему это работает:

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

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

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

Конкретика вместо общих фраз

Чтобы эффективно использовать ChatGPT, важно понимать, как он обрабатывает запросы. Принцип работы ИИ чат-ботов напоминает усложнённую версию Т9. Если упрощать, то нейросеть обучают на текстовых данных, где она находит связи между словами.

Когда мы отправляем наш текст, ГПТ его считывает, сопоставляет со своей базой и связями, которые он выучил. Далее, отталкиваясь от структуры и последовательности слов в нашем запросе, ИИ определяет оптимальную последовательность символов, слов и фраз, которые с ним связаны. Так формируется ответ.

У ChatGPT и аналогичных моделей обычно большие базы данных. Та же ChatGPT 3 имела 175 млрд параметров. ИИ учитывает эти параметры при составлении ответа. Слова в нашем запросе помогают нейросети правильно ориентироваться в данных: чем конкретнее запрос, тем более релевантную информацию ИИ сможет вытащить из базы. Благодаря чёткому и структурированному запросу мы как бы сужаем фокус поиска и помогаем сформулировать подходящий ответ.

Как написать промт

Наиболее распространённый способ написать рабочий промт — придерживаться следующей структуры:

• Контекст.
• Роль.
• Цель и задача.
• Дополнительные детали.

Благодаря такому подходу мы можем «сузить фокус» нейросети и получить более предсказуемый результат. Кратко рассмотрим элементы структуры промпта на примерах:

Контекст

В контексте мы описываем нашу ситуацию. Что мы делаем, для чего, с какими трудностями сталкиваемся и так далее.

Например:

Я начинающий веб-разработчик, изучаю Python и фреймворк Flask. Для практики и закрепления полученных знаний я хочу создать своё первое небольшое, но полноценное веб-приложение — «Менеджер задач» (To-Do List). Я хочу продумать его структуру и основной функционал, прежде чем приступать к написанию кода.

Роль с опытом

Далее прописываем нейросети роль. Мы прямо указываем, с позиции какого эксперта или персонажа нейросеть должна нам отвечать. Это помогает адаптировать стиль, глубину и направленность ответа. Например, объяснение для новичка тоном «ментора» будет отличаться от технического анализа от «старшего разработчика». Поэтому важно указать правильную роль под нашу задачу.

Пример:

Представь, что ты опытный Full-stack разработчик и ментор. У тебя за плечами более 10 лет создания веб-приложений на Python (включая Flask и Django), и ты успешно наставлял многих начинающих разработчиков в их первых проектах. Ты знаешь, с какими типичными трудностями они сталкиваются и как лучше спланировать проект для эффективного обучения.

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

Цель и задачи

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

Пример:

Цель — получить подробный план и рекомендации для создания веб-приложения «Менеджер задач» на Flask. Задачи:

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

Структура проекта и технологии: Опиши рекомендуемую структуру папок для Flask-приложения и посоветуй основные технологии (например, какую БД использовать для начала, что взять для простого фронтенда).

Потенциальные сложности: Укажи на наиболее вероятные проблемы, с которыми я, как новичок, могу столкнуться при разработке.

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

Дополнительные детали

Это последний штрих, который поможет получить ответ, максимально соответствующий нашим ожиданиям. Сюда можно добавить любую специфическую информацию: примеры, антипримеры, рекомендации, прочие нюансы.

Пример:

Перед тем, как давать полный ответ, пожалуйста, кратко перечисли шаги (подумай шаг за шагом), которые ты предпримешь, чтобы ответить на мой запрос. Отвечай по существу, избегая излишне пространных введений, но при этом давая достаточно деталей по каждому пункту моих задач. Если предлагаешь какие-то конкретные библиотеки или инструменты (кроме Flask), давай краткое пояснение, почему они подходят для новичка в этом проекте.

Иногда нейросети могут выдавать плохой ответ, даже на хорошо структурированный и конкретный запрос. Если ИИ капризничает, то это нормально, надо просто поиграться с уточнениями и формулировкой промпта.

Лучшие практики обучения с ChatGPT

Искать баланс между конкретикой, структурой и краткостью

Эффективное обучение с Chat GPT часто зависит от баланса между конкретикой и объёмом. Наш промпт получился довольно большим, но вполне конкретным. Важная оговорка: такие большие и сложные запросы не всегда уместны для мелких задач. Если мы учим английский для работы в IT и нам нужно перевести слово, или если мы хотим запомнить синтаксис цикла for в Python, то писать такую простыню текста будет избыточно. ИИ прекрасно справится с задачей без этих заморочек. Мы можем написать промпт по такому же подходу, но поменьше:

Пример:

Я учу язык Python, сейчас прохожу циклы. Представь, что ты ментор, который специализируется на Python. Объясни, как устроен цикл for, когда его уместно использовать? Отвечай кратко.

Либо, можно вообще отойти от такой структуры:

Объясни, как устроен цикл for в Python.

Нужно искать баланс между детализацией запроса и его сложностью. Чем труднее задача, тем конкретнее будет промпт и наоборот.

Использовать разные чаты для разных задач

Ещё важный нюанс: у чат-ботов обычно есть память. Они запоминают ход диалога, и это тоже влияет на качество ответов. Поэтому иногда чат может засориться. Например, мы генерируем программу обучения Python, потом просим дать задачки по алгоритмам на C#, потом закидываем кучу документации по react. При формировании ответов ИИ всё это помнит и сбивается. Поэтому под разные задачи стоит использовать отдельные чаты.

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

Например, если мы хотим продолжить обсуждать цикл for, то нам уже не надо заново прописывать контекст и роль:

Придумай 5 упражнений с циклом for.

Постепенно усложнять свои вопросы и пробовать альтернативные подходы

Допустим, мы при обучении пишем функцию и она выдаёт ошибку. Вместо того чтобы писать один огромный промпт, мы можем разбить задачу на шаги и начать с малого. Сперва попросим объяснить конкретные части кода, потом перейдем к общей логике и разберем всю функцию, попросим подробнее разобрать ошибку и так далее.

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

Использовать мета-промты

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

Я начинающий {Указать специализацию}. Мне регулярно приходится изучать что-то новое, планировать структуру проектов, писать код, работать с документацией. В работе я использую нейросети, но на написание структурированных запросов уходит много времени.

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

Твоя цель — помочь мне составить продуманный промпт для {описание задачи}. Я должен получить максимально подходящий и контролируемый результат.

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

В качестве примера можешь опираться на структуру и детализацию этого запроса:
«Я начинающий веб-разработчик, изучаю Python и фреймворк Flask. Для практики и закрепления полученных знаний я хочу создать своё первое небольшое, но полноценное веб-приложение — «Менеджер задач» (To-Do List). Я хочу продумать его структуру и основной функционал, прежде чем приступать к написанию кода.
Представь, что ты опытный Full-stack разработчик и ментор. У тебя за плечами более 10 лет опыта создания веб-приложений на Python (включая Flask и Django), и ты успешно наставлял многих начинающих разработчиков в их первых проектах. Ты знаешь, с какими типичными трудностями они сталкиваются и как лучше спланировать проект для эффективного обучения.
Цель — получить подробный план и рекомендации для создания веб-приложения «Менеджер задач» на Flask. Основные задачи:

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

Структура проекта и технологии: Опиши рекомендуемую структуру папок для Flask-приложения и посоветуй основные технологии (например, какую БД использовать для начала, что взять для простого фронтенда).

Потенциальные сложности: Укажи на наиболее вероятные проблемы, с которыми я, как новичок, могу столкнуться при разработке.
Перед тем как давать полный ответ, пожалуйста, кратко перечисли шаги (подумай шаг за шагом), которые ты предпримешь, чтобы ответить на мой запрос. Отвечай по существу, избегая излишне пространных введений, но при этом давая достаточно деталей по каждому пункту моих задач. Если предлагаешь какие-то конкретные библиотеки или инструменты (кроме Flask), давай краткое пояснение, почему они подходят для новичка в этом проекте.»
Не придумывай факты обо мне. Будь пытливым, задавай дополнительные вопросы, чтобы лучше прописать промпт. Дай знать, если тебе понятна твоя задача.

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

• Prompt Perfect.
• Super Prompter.
• Prompt Wizard.

А вот ещё несколько полезных GPTs для разработчиков:

• Code Copilot — бот для программирования.
• Code Tutor — ИИ, который учит программированию.

• Python GPT — бот для программирования на Python.

Как использовать память и модели ChatGPT для обучения

Что такое память и зачем она нужна

Некоторые нейросети, как Gemini, Grok, ChatGPT, позволяют настроить глобальную память, что может быть полезно при обучении. Мы просто вписываем важную информацию в специальные формы в настройках. При работе во всех чатах ИИ помнит про эту информацию и пытается генерировать более персонализированные ответы. Вспомним, как мы пишем контекст в запросах.

Память — это что-то наподобие контекста, просто универсального. Мы можем добавить информацию о нашем стеке, должности, месте работы, нише и так далее. Вот пример настроенной памяти в ChatGPT:

Также у GPT есть более глобальная память — возможность попросить что-то запомнить или забыть прямо в чате. Мы можем рассказать, чем занимаемся, что планируем, какие форматы ответов любим. ИИ будет учитывать эту информацию при формировании ответов в других диалогах.

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

Какие в ChatGPT есть модели, для каких задач они подходят

Модельный ряд Open AI

В чате ГПТ много моделей. Здесь есть GPT-4o, 4o mini, 4.5, o3, o4-mini, o4 mini-high, o3-mini, o1 / o1-mini.

Для обучения программированию будет достаточно базовой GPT-4o. Её можно использовать вместо поисковика или ментора, чтобы разобраться в сложных темах.

Какие модели подойдут для разработки

Для разработки лучше подойдёт Gpt o3 или 4.1. Они хорошо справляются с задачами по математике и программированию. Правда, доступны только при платной подписке. Как альтернатива — в бесплатной версии можно использовать o4 mini-high. Но это не лучшая модель на рынке.

Если не хотите платить, то, возможно, стоит присмотреться к конкурентам Open AI. Тот же Google раздаёт свою топовую модель Gemini 2.5 Pro бесплатно в AI Studio. Согласно бенчмарку lmarena, Gemini 2.5 Pro обходит нейросети от Open AI в задачах по программированию. Также в кодинге себя хорошо показывает Grok3 и Cloude 3.7 Sonnet. Не стоит забывать и про китайские модели, прежде всего, DeepSeek.

Основные сценарии использования ChatGPT с примерами промптов

Итак, мы разобрались, как правильно составлять промпты, когда они уместны, как настроить ChatGPT и какие модели использовать для тех или иных задач. Рассмотрим несколько сценариев изучения программирования, при помощи ИИ чат-ботов.

Объяснение сложных тем «на простом языке»

Мы можем использовать нейросеть вместо поисковика, учебника или наставника. В программировании много непонятных для новичков тем: рекурсии, ООП, функциональное программирование. В базе ботов есть в том числе учебные материалы. ИИ может их достать и объяснить простым языком, адаптируя информацию под наш уровень.

Пример: объясни, что такое рекурсия

Я начинающий Python-разработчик, сейчас разбираю тему рекурсий. Не могу понять, чем они отличаются от циклов. Представь, что ты опытный ментор, который уже 5 лет обучает новичков программированию на Python. Объясни, что такое рекурсия, чем она отличается от цикла и когда её лучше всего использовать. Ответ должен быть не сильно большим, используй примеры кода.

Вот такой ответ от нейросети получим:

Помощь в написании и отладке кода

Пример: помоги написать функцию сортировки

Допустим, мы учим питон и хотим попрактиковаться на простых задачах. Формулируем промпт так:

Я учусь программировать на Python, недавно начал разбирать функции. Хочу попрактиковаться и написать функцию, которая сортирует список строк по длине (от самой короткой к самой длинной).

Представь, что ты опытный Python-разработчик и ментор. У тебя за плечами более 10 лет опыта, ты обучаешь новичков и понимаешь, какие объяснения для них работают лучше всего.

Моя цель — понять, как работает функция сортировки в Python. Покажи пример такой функции, объясни по шагам каждую строку.

Результат:

Пример: проверь мой код на ошибки

Другой сценарий, это когда наш код не работает или работает не так.

Я новичок в Python. Написал функцию, но она не работает — вылетает ошибка.
Вот код:
def hello(name):print("Привет," name)
hello("Мир")
Представь, что ты опытный преподаватель Python. Объясни, в чём ошибка, как её исправить и почему так нельзя писать. Дай исправленный пример.

Результат:

Генерация идей для проектов и упражнений

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

Пример: составь подробный план обучения

Я изучаю фронтенд-разработку. Уже знаю основы HTML, CSS и JavaScript. Хочу освоить React, чтобы уметь создавать интерфейсы и взаимодействовать с API.
Представь, что ты опытный фронтенд-разработчик и преподаватель. Составь подробный план изучения React на 3 месяца. Укажи, какие темы проходить каждую неделю, какие мини-проекты можно делать, и на что обратить особое внимание. План должен быть реалистичным для человека, который учится в свободное время (около 10 часов в неделю).

Результат:

Пример: придумай проект под мои знания

Я изучаю Python, прошёл основы: переменные, циклы, функции, списки. Хочу попрактиковаться на небольшом проекте, чтобы закрепить знания.
Представь, что ты ментор по Python с опытом преподавания. Придумай 3–5 простых проектов, которые я могу реализовать за выходные. Объясни, какую задачу решает каждый проект и какие навыки он помогает прокачать.

Результат:

Пример: подготовь мне задания для практики

Я изучаю JavaScript, пока прошёл только основы: переменные, функции, массивы. Хочу попрактиковаться.
Сыграй роль преподавателя, который даёт студенту задания для отработки материала. Придумай 5 упражнений, упорядочи их от простого к сложному. Желательно, чтобы они были с короткой формулировкой и подходили для ручной отработки без фреймворков.

Результат:

Ограничения и как их обходить

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

Почему важно перепроверять ответы

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

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

Как использовать дополнительные источники вместе с ChatGPT

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

Выход в интернет

Некоторые модели — вроде ChatGPT, Claude, Gemini, Perplexity и Grok — поддерживают подключение к сети. Это значит, что мы можем просить их найти актуальные решения, примеры кода, ошибки, официальную документацию или свежие статьи. Они работают как поисковик, только в виде диалога.

Работа с файлами и контекстное окно

Другой важный момент — работа с файлами. Мы можем загрузить код, ТЗ, документацию, таблицы или Markdown-файл с задачами. Модель проанализирует содержимое и будет использовать его при ответах. Это удобно, когда нужно задать вопрос по проекту и не хочется копировать всё вручную.

Однако важно учитывать размер документа и контекстного окна. Контекстное окно — это максимальный объём информации, которую нейросеть может запомнить в одном диалоге. У GPT-4o и Deep Seek оно около 128 тыс токенов, у Gemini, Grok и Qwen — 1 млн, у Claude — 200 тыс.

Чем больше окно, тем больше данных можно скормить ИИ чат-боту — например, сразу весь репозиторий, длинную спецификацию или книгу. Модели от Google могут переваривать целые часовые видео.

Интеграция с GitHub

Чат ГПТ поддерживает интеграцию с GitHub. У нас есть три способа, как работать с репозиториями.

Вариант 1 — через GPT-ботов. Мы находим специальных ботов, которые созданы для работы с Github, и используем их.

Вариант 2 — можем работать с GitHub при помощи глубокого поиска из любого чата. Но у этого способа есть недостаток. В бесплатной версии мы можем использовать его только 5 раз в месяц.

Ещё мы можем попробовать работать с GitHub при помощи обычного режима модели GPT 4o с включённым поиском в интернете, но не факт, что ИИ возьмёт данные именно с гитхаба.

В ChatGPT есть возможность привязать GitHub к нашему аккаунту Open AI и работать с репозиториями, без заморочек, в чатах. Делается это через настройки учётной записи.

Отличия платной и бесплатной версии ChatGPT для обучения программированию

Лимиты на использование моделей в платной и бесплатной версии

Самое заметное отличие — лимиты на использование моделей. Бесплатно мы получаем доступ к флагманской GPT-4o, но с ограничениями: обычно это около 10 сообщений на 3–5 часов (точное число зависит от загрузки серверов). Если лимит исчерпан, нас автоматически переключат на менее продвинутую GPT-4.1 mini. Это значит, что разбор сложного алгоритма или отладка бага может прерваться. Придётся ждать или довольствоваться ответами модели попроще.

В платной версии (например, Plus) лимиты «вкуснее»: до 80 сообщений к GPT-4o каждые 3 часа. Этого хватает для долгих диалогов: можно глубже погружаться в темы и не экономить запросы.

Ещё один важный момент — длина контекста: объём информации, который модель «помнит» в рамках одного диалога. GPT-4o и GPT-4.1 mini в бесплатной версии работают с окном в 128 тыс токенов. Это немало, но для анализа объёмного кода, нескольких файлов проекта или длинной документации может не хватить. В платной версии у нас есть доступ к GPT-4.1 с контекстным окном до 1 млн токенов. Здесь мы уже можем скормить проекты на сотни строк кода, и ИИ это всё переварит.

Ещё одна модель, которая заслуживает внимание — GPT o3. Это «думающая модель». Когда мы пишем запрос, то ИИ начинает генерировать разные формулировки по теме, как бы рассуждая. Далее, отталкиваясь от цепочек «рассуждений», получается сформулировать более точный ответ. У неё контекстное окно поскромнее — всего 200 тыс токенов, но зато она отлично справляется с задачами по логике, математике, хорошо подходит при программировании. Доступна только в платной версии.

Задачи и напоминания в чатах

Приятный бонус платной подписки — напоминания и планирование задач. В бесплатной версии этого нет. А с подпиской мы можем попросить ChatGPT, например, ежедневно присылать небольшую задачку по Python или напоминать о повторении материала по JavaScript.

Это похоже на личного AI-ассистента, который помогает учиться регулярно. Для этого ChatGPT использует модели o3 или o4-mini. Одновременно может быть до 10 активных задач.

Когда придёт время напоминания, ChatGPT отправит уведомление на смартфоне, письмо на почту и пришлёт новое сообщение в чате.

Голосовой мод с возможностью использовать камеру и транслировать экран

Общаться с ChatGPT голосом можно и бесплатно (Standard Voice). Но платная подписка даёт Advanced Voice: он звучит естественнее и даже передаёт эмоциональные оттенки. Это предаёт интерактивности при обучении (ногда устаёшь печатать много текста).

Ещё в платной версии во время голосового чата на мобильных устройствах можно включать камеру и делиться экраном.

Например, мы можем «проговорить» с ChatGPT сложную концепцию, получить обратную связь, или, столкнувшись с багом в мобильном приложении, показать его ИИ через камеру либо трансляцию экрана, чтобы вместе разобраться. Это добавляет интерактивности и полезно тем, кому проще воспринимать информацию на слух.

А как вы используете ChatGPT или другие нейросети для изучения программирования? У вас есть свои фишки, удачные примеры или не очень? Делитесь в комментариях и подписывайтесь на наш тг-канал.

Так случалось, пока не появились инструменты вроде TanStack Query и не родились «обертки», которые уменьшают объемы рутины. Как перестать тонуть в запросах на разработку API и начать дышать свободно, рассказывает Дмитрий Скляр, старший разработчик компании Axenix.

API: нервная система цифрового мира

В современном ИТ-ландшафте API давно перестал быть просто техническим термином. Теперь он — один из столпов, на котором держится цифровая цивилизация.

Философия современной разработки давно сместилась от принципа «сделай все сам» к парадигме «собери из лучших компонентов». API стал языком, на котором взаимодействуют цифровые сервисы. Он превратил ИТ-ландшафты и интернет из собрания разрозненных приложений и сайтов в единую живую экосистему, где каждый элемент может взаимодействовать с другим.

Когда разработчик использует API картографического сервиса, ему не нужно разбираться в геоданных или алгоритмах прокладки маршрутов — он просто отправляет запрос и получает готовое решение. Это похоже на то, как мы пользуемся электричеством: не нужно понимать, как работает электростанция, чтобы включить свет в комнате.

Но настоящую революцию API совершил в бизнесе, создав целые экосистемы цифровых услуг. Такие компании, как Stripe, Twilio или Plaid построили свои империи именно на API, предоставляя другим разработчикам готовые «кирпичики» для создания финансовых, коммуникационных или аналитических сервисов.

Внутри крупных компаний API выступают в роли «дипломатов» между микросервисами и ИТ-системами, позволяя разным командам работать независимо, но при этом сохранять общую согласованность. Когда маркетинговая система запрашивает данные о продажах, а сервис логистики получает информацию о новых заказах — все это происходит через четко определенные API-контракты, которые делают сложные системы управляемыми и гибкими.

Боль, которую никто не замечает

Но не все так просто и далеко не так радужно.

Да, формально API — это универсальный мост, например, между фронтендом и бэкендом. На практике же он часто напоминает шаткую подвесную конструкцию: данные приходят в разном формате, документация устаревает еще до релиза, а поля user_name и username существуют одновременно просто потому, что «исторически сложилось».

Типичный сценарий: вы пишете код для запроса списка товаров, все типизируя и описывая модели — 50 строк. Добавляете фильтрацию — еще 30 строк. А через месяц бэкенд меняет структуру ответа, забывает предупредить — и вы тратите день на поиск багов в трех разных местах. И самое обидное: 80% этого кода — копипаст. Проверка ошибок, трансформация данных, инвалидация кэша — все одно и то же, но плодится как вирусы.

Сюда можно добавить также сложность поддержки — API меняется, код устаревает.

Другой момент: код для каждого API-метода имеет схожую структуру. Повторяются основные шаблоны, а различия лишь в типах данных и отдельных деталях. Чем больше API-методов, тем сложнее отслеживать изменения в коде и поддерживать его в актуальном состоянии.

В итоге — дублирование кода, которое усложняет приложение, снижает его читаемость и замедляет разработку новых функций. Документация? Либо устарела, либо ее вообще не писали.

Спасение — в системе

Однажды наши разработчики устали писать однотипные хуки, чинить сломанные запросы и объяснять новичкам, что где находится, почему именно так это работает и почему нельзя просто взять и использовать что-то другое. Устали писать однотипный код для каждого запроса, захотели минимизировать ошибки и ускорить разработку, а также сделать работу с API более структурированной и понятной. Также у команд назрела потребность в скорейшем включении в проект новых разработчиков. Для всех этих задач подходит одно решение: унифицированный подход к API, который также наводит порядок в данных и отчетах, упрощая аналитику и логику приложения.

Тогда и родилась идея фабрики API — слоя абстракции, который скрывает рутину. Для этого мы привлекли возможности TanStack Query, семейство библиотек для управления состоянием данных (data fetching) в клиентских приложениях. Помимо TanStack Query (ранее React Query), к этому классу инструментов также относятся: RTK Query (из Redux Toolkit), Apollo Client (для GraphQL) и SWR.

Их общая философия: «делать рутину невидимой для разработчика». Рассмотрим Конкретные проблемы и их решения.

Однотипные хуки для каждого запроса

В большинстве проектов без дополнительной абстракции каждый хук под API-запрос пишется вручную. Меняется только URL и параметры, а структура остаётся одинаковой: queryKey, queryFn, опции запроса. Это быстро приводит к копипасту, дублированию логики и усложнению поддержки.

Например, для каждого ресурса вроде пользователей, продуктов, заказов и т.д. приходится повторять одну и ту же конструкцию. Если нужно изменить поведение запроса (например, добавить retry или staleTime), правки необходимо делать в десятках мест.

Решение: Универсальная обёртка над хуками TanStack Query

Создание единой функции-генератора для хуков позволяет избавиться от повторяющегося кода. Она принимает ключ, функцию запроса и опциональные параметры — и возвращает сразу «пачку» готовых хуков.

Такой подход:

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

Хрупкость при изменении API

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

Решение: Централизованная трансформация данных + class-transformer.

С помощью class-transformer можно объявить классы сущностей и задать правила преобразования один раз.

Плюсы:

• Все данные автоматически приходят в нужном виде;
• Компоненты работают с гарантированно типизированными данными;
• Один источник правды: при изменении API – правим только Entity-класс;
• Удобно масштабируется, особенно если API большое и сложное.

«Мусор» в данных и отчётах

Решение: Валидация данных при трансформации (например, через class-validator); автоматическая синхронизация кеша (актуальные данные во всём приложении).

Почему это лучше ручного подхода? Смотрите: строк кода на 1 endpoint при ручном управлении потребуется 30+, а с фабрикой — 5-10. Времени для добавления нового поля — 1 час вручную, с фабрикой — 5 минут. Количество мест для правки при изменении API — вручную их много, с фабрикой — лишь одно.

Реальный кейс: в проекте с 50+ endpoint’ами переход на фабрику сократил код на 70%. Разработчики перестают быть «переводчиками» между API и интерфейсами сервисов и приложений, а сосредотачиваются на бизнес-логике. Как сказал один тимлид: «Теперь мы не фиксим баги данных, а делаем фичи, которые нравятся пользователям».

Еще пример: вместо пяти отдельных хуков для CRUD-операций фабрика дает одну функцию createApi(). Вместо ручного парсинга — автоматическую трансформацию данных через class-transformer. А главное — единые правила игры для всего проекта.

Как это работает? Представьте, что вы говорите системе: «Вот endpoint для товаров, вот их модель данных, вот правила валидации» — а все остальное она делает за вас. Хотите получить товар по ID? Пишете useGetByIDQuery. Нужно обновить? — useUpdatetMutation. И никакого шаманства с ручным описанием каждого хука.

Но главное — когда бэкенд меняет API, правки нужны только в одном месте. А новые разработчики перестают спрашивать: «Почему у нас три разных способа загрузить список пользователей?».

Как договориться и не сойти с ума

Проблема в том, что без четкого контракта, набора правил и подходов фронтенд- и бэкенд-разработчики живут в параллельных реальностях. Один думает, что данные придут в camelCase, другой шлет их в snake_case. Один ожидает массив, другой неожиданно подсовывает null. Итог — бесконечные баги, исправления «на живую» и испорченные нервы.

Решение? Четкий контракт. Простой, прозрачный, однозначный. В нем должны быть:

1. Единые правила именования — если бэкенд отдает snake_case, фронтенд не должен гадать, будут ли остальные поля в camelCase, или, например, если в одной модели данных full_name , в другой не будет fullname и так далее.
2. Единый формат запросов и ответов.
3. Договоренности о структуре URL, формате данных и кодах ошибок.
4. Строгая типизация — TypeScript-интерфейсы, которые знают, какие поля обязательны, а какие могут отсутствовать.
5. Документация, которая не врет — если Swagger говорит, что поле email есть, оно должно быть. Всегда.

И самое главное — этот контракт должен соблюдаться. Если бэкендеры меняют API, они обязаны предупредить. Иначе фронтенд превращается в сапера, который каждое утро разминирует прод.

Но, как правило, контракт сделать тяжело. Каждый видит REST по-своему: разные URL, форматы данных, обработка ошибок. Модели данных непоследовательны — поля то есть, то их нет, вложенность меняется. Документации либо нет, либо она устарела, так что API изучаем методом проб и ошибок. От такого надо отказываться сразу и стараться договорится на берегу.

Для унификации и строгого соответствия данных мы используем class-transformer: автоматически приводим данные к нужным форматам, вместо работы с сырыми JSON-объектами. Так получаются экземпляры классов с методами и свойствами. Далее убираем ручную обработку и проверки данных, преобразовываем вложенные структуры и применяем кастомные трансформации.

Что получаем в итоге?

Когда контракт есть, а обертка API готова, магия начинает работать:

• Простота использования: вместо десятков хуков — единая фабрика createApi(). Меньше boilerplate-кода.
• Мощные возможности: данные приходят уже в нужном формате без ручных проверок. Кэш, инвалидация и оптимизации — TanStack Query делает за вас всю грязную работу.
• Новички влетают в проект: больше не нужно объяснять, почему useGetEntity в одном компоненте работает не так, как в другом.
• Активное сообщество: TanStack Query — тысячи разработчиков, готовых ответить на вопросы. Здесь можно найти примеры для любых кейсов: от интеграции с Next.js до кастомного кеширования.
• Нет ограничений по использованию: TanStack Query — не только для React, есть версии для Vue, Svelte и даже Solid.js. Также работает с любым API — REST, GraphQL, WebSockets.
• Работа с SSR без боли: готовая интеграция с Next.js, Remix и другими фреймворками. При этом данные, полученные на сервере, автоматически передаются на клиент. TanStack Query синхронизирует серверный и клиентский рендеринг.

Но есть и ложка дегтя. Отладка усложняется, если что-то сломается внутри обертки — придётся копать глубже. Возникает зависимость от библиотек: class-transformer, axios и сам TanStack Query становятся обязательными.

Однако игра стоит свеч. Потому что время, сэкономленное на рутине, можно потратить на то, что действительно важно — фичи, которые понравятся пользователям, а не бесконечные правки API-вызовов.

Сравнительные примеры

GET /products — Список продуктов

GET /products/:id — Один продукт по id

POST /products — Создание продукта

PUT /products/:id — Обновление продукта по id

DELETE /products/:id — Удаление продукта по id

Как это выглядит в обертке

Все свойства и возвращаемые хуки и конфиги из фабрики:

Пример использования в компонентах:

Использование конфигов:

Для сравнения с классическим решением:

Когда стоит переходить на обертку?

Не каждый проект нуждается в таком подходе к API. Если у вас два-три endpoint’а и они никогда не меняются — возможно, обертка будет избыточной. Но представьте стартап, где каждый месяц добавляются новые сущности: сначала товары, потом отзывы, потом промокоды, рекомендации, аналитика.

Вот где система раскрывается на полную! Новая сущность? Пять минут на добавление — и готовы все CRUD-операции. Изменился бэкенд? Правим в одном месте — и все работает. Пришел новый разработчик? Он не тратит неделю на изучение особенностей API.

Правда, если бэкенд живет в мире хаотичных endpoint’ов (например, GET /fetch_items, но DELETE /removeProduct), обертка не спасет.

Но как навести порядок?

Главный секрет — общаться. Не ждать, пока API сломается, а сразу договориться:

• Какие будут названия полей (created_at vs createdAt);
• Как структурированы ошибки;
• Когда и как можно менять контракт.

Как сказал один разработчик: «фронтенд и бэкенд — как соседи по коммуналке. Можно ругаться из-за бардака на кухне, но лучше сесть и написать правила совместного проживания».

А напоследок — график, для закрепления разницы между работой с оберткой и без нее.

Это приложение запускается на каждый клик и может загружать до 80% одного ядра процессора. В зависимости от конфигурации ПК, это приводит к ощутимым подлагиваниям, особенно на устройствах со слабым железом.

Почему «Пуск» вообще написан на React Native

Microsoft уже давно использует React Native в интерфейсе Windows 11. Например, на этом же фреймворке построена страница «Ваша учетная запись» в настройках.

Компания объясняет такой выбор желанием унифицировать разработку — один код можно использовать и на десктопе, и в вебе.

Но вопрос остается: стоит ли системным элементам, вроде меню «Пуск», быть написанными на веб-технологиях, которые не славятся легкостью и быстродействием?

Упрощение разработки — за счет пользователя

На Reddit и в X.com пользователи протестировали поведение меню с помощью инструментов мониторинга. Оказалось, что каждый вызов «Пуска» запускает тяжелый интерфейс, который обновляется как веб-страница: с анимациями, DOM-объектами и переработкой слоев.

В результате — скачки нагрузки даже на мощных системах, не говоря уже о бюджетных ноутбуках. На скриншотах пользователи показывают рост до 70–80% загрузки одного ядра при каждом открытии меню.

Кармак был прав

На фоне этого всплыло старое высказывание Джона Кармака — легенды геймдева и автора движка серии DOOM и Quake.

По его словам, «мир гораздо меньше зависит от передовых чипов, чем кажется». Главная проблема — не железо, а неэффективное ПО. И если рынок заставит, мы увидим настоящую революцию в оптимизации.

Меню «Пуск» в виде React-приложения — яркий пример. Зачем гонять процессор до 80% ради того, чтобы показать сетку ярлыков?

В статье мы разберёмся, как запустить кодген на основе OpenApi схемы для веб-приложения на стэке React + redux-toolkit.

Для справки: контракт — соглашение о формате данных между клиентом и сервером

Какие проблемы решает кодген?

Любой разработчик может совершить ошибку: неудачно разрезолвить мердж-конфликт, забыть предупредить о рефакторинге или банально опечататься.

В микро-сервисной архитектуре цена таких ошибок высока — оперативно доставить обновления многочисленным клиентам иногда бывает проблематично.

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

Синхронизация контрактов

При активной разработке бекенд постоянно обновляет контракты. Без кодгена все обновления на стороне фронтенда синхронизируются вручную.

Также на основе контрактов создаются побочные интерфейсы, например, для redux-слайсов и react-компонентов. Ошибка в основном контракте создает цепочку проблем со связанными типами и интерфейсами.

Сочетание кодген-контрактов и typescript-утилит для создания побочных интерфейсов делает доставку обновлений простой и безопасной.

Устранение дубликатов

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

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

Совет: Кодген проще и безопасней внедрять на начальных этапах разработки. А в уже написанных проектах — стоит внедрять его постепенно, например, по несколько эндпойнтов за раз.

Что понадобиться для кодгена?

Прежде чем запускать кодген нам нужно минимально настроить проект:

Подготовить схему

OpenAPI-схема в формате yaml:

Важно: Любая ошибка в схеме приводит к поломке кодгена. Поэтому важно, чтобы ваша схема проходила валидацию.

Проверить валидность OpenAPI схемы можно на в swagger редакторе

Настроить Redux

Redux-клиент для API-запросов:

Redux-слайс для хранения данных из API-запроса:

Redux-хранилище с подключенным API-клиентом и редюсером:

Настроить кодген

Для кодгена возьмём официальную библиотеку от Redux — @rtk-query/codegen-openapi

Затем создадим файл настройками кодгена:

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

Если вам нужна гибкость, попробуйте использовать @openapitools/openapi-generator-cli с различными готовыми шаблонами или Orval от tanstack

Запуск кодгена

Для запуска добавим команду в package.json:

Далее заходим в корень проекта и запускаем команду:

На выходе должен получиться файл codegenApi.ts с содержимым:

Проверяем результат:

• Инджект кодген эндпойтов в baseApi;
• Системные типы Props Response Error;
• Контракт User;
• RTK-query хуки.

Совет: создание кодгена можно автоматизировать, например, сделать его отдельным этапом в CI/CD, который выполняется прямо перед билдом приложения.

Возможные проблемы

Необычные типы данных

При внедрении кодгена в проект на Kotlin я столкнулся с проблемой парсинга: кодген не мог распарсить тип данных LocalDateTime, который должен возвращать строку с датой в формате ISO. Вместо строки когден возвращал пустой объект.

LocalDateTime — это класс из Java-библиотеки java.time, который представляет дату и время без учёта временной зоны.

Данную проблему я решил с помощью кодмода:

Кодмод запускается после команды codegen. Он бежит по файлу сверху вниз, находит нужный тип и меняет его значение на string.

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

Кодмоды отлично генерируются с помощью AI.

Плюсы и минусы кодгена

Плюсы:

• Генерируем API-слой всего приложения за секунды;
• Получаем автоматическое строгое создание интерфейсов и типов;
• Избавляемся от опечаток в URL и параметрах;
• Обнаруживаем проблемы с обратной совместимостью контрактов на ранних этапах сборки;
• Экономим время.

Минусы:

• Качество кодгена зависит от качества описания OpenAPI схемы;
• Если схема не генерируется в автоматическом режиме, актуальности OpenAPI схемы потребуется поддерживать вручную;
• Логику нестандартных запросов придётся описывать вручную.

Напоминание: API-слой сложного проекта невозможно покрыть кодогенерацией на 100% — это нормально. Будьте готовы при помощи методов enhanceEndpoints и injectEndpoints комбинировать когден-эндпойнты с эндпойнтам написанными вручную

Заключение

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

В остальных случаях, используя кодген, вы получите предсказуемый и масштабируемый API-слой, который сэкономит сотни часов разработки и поможет вашей команде сместить фокус c рутинных задач на создание качественной бизнес-логики для вашего веб-приложения.

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

Аким Саввин, тимлид команды бэкэнда в ВСК, ментор Эйч Навыки и автор тг-канала, расскажет, зачем разработчики скручивают и накручивают опыт и как это помогает им попасть в компанию.

Опыт — новая нефть

Недавно мы писали про то, что рынок IT перегрет, зарплаты падают, джунов — не берут на работу. Усугубляется ситуация тем, что молодых специалистов стало очень много. Например, на hh.ru количество откликов на джуниор-вакансию может достигать нескольких тысяч. И самые банальные критерии, по которым кандидатов будут отсеивать эйчары — вуз, опыт и возраст. Даже если в объявлении указан минимальный опыт и «базовые знания», на собеседования будут звать тех, у кого был серьезный опыт в разработке — и то, далеко не всех.

В такой системе скилловые ребята с меньшим стажем не могут претендовать на зарплаты, соответствующие их компетенциям, даже если они превосходят более опытных коллег. Это и подпитывает тренд на накрутку опыта: инженеры, проработавшие год-два, но активно развивавшиеся и решавшие сложные задачи, добавляют себе 2–3 года стажа, чтобы пройти отбор и попасть на собеседование.

Недавно в ТикТоке завирусились видео одного «разработчика», который решил провести эксперимент, сможет ли он выдумать резюме, пройти эйчаров и попасть в компанию на зарплату 500+ тысяч. Вы не поверите, но у него получилось — он уже прошел одно техсобеседование, а скоро его ждет второе в другой компании. Отвечать на вопросы, кстати, ему помогает искусственный интеллект. Считайте, он накрутил себе огромный стаж и полностью придумал все достижения на предыдущих местах работы. Здесь возникают вопросы: по каким критериям в принципе эйчары и команда отбирают специалистов? Получается, врать в резюме — просто необходимость? И можно ли оправдать тех, кто скручивает или накручивает опыт, чтобы попасть в компанию?

А этот опыт — он сейчас с вами в одной комнате?

Кейс 1: у нас есть Python-разработчик Паша, которому 21 год, он прошел стажировку в крупной компании, проявил себя, быстро попал в штат и за год сделал кучу крутых фич. Он понял, что вырос из нынешних задач и зарплаты, а повышать его не хотят, потому что у компании, например, нет возможности. Паша начинает рассылать резюме в другой бигтех, но везде отказы. И причина, скорее всего, в нехватке опыта — у нашего героя его всего 1 год.

Один из простых, но не самых честных вариантов для нашего Паши — банально накинуть себе еще 1-2 года опыта. Это реальный способ пробиться через жесткие фильтры HR и ATS-систем, которые часто отсекают кандидатов с недостаточным стажем. Главное здесь — не переусердствовать, иначе этого разговора из небезызвестного фильма не избежать:

Лично я никогда не крутил опыт, но зачем другие люди это делают? Опыт крутят, чтобы было больше шансов попасть на собеседование. Задача HR’ов и нанимающих менеджеров максимально сузить круг подходящих кандидатов. Главная задача — найти самого скилового кандидата. Хороший опыт дает человеку возможность опробовать себя в разных условиях, пообщаться с разными людьми и получить больше практики на разных задачах, а, соответственно, и больше хард- и софт-скиллов.

Кейс 2: Дмитрий Александрович, Java-разработчик с 20-летним стажем хочет перейти в новую компанию по личным причинам, допустим, ему наскучили задачи. Однако такой количество такого большого опыта совершенно не значит, что компании будут стучаться к нему в профиль каждые 3 минуты, поскольку это тоже может быть ред-флагом для эйчаров.

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

Какие в этой системе проблемы

Манипуляции с опытом работают только в том случае, если вы действительно крутой разработчик, который постоянно развивается и готов браться за сложные задачи. Другими словами, с большим опытом приходит большая ответственность. И если со скруткой вряд ли возникнут какие-то проблемы, то с накруткой — ситуация сложная. Разбираемся со всеми рисками на вымышленных (и немного утрированных) историях.

Потеря доверия

Представим, Антон, 24-летний выпускник курсов по Python и стажер в небольшом стартапе, решил, что ему пора уходить в бигтех. После нескольких месяцев безуспешных откликов он решил усилить свое резюме и добавил два года вымышленного опыта работы над проектами в другом стартапе. Его план сработал: резюме прошло фильтр HR, и Антон получил приглашение на собеседование в компанию мечты. Он тщательно подготовился, выучил ответы на типичные вопросы и даже прошел техническое интервью (с трудом).

Но на финальном этапе эйчар попросил предоставить контакты для рекомендаций с «прошлого места работы». Да, такое случается редко, но это вполне возможно, особенно если компания сомневается. Антон запаниковал — никакого стартапа не существовало. Он попытался выкрутиться, придумав отговорки, но эйчар быстро заподозрил ложь. После проверки оказалось, что указанный опыт был фейковым. Антону отказали, а его имя попало в неофициальный черный список компании.

Несоответствие ожиданиям

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

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

Количество опыта не равно качество. Даже 15 лет стажа не гарантируют, что человек работал над сложными проектами, брал на себя интересные задачи или занимался саморазвитием в свободное время. Количество лет опыта стало условным фильтром, который часто используется эйчарами, но утратил связь с реальным уровнем навыков. Также нужно понимать последствия: кто-то это воспримет как обман, но за это вас вряд ли уволят. Уволить могут, если ты не оправдаешь ожидания, не будешь справляться с теми задачами, которые на тебя возлагают. Если ты джун и крутишь на сеньора, то, возможно, тебе понадобится больше времени для решения своих задач, возможно, понадобится ментор, а, возможно, ты и сам справишься, если займешься своим развитием — все зависит от ситуации.

Репутационные риски

Алексей, разработчик с годом реального опыта, хотел ускорить карьерный рост. Он добавил в резюме три года работы над вымышленными проектами, включая роль лида в несуществующей компании. Его харизма и уверенные ответы на собеседовании убедили небольшую IT-компанию нанять его на позицию синьора. Алексей справлялся с задачами на базовом уровне, но его пробелы в знаниях стали очевидны, когда проект усложнился. Коллеги начали подозревать, что его опыт не соответствует заявленному, и слухи дошли до руководства.

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

Вместо заключения: как сделать реальный опыт

Накрутка и скрутка — не единственные способы вырасти в айти. Вот несколько альтернативных вариантов:

1. Фриланс и open-source. Новички могут брать небольшие проекты на фриланс-платформах или участвовать в open-source проектах, чтобы набраться реального опыта.
2. Стажировки. Многие компании предлагают стажировки для джуниоров, которые помогают получить первый опыт без необходимости «накручивать» стаж.
3. Портфолио. Хорошо оформленное портфолио с реальными или пет-проектами точно усилят ваше резюме, если будут выбирать из нескольких человек с одинаковым опытом.
4. Честная самопрезентация. Если вы опытный специалист, фокусируйтесь на реальных навыках и четко объясняйте, почему предыдущий опыт не будет препятствием.
5. Нетворкинг. Посещайте ярмарки вакансий, конференции и хакатоны — там вас могут заметить и позвать в команду.

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

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

Рассмотрим, в чем особенность пушей и почему командам стоит к ним присмотреться.

Почему сначала пуши, а потом СМСки

Казалось бы, мы уже настолько привыкли к пушам из приложений, что СМСки кажутся прошлым веком. Однако многие компании продолжают ими пользоваться — это в какой-то степени логично, поскольку не все устанавливают приложения. Но часто бывает и такое, что бизнес в принципе не стал внедрять подобную функцию.

А зря: во-первых, СМС — всегда сильная зависимость от оператора связи. Пуши же — более гибкая опция, поскольку при их отправке используются ваши собственные каналы связи. Плюс стоимость отправки push-уведомлений значительно ниже, чем у СМС, при этом данные шифруются, а значит, злоумышленники не смогут украсть важные коды.

После 2022 года выбор сервисов для push-уведомлений стал сложнее из-за санкций. Долгое время компании пользовались и по инерции продолжают пользоваться сервисом Firebase Cloud Messaging от Google, но сейчас этот канал не может быть единственным для отправки push, так как могут возникнуть определенные санкционные риски и для бизнеса, а также другие проблемы:

• Одноразовые коды и другие уведомления — чувствительная информация. Зарубежные сервисы передают данные за пределы России, что может быть рискованно.
• Условно-бесплатные аналоги, такие как FCM, не гарантируют доставку и не предоставляют аналитику.
• Некоторые сервисы вовсе заблокированы в России, а другие не работают в Китае, где многие сейчас ведут бизнес.

Как работают push-уведомления: техническая основа

Push-уведомления основаны на клиент-серверной архитектуре, где сервер отправляет данные на устройство через специализированные сервисы. Процесс начинается с регистрации: при запуске приложения устройство генерирует токен (device token) и отправляет его на сервер разработчика. Этот токен используется для маршрутизации сообщений.

Доставка происходит через платформо-зависимые сервисы:

• APNs (Apple Push Notification service): Для iOS и macOS, требует сертификата от Apple и поддерживает богатые уведомления с изображениями и действиями.
• FCM (Firebase Cloud Messaging): Для Android, кросс-платформенный сервис от Google, интегрируется с другими каналами.
• HPK (Huawei Push Kit): Альтернатива для устройств Huawei, особенно актуальна в регионах без Google Services.
• RuStore и Aurora: Российские аналоги для Android, ориентированные на локальный рынок и совместимые с санкционными ограничениями.

Для веб-приложений используются Web Push Notifications на базе Service Workers и протокола Push API, совместимого с браузерами Chrome, Firefox и Edge. Сообщения шифруются с помощью VAPID (Voluntary Application Server Identification) для аутентификации отправителя.

Модель Pub/Sub (Publish/Subscribe) лежит в основе масштабируемых систем: издатели публикуют сообщения в топики, а подписчики (устройства) получают их асинхронно. Это позволяет обрабатывать миллионы подключений без перегрузок. WebSocket или long-polling обеспечивают постоянное соединение для минимальной задержки – часто менее 0,1 секунды.

Вызовы включают:

• Оффлайн-доставку: Если устройство выключено или без интернета, сообщение может потеряться; ретраи (повторные попытки) и каскадирование (переключение на альтернативные каналы) решают эту проблему.
• Географические ограничения: Сервисы вроде FCM могут блокироваться в некоторых странах, требуя омниканальных подходов.
• Безопасность: Уведомления с чувствительными данными (коды аутентификации) нуждаются в end-to-end шифровании, чтобы предотвратить перехват.
• Пользовательский контроль: Пользователи могут отключать пуши, поэтому важно соблюдать регуляции вроде GDPR или 152-ФЗ, избегая спама.

Преимущества пушей над SMS: низкая стоимость (почти нулевая для больших объемов), мгновенная доставка, поддержка мультимедиа (изображения, кнопки действий) и аналитика (открытия, клики).

Омниканальность и лучшие практики внедрения

Омниканальные системы объединяют несколько каналов в единую платформу, обеспечивая доставку независимо от устройства или региона. Это включает каскад: если основной канал (например, собственный WebSocket) недоступен, система переключается на FCM или APNs. Такие подходы достигают 99,9% доставки, с ретраями и мониторингом.

При выборе системы учитывайте:

• Масштабируемость: Поддержка высоких нагрузок, как во время пиковых событий (распродажи, новости).
• Аналитика: Реал-тайм отчеты о доставке, конверсии и отказах для оптимизации кампаний.
• Кастомизация: Deeplink для перехода в конкретный раздел приложения, добавление изображений, ссылок или персонализированного контента.
• Интеграция: REST API и SDK для популярных фреймворков (React Native, Flutter), чтобы внедрение заняло минимум времени.
• Соответствие регуляциям: Локализация данных, сертификаты безопасности (PCI DSS, ФСТЭК) для работы с финансовыми или государственными данными.

Лучшие практики: сегментируйте аудиторию по поведению, тестируйте A/B-варианты сообщений, интегрируйте с CRM для персонализации. Для бизнеса в e-commerce пуши идеальны для напоминаний о корзине, в банках – для транзакций, в медиа – для новостей.

MULTIPUSHED как пример омниканальной платформы

В качестве примера рассмотрим российскую систему MULTIPUSHED от МУЛЬТИФАКТОР, ориентированную на доставку уведомлений в условиях санкций и локальных требований. Она использует SaaS-модель с инфраструктурой в дата-центрах Tier3 (DataLine, Selectel, LinxCloud), защищенной от DDoS через NGENIX.

Архитектура включает Pub для приема сообщений по HTTPS API, Broker для распределения и Router для маршрутизации по каналам: собственный PUSHED, APNs, FCM, HPK, RuStore, Aurora. Sub-серверы поддерживают WebSocket Secure для онлайн-доставки, с каскадированием для оффлайн-случаев.

Процесс: устройство регистрируется, получает токен; отправитель передает сообщение Pub; система маршрутизирует и подтверждает доставку. Совместима с iOS, Android, Aurora, РОСА МОБАЙЛ, KasperskyOS и веб. SDK для Android, iOS, React Native, Flutter, Aurora и Web упрощают интеграцию.

Функции: аналитика в реальном времени, кастомизация (deeplink, изображения), глобальная доставка (включая Китай и регионы РФ). Сообщения шифруются, соответствует 152-ФЗ и PCI DSS, внесена в реестр российского ПО.

Итоговые рекомендации

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

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

Инструменты и окружение

Современные DevOps-инженеры без инструментов — как админ без терминала. Вот что стоит добавить в стек:

Топ-10 инструментов DevOps, которые упростят вашу жизнь и избавят от ночных релизов — Список лучших инструментов для DevOps-инженеров, которые упрощают релизы, мониторинг и CI/CD-процессы. От логгирования до автоматизации тестов.

Podman: Альтернатива Docker без daemon — Знакомим с Podman, инструментом, который не требует daemon, но дает весь функционал Docker.

Docker Hub в России — всё? Гайд, как обойти блокировку —Объясняем, как работать с Docker Hub после блокировки: альтернативы, зеркала и решения.

CI/CD, Kubernetes и деплой

Когда каждое изменение должно доходить до продакшена быстро и без боли — нужна хорошая сборка:

Разворачиваем инструменты CI/CD: практики от DevOps-инженеров — Практическое руководство по внедрению и настройке CI/CD: инструменты, примеры, лайфхаки.

Собираем и деплоим в Kubernetes приложение на Node.js с помощью werf — Пошагово показываем, как собрать и развернуть приложение на Node.js в Kubernetes с помощью инструмента werf.

Как автоматизировать деплой с использованием Kubernetes — Рассказываем, как автоматизировать процесс деплоя приложений в Kubernetes: подходы, инструменты и советы.

Выбираем оптимальную архитектуру мониторинга: от легковесного сервиса до высоконагруженных кластеров —Рассматриваем варианты мониторинга от минимальных решений до сложных систем, подходящих под высокие нагрузки.

Практики и подходы

Не только инструменты, но и культура разработки — основа DevOps:

Как стать DevOps в 2024 году — Что нужно знать, какие навыки прокачивать, с чего начать.

Как автоматизировать безопасность с помощью DevSecOps и искусственного интеллекта — Объясняем, как применить DevSecOps-подход и AI для защиты приложений на всех этапах разработки.

Как serverless-технологии помогают снизить нагрузку на разработчиков — Разбираемся, как serverless помогает ускорить разработку, упростить масштабирование и снизить поддержку инфраструктуры.

Не забывайте читать предыдущие гайды. Python, React, мобильная разработка, С++, инструменты, фронтенд.

Кстати! Забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

1. Топовые инструменты для фронтенд-разработки в 2025 году — собрали самые полезные инструменты, которые помогут фронтендерам работать быстрее и лучше в 2025 году.
2. ReactJS на изи: что реально нужно знать фронтенд-разработчику в 2025 году — кратко и по делу: что должен знать разработчик, работающий с React в 2025 году. Хуки, компоненты, архитектура.
3. Что должен знать уважаемый фронтендер в 2024 году — обновленный список знаний для фронтенд-разработчиков. Современные фреймворки, DevTools и подходы.
4. Фронтенд-разработка: чем занимаются и сколько зарабатывают специалисты — Объясняем, чем занимается фронтенд-разработчик, какие бывают задачи и сколько можно зарабатывать.
5. Как работать с JSON в веб-разработке — простое объяснение JSON: как он устроен, как его использовать и почему без него не обойтись на фронтенде.
6. Как выбрать IDE, если вы начинающий веб-разработчик — обзор самых удобных и популярных сред разработки для начинающих веб-разработчиков, их плюсы и минусы.
7. Эффективные инструменты для оптимизации кода во фронтенд разработке — собрали инструменты, которые помогут ускорить загрузку, уменьшить размер и повысить читаемость кода.
8. 30 самых полезных библиотек Python для веб-разработки в 2024 году — лучшая подборка Python-библиотек для веба: от фреймворков до утилит. Что взять в 2025 году.
9. На каком языке писать сайт в 2024 году — помогаем выбрать язык программирования под сайт в 2025 году. Сравнение по скорости, удобству и экосистеме.

Предыдущие подборки лежат здесь: Python, React, мобильная разработка, С++, инструменты.

Кстати! Забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

База и теория

1. Event loop для чайников: простыми словами о сложном механизме браузера — В статье разбираем, что такое Event Loop, очередь задач и стек вызовов. Простыми словами о том, как браузер выполняет JavaScript-код и обрабатывает события.
2. Чек-лист по Node.js для новичков: обработка ошибок — Показываем основные подходы к обработке ошибок для Node.js. Рассматриваем пошаговую инструкцию и практические примеры.
3. Что нужно учить JavaSript-разработчикам в 2024 году — Разбираем, какие технологии и навыки нужно знать JS-разработчику, в том числе и в 2025. От фреймворков до подходов к архитектуре.
4. Декларативные языки на примерах с JavaScript — Рассказываем, что значит декларативный стиль программирования. Сравниваем с императивным на примерах JavaScript.
5. JavaScript localStorage: Полное руководство — Разбираем, как работает localStorage. Учим сохранять данные на клиенте с помощью JavaScript.
6. Как работает режим strict в JavaScript — Объясняем, что делает режим strict и почему он помогает писать более безопасный код на JavaScript.
7. Как бесплатно выучить JavaScript и не идти в онлайн-школы — Рассказываем, как самостоятельно освоить JavaScript. Бесплатные ресурсы, полезные советы и личный план обучения.
8. Какие JS-библиотеки использовать для анимаций на сайте в 2024 году — Актуальные JavaScript-библиотеки для веб-анимации. Рассматриваем лучшие инструменты для красивых и быстрых интерфейсов.

Практикуемся

1. 10 реальных вопросов с собеседования JavaScript-разработчика с ответами — Подборка реальных вопросов с собеседований для JavaScript-разработчиков. Даем ответы и объясняем, как правильно мыслить на интервью.
2. Приложение прогноза погоды с использованием Vue JS — Пошаговое руководство по созданию погодного приложения на Vue.js. Обучаем взаимодействию с API и построению интерфейса.
3. Математика в программировании: реализуем уравнения на JavaScript — Объясняем, как реализовать математические уравнения на JavaScript. Практика для программистов, которые не боятся формул.
4. Регулярные выражения в JavaScript: разбираемся в создании — Учим создавать и использовать RegExp в JavaScript. Поясняем синтаксис, паттерны и типовые ошибки.
5. Решаем популярные задачи с асинхронным кодом на JavaScript: часть первая — Практика асинхронного программирования на JavaScript. Решаем задачи с API, задержками и промисами.
6. Асинхронный JavaScript: изучаем Async/Await, Callbacks и Promises — Учим писать асинхронный код в JavaScript: от колбэков до современного async/await. Понятно, на примерах и без лишнего.
7. Задачи по асинхронному программированию на JS — Упражнения на асинхронный JavaScript. От простых примеров до сложных сценариев.

Предыдущие подборки лежат здесь: React, мобильная разработка, С++, инструменты.

Кстати! Забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

• Как безболезненно масштабировать компонент?
• Как быстро и просто доставлять изменения?
• Как сделать компонент устойчивым к рефакторингу?

Для решения этих проблем разработчики прибегают к использованию различных паттернов проектирования. Один из таких — «Составной компонент». Сегодня рассмотрим его со всех сторон и дадим рекомендации по использованию.

Дисклеймер:

• Примеры кода упрощены для наглядности и могут требовать доработки под конкретные задачи.
• Подходы в статье не являются универсальными, правильными или неправильными. Каждый из них решает конкретные задачи и проблемы, выбирайте подход согласно требованиям в вашем проекте.
• Автор под понятием дизайн-система подразумевает такие вещи, как UI-кит и библиотека компонентов .

Какие проблемы помогает решить «Составной компонент»?

При создании переиспользуемых компонентов разработчики вынуждены решать одни и те же проблемы:

• Как сделать строение компонента достаточно гибким, чтобы оно покрывало как можно больше вариантов использования? Если об этом не подумать — вокруг появятся вспомогательные компоненты и утилитарные функции.

• Как сделать API компонента устойчивым к изменениям? Если об этом не подумать props начинают обрастать пометками deprecated, появляются проблемы с обратной совместимостью старых и новых props, а время рефакторинга и выхода новой версии неизбежно приближается.

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

• Создание новых тестов и обновление старых (снапшоты, скриншоты, e2e),
• Обновление документации или сторибука,
• Проверка изменений в реальном проекте,
• Запуск CI-CD пайплайнов для доставки изменений.

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

Все эти проблемы стремится решить «Составной компонент»

Из чего состоит «Составной компонент»?

Компонент становится «составным» при наличии следующих свойств:

Есть иерархия:

• Есть главный и дочерние компоненты,
• Дочерние компоненты зависят от главного.

Есть общая логика:

• У компонентов есть общее внутреннее состояние, например: открыть/закрыть компонент, выбрать вид отображения и т.п.
• Главный компонент содержит логику управления дочерними компонентами, например: выбрать активный элемент, раскрыть элементы, добавить элемент в список и т.п.

Нет противоречий с основными принципами SOLID:

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

Как создать свой «Составной компонент»?

Для примера сделаем компонент Аккордеона.

Но, в начале сделаем классический React-компонент через props — так мы лучше поймем преимущества одного подхода и недостатки другого:

Реализация

Применение

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

Создаём «Составной компонент»

Теперь сделаем компонент на основе паттерна, подробно разобрав его архитектуру. Начнём с декомпозиции компонента на составные части:

Основной компонент

Назначение:

• Управлять своим состоянием,
• Выступать контроллером для дочерних компонентов, обеспечивая их согласованную работу.

Во избежание props-дриллинг для передачи состояния от основного компонента к дочерним будем использовать React Context API:

Дочерние компоненты

Назначение:

• Принимать логику, состояние и методы из главного компонента через React Context API
• Реагировать на изменение собственных props

Функциональная обёртка

• Помогает дочерним компонентам быть неконтролируемыми

Компонент заголовка

• Отображает заголовок и реагирует на действия пользователя

Компонент контента

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

Теперь сложим все составные части и попробуем собрать полноценный компонент:

Что произойдет при внесении изменений в компонент?

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

Добавим кнопку «Закрыть»

Как сработает обычный компонент

Плюсы:

• Подход очевиден, прост и интуитивно понятен,
• Положение кнопки «Закрыть» определяется один раз.

Минусы:

• Местоположение компонента жестко закреплено,
• Изменить лэйбл и навесить дополнительное событие можно только через создание новых props в основном компоненте.

Как сработает составной компонент

Плюсы:

• Компонент может свободно перемещается внутри Accordion.Item,
• На компонент можно навесить любой хэндлер без изменения props.

Минусы:

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

Добавим компонент «Разделитель»

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

Обычный компонент

Плюсы:

• Положение разделителя определяется один раз.

Минусы:

• Изменить расположение разделителя можно только через изменение кода основного компонента.
• Добавить новые свойства компоненту можно только через props основного компонента.

Составной компонент

Плюсы:

• Положение элемента можно свободно перемещать без изменений в основном компоненте

О каких особенностях паттерна важно знать?

Тришейкинг

Как только компонент становится свойством объекта — сборщик перестает считать неиспользуемые составные компоненты «мертвым кодом». Следовательно, такие компоненты будут всегда попадать в конечный бандл.

Next.JS

Использование подхода в среде Next.JS приводит к ошибке. Ошибка связана с разделением компонентов внутри фреймворка на клиентские и серверные. Проблема решается указанием директивы 'use client' в начале файла там, где используются составные компоненты.

Выводы

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

Если React-компонент внутри дизайн-системы обладает сложной логикой, управляет внутренним состоянием, имеет зависимые дочерние компоненты, требует гибкости и кастомизации, то он — хороший кандидат для реализации с использованием паттерна «Составной компонент». Примеры таких компонентов: RadioGroup, TagGroup, Select, Dropdown, Form, Tab.

Кстати, если хотите узнать больше про React, недавно мы выпустили подборку наших материалов. Скорее смотрите!

Основные инструменты и технологии

Статьи, с которых стоит начать, если хочется обновить стек или разобраться в новых подходах:

ТОП 60 лучших инструментов для разработки ПО в 2025 — Собрали шестьдесят лучших инструментов для разработки программного обеспечения в 2025 году. От трекеров и редакторов до библиотек и фреймворков.

Топ 11 трендов, которые нужны айтишнику в 2025 году — Представляем одиннадцать ключевых трендов в IT, которые будут актуальны в 2025 году. Краткий гид по технологиям, которые будут на слуху.

Фреймворки, меняющие игру: выбираем идеальный инструмент для ваших веб-проектов — Обзор современных веб-фреймворков, которые могут изменить подход к разработке ваших проектов.

Инструменты и фреймворки QA, которые (не) нужно знать — о том, что реально используется в тестировании.

Что изучать начинающему разработчику на C# — рассматриваем языки, среды и подходы, которые пригодятся новичкам. Рекомендуем, с чего начать изучение C# и какие темы освоить в первую очередь.

ReactJS на изи: что реально нужно знать фронтенд-разработчику в 2025 году — Краткий гайд по ключевым знаниям и навыкам, необходимым для работы с ReactJS в 2025 году.

Базы, API, DevOps и CI/CD

Набор инструментов и практик, которые помогут масштабироваться и не выгорать:

Топ-10 инструментов DevOps, которые упростят вашу жизнь и избавят от ночных релизов — must-have решения для DevOps-команд.

PostgreSQL vs. ClickHouse vs. DuckDB: какую опенсорс базу выбрать для аналитики в 2025 году? — Сравниваем три популярные опенсорс СУБД для аналитики: возможности, производительность и кейсы использования.

Семь API, которые сократят вам недели разработки — Подборка решений, которые можно быстро внедрить.

Разворачиваем инструменты CI/CD: практики от DevOps-инженеров — Делимся практическими советами по развертыванию инструментов CI/CD от профессионалов.

Как автоматизировать простые задачи с помощью скриптов? — Гайд по быстрой автоматизации без боли.

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

AI-инструменты и нейросети

Что может помочь вам уже сейчас — от подсказок до генерации кода:

Топ-5 ИИ-инструментов для программистов в 2025 году — Самые полезные AI-ассистенты по мнению редакции.

DeepSeek или Claude: какая нейросеть напишет код, за который не стыдно? — Сравниваем возможности нейросетей DeepSeek и Claude в контексте генерации качественного кода.

Edge AI: как работают нейросети на устройствах с ограниченными ресурсами — Объясняем, как нейросети работают на устройствах с ограниченными ресурсами и где это применимо.

10 способов заработать на искусственном интеллекте в 2025 — Рассказываем о десяти способах монетизации искусственного интеллекта в 2025 году.

Утилиты, лайфхаки и неожиданно полезные штуки

То, что экономит время, силы и нервы:

11 сайтов, экономящих время, которые нужны каждому разработчику — Подборка must-have ресурсов.

7 библиотек для анимаций на React — Обзор популярных библиотек для создания анимаций в React: от простых эффектов до сложных переходов.

30 самых полезных библиотек Python для веб-разработки в 2024 году — Подборка тридцати полезных библиотек Python, которые пригодятся веб-разработчикам в 2025 году.

7 программ для шифрования данных — Базовая кибер-гигиена для всех, кто работает с пользовательскими данными.

Топ самых полезных магических команд для завсегдатаев Colab — Рассказываем, как использовать магические команды в Colab, чтобы ускорить работу с данными и кодом.

5 ETL для обработки данных из Python-ботов — Представляем пять ETL-инструментов, которые помогут автоматизировать сбор, трансформацию и загрузку данных от Python-ботов

Работа с Excel: где он применяется, чем полезен и где освоить этот навык — Объясняем, где и как используется Excel, почему он важен для аналитиков и где научиться работать с ним.

Немного философии

Когда хочется не просто выбрать инструмент, а понять, зачем он вам нужен:

Язык Elixir и функциональное программирование: что это за зверь и почему он хорош для отказоустойчивых систем — Знакомим пользователей с Elixir и его применением.

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

10 лучших платформ для создания приложений без единой строчки кода — Обзор десяти лучших no-code платформ, позволяющих создавать приложения без программирования.

Скорее пользуйтесь нашим гайдом и читайте предыдущие. Вот, например, по мобильной разработке и React.

Кстати! Забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

Немного базы

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

• ReactJS на изи: что реально нужно знать фронтенд-разработчику в 2025 году — помогаем новичкам войти войти и показываем опытным разработчикам, что они могли упустить.
• Какие есть паттерны в React и для чего они нужны: часть 1 и Какие есть паттерны в React и для чего они нужны: часть 2 — здесь объясняем популярные архитектурные паттерны в React, когда и зачем их применять.
• 7 библиотек для анимаций на React / Tproger — собрали актуальные библиотеки для анимации в React; сравнение, демо и рекомендации.
• Типичные ошибки джунов, использующих React — показываем типичные ошибки junior-разработчиков в React, рассказываем, как писать чище и стабильнее.
• Подготовка окружения React-приложения: VSCode, Prettier, ESLint, Stylelint, Husky — рассказываем, как начать работу с приложениями на Реакте и что должно быть на рабочем столе.
• React Native против Flutter: что лучше (для общего развития) — сравниваем популярные фреймворки для кроссплатформенной разработки; плюсы, минусы и рекомендации.
• Deeplink в React Native: Полное руководств для новичков — рассказываем, что такое deeplink и как их писать на Реакте.

Практикуемся

• Современный Drag and Drop в React с помощью dndkit: создаем перетаскиваемое меню — здесь о том, как сделать меню, кнопки и все с помощью dndkit.
• Пишем приложение с бэкендом на Django и фронтендом на React — рассказываем, как создать REST API на Джанго, добавить React и объединить это в один проект.
• Создание ToDo-листа бесконечной вложенности на React, TypeScript и MobX — пошагово создаем вложенные задачи в ToDo-приложении, используем MobX, React и TypeScript.
• Создание Typing Test приложения на React + TypeScript + Redux Toolkit — учимся создавать приложение для проверки скорости набора текста, используем Redux Toolkit.
• Найди ошибку в React-компоненте: Функциональное Карри — практический кейс: ищем ошибку в React и заодно изучаем каррирование функций.
• Создание приложений для Windows на React Native — разбираем, как запускать и разрабатывать React Native-приложения под Windows, примеры и инструменты.
• Оптимизация графиков Recharts — ускоряем отрисовку графиков на React с помощью Recharts, практика, кейсы и улучшения.
• Как разработать своё первое приложение на React Native — инструкция по созданию первого мобильного приложения на React Native, от идеи до запуска.
• Пет-проект на React. Как мы «озвучивали» интернет — история реализации проекта с Web Speech API и React. Учим браузер говорить.

Кстати, похожий гайд мы уже делали — про Python. Можно заценить здесь.

Если научиться работать с ИИ-моделями, даже начинающий разработчик сможет перепрыгнуть с уровня «кодер кнопок» до «архитектор интерфейсов».

AI — не замена разработчику, а новый хард-скилл. Те, кто осваивает нейросети, в 10 раз продуктивнее коллег, все еще верстающих каждый элемент вручную.

Pixel perfect по запросу: как фронтендеры генерируют интерфейс в 2025 году

*Дизайнер прислал макет в 23:45. Дедлайн — завтра в 10:00*

Знакомо? Раньше это означало ночь без сна. Но что делают ваши коллеги — просто скармливают макет нейронке и идут спать. Утром правят готовый код и укладываются даже в безумный дедлайн без вреда для здоровья.

Что изменилось?

AI-генерация интерфейсов становится рабочим инструментом. Можно конвертировать текст и даже рисунок от руки в готовый HTML/CSS/JS код. Без выравнивания пикселей и утомительной верстки однотипных элементов.

Вы вводите «Создай карточку товара с изображением, названием, ценой и кнопкой “В корзину”» — и получаете код компонента. То, что раньше занимало до 30 минут, теперь можно делать за секунды.

3 причины делегировать рутинную работу на ИИ

AI-генерация компонентов

Помните, как в 100-й раз писали карусель или модалку? Есть инструменты, которым достаточно описания результата — нейросеть сгенерирует компонент с нуля.

GitHub Copilot, Anthropic Claude и AI-плагины для VSCode превращают текстовый запрос в рабочий интерфейс. Причем не просто работающий, а соблюдающий ваши стандарты оформления кода.

Адаптив на автопилоте

Дебаг мобильной верстки не доставляет удовольствие?

Можно обратиться к ИИ — нейросеть генерирует базовый интерфейс и сразу продумывает адаптив (если попросить об этом). Вместо десятков медиа-запросов — функция, которая преобразует ваш многоколоночный интерфейс в мобильную версию.

Дизайнер с «Глазом Бога»

«Кажется, кнопка должна быть правее» — нет, ИИ выдает конкретные рекомендации.

Например:

«При ширине экрана 375px карточки товаров перекрывают друг друга на 12px. Причина: отрицательный margin в классе .product-card, который не учитывает падение грида на мобильных устройствах».

ИИ анализирует верстку и сравнивает ее с лучшими практиками UI/UX. Еще нейронка «видит» проблемы, которые не заметны до первых жалоб на баг.

Популярные модели и технологии

GPT, Claude и Gemini

Нейросети последних версий при четкой постановке задачи сразу пишут хороший код. В 2025 году это относится ко всем популярным моделям.

О том, как правильно составлять запросы для ИИ, рассказывали в статье «Продвинутый промтинг в ChatGPT».

На качество кода влияет выбор между «тяжелыми» и «легкими» версиями.

Например, GPT-4o генерирует код лучше, чем Claude 3, но обходится значительно дороже.

Релизы свежих версий ИИ сопровождаются отчетами с бенчмарками. На 100% доверять этой информации не стоит — если в тестах нейросеть показала хороший результат, не факт, что она эффективна в реальных условиях.

Если нужно сравнить несколько моделей, но времени на самостоятельные тесты нет, обратите внимание на Arena Leaderboard. Этот рейтинг имеет хорошую репутацию в профессиональных кругах. Люди делают одинаковые запросы двум нейросетям и сравнивают ответы. Рейтинг формируется на основе оценок от реальных пользователей.

GPT-Engineer, Smol Developer

Если ChatGPT действует как советчик, то GPT-Engineer и Smol Developer участвуют как полноценные члены команды.

GPT-Engineer трансформирует текстовое описание в готовый проект. Разработчику достаточно сформулировать задачу — AI создаст структуру проекта с файлами, настроит окружение и сгенерирует код.

Smol Developer предлагает иной подход — персонального AI-разработчика. С аудиторией более 10,000 пользователей на GitHub, этот инструмент отличается интуитивным интерфейсом и поддержкой E2B SDK.

No-code/Low-code платформы

Uizard превращает идею в интерактивный прототип быстрее, чем команда дизайнеров набрасывает первые эскизы. За 7 лет инструмент эволюционировал в no-code платформу для создания UI/UX без дизайнерского бэкграунда.

Ключевые функции:

• Автодизайнер 2.0 — генерирует многоэкранные интерфейсы по текстовому описанию.
• Дизайн по эскизу — сфотографируйте рисунок с салфетки, и Uizard трансформирует его в редактируемый прототип.
• Клонирование интерфейсов — загрузите скриншот существующего сайта, и AI превратит его в настраиваемый макет, сохранив структуру и компоновку.
• Экспорт в PNG, PDF и генерация AI базового React-кода (требует доработки).

Locofy пригодится на следующем шаге после создания дизайна — превращении макетов в рабочий код.

Преимущества:

• Генерация кода для React, Angular, Vue.js и других фреймворков.
• Распознавание кнопки, поля ввода, слайдеры для создания динамического элемента.
• Платформа анализирует дизайн и автоматически добавляет медиа-запросы.

Связка Uizard + Locofy формирует конвейер от идеи до кода:

1. Создание прототипа в Uizard по текстовому описанию или наброску.
2. Экспорт в Figma для детальной проработки.
3. Преобразование в код через Locofy.
4. Доработка и интеграция с бэкендом.

Бесплатные тарифы позволяют оценить возможности платформ, но для полноценного использования в работе потребуется платная подписка — от 12$ в месяц.

AI-плагины в Figma

Фигма преобразилась с появлением AI-плагинов. В коллекции десятки дополнений на базе нейросетей.

AI Design by Figma — официальный ИИ-помощник для генерации интерфейсов, встроенный прямо в редактор.

Функционал:

• Создание элементов по текстовому описанию.
• Генерация нескольких вариаций компонентов.
• Трансформация простых фигур в иллюстрации.
• Предложение альтернативных цветовых решений.

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

Режим AutoLayout автоматизирует верстку элементов. Функция анализирует расположение объектов и предлагает наиболее логичную систему компоновки.

Еще в Фигме есть интеллектуальное определение отступов между элементами, создание адаптивных сеток на основе расположения компонентов, оптимизация приложения для различных разрешений экрана и автоматическое выравнивание элементов интерфейса.

Путь от запроса к интерфейсу: этапы работы с AI

Шаг 1: Формулировка промпта

Качество сгенерированного интерфейса зависит от точности запроса. ИИ-модели считывают структурированные инструкции лучше, чем набор общих фраз.

Вместо размытого «Сделай хедер» лучше попросить «Создай адаптивный хедер с логотипом слева, навигационным меню по центру и кнопкой авторизации справа».

Шаг 2: Генерация кода

ИИ превращает текст в код, анализируя миллиарды строк из репозиториев и документации. Процесс включает:

• Разбор запроса на технические требования.
• Определение структуры компонента/интерфейса.
• Генерацию HTML/JSX элементов.
• Формирование стилей и интерактивных элементов.
• Оптимизацию согласно паттернам.

Стандартный запрос для генерации компонента пользовательского интерфейса занимает 3-15 секунд.

Шаг 3: Визуализация и проверка

AI-инструменты позволяют мгновенно увидеть результат без настройки окружения. Ваш запрос трансформируется в код, который тут же визуализируется.

Варианты визуализации:

• Встроенные рендереры в IDE (VS Code + GitHub Copilot).
• AI-платформы с предпросмотром (V0, Figma Dev Mode).
• Локальные песочницы (CodeSandbox, StackBlitz).

Шаг 4: Человеческая доработка — финальный штрих

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

Типичные улучшения:

• Добавление проверок на доступность (ARIA-атрибуты).
• Оптимизация производительности (lazy loading).
• Интеграция с реальными данными и API.

Стоит отметить, что ИИ успешно генерирует компоненты для React-приложения, включая:

• Функциональные компоненты с хуками.
• Context API для хранения состояния.
• Мемоизацию через useMemo/useCallback.

Генерация для Vue отлично работает с Composition API. ИИ автоматически применяет ref и reactive для состояния, computed для производных значений и методы для обработчиков.

В процессе создания UI с помощью ИИ не обойтись без проверки качества полученного результата. Тестировать сгенерированное веб-приложение приходится в несколько подходов:

• Визуальный просмотр — проверка соответствия дизайна требованиям и ожиданиям пользователя.
• Кросс-браузерная совместимость — тестирование работы интерфейса в различных браузерах и устройствах.
• Проверка доступности — оценка соответствия стандартам WCAG для обеспечения доступности для всех пользователей.
• Валидация HTML/CSS/JS — использование линтеров и валидаторов для проверки качества кода.
• Юзабилити-тестирование (E2E) — оценка удобства использования интерфейса реальными пользователями.

Плюсы и минусы AI для генерации пользовательского интерфейса

Подводные камни

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

— Шаблонность. ИИ тяготеет к стандартным решениям. Бесполезно пытать нейросеть запросами по типу «нужен уникальный и креативный дизайн». В ответ вы получите очередной шаблон.

— Усредненный UX вместо продуманного. ИИ ориентируется на паттерны, которыми был обучен. Результат часто напоминает интерфейс из 2021 года без учета новейших трендов в UX.

— Зависимость от контекста. Чем сложнее и нестандартнее требование, тем выше шанс, что ИИ не справится с задачей.

— Переоптимизм. Когда люди обращаются к ИИ, то ожидают идеальный результат с первой попытки. К сожалению, так не бывает.

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

Преимущества AI frontend

— Быстрое прототипирование. ИИ выдает рабочий код за секунды. Полноценный скелет интерфейса появляется по первому запросу: «Создай страницу профиля пользователя с аватаром, статистикой активности и настройками».

— Улучшения на ходу. ИИ вносит изменения мгновенно. Разработчик лишь направляет процесс.

— Поддержка компонентного подхода. ИИ генерирует компоненты, соответствующие архитектурным паттернам.

— Дизайн-варианты с A/B-тестированием. Тестирование гипотез ускоряется в несколько раз. Запрашивайте несколько вариантов UI без дополнительных затрат.

Кейсы и примеры: что реальные разработчики говорят про ИИ

Согласно исследованию Cloud.ru, 62% российских IT-специалистов доверяют AI как коллеге. Российские разработчики активно интегрируют ИИ в рабочие процессы — 73% используют его для работы с кодом, а 39% применяют ежедневно.

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

Рассмотрим три популярных сценария применения ИИ во frontend-разработке.

1. Создание панели администратора за 5 минут

AI-ассистенты значительно ускоряют разработку типовых интерфейсов. Опишите требуемые функции админ-панели (управление пользователями, статистика, редактирование контента), и нейросеть сгенерирует базовую структуру, HTML-разметку и CSS-стили.

2. Быстрое создание дизайна лендинга по описанию продукта

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

3. Адаптация UI под разные разрешения и аудитории

Нейросеть упрощает создание адаптивных интерфейсов и персонализацию UX для различных пользовательских сегментов.

Интересно, что 46% разработчиков отдают предпочтение именно российским AI-сервисам, что говорит о росте доверия к отечественным ИИ-решениям. Еще исследование Cloud.ru выявило, что в 70% вакансий работодатели упоминают навык владения AI-инструментами.

Будущее AI во frontend-разработке

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

Финальная стадия эволюции — создание интерфейсов без интерфейса проектирования.

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

Вопрос не в том, заменит ли ИИ фронтендеров, а в том, заменят ли фронтендеры с ИИ тех, кто продолжает работать по старинке.

Кстати, забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами.

1. Какие есть паттерны в React и для чего они нужны: часть 1
2. Какие есть паттерны в React и для чего они нужны: часть 2

Мы решили сделать небольшой квиз по этим паттернам, чтобы вы могли закрепить новые (или старые) знания. Справитесь?

Определяем цель

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

Некоторые программы помогают развивать существующий бизнес — как это делают банковские сервисы, которые упрощают работу с клиентами. Другие становятся самостоятельными продуктами, например, для обучения, занятий спортом или развлечений.

Кроме того, приложение должно решать реальные проблемы пользователей. Допустим, вы задумали создать программу для фрилансеров. Решили провести исследование, и оно показало, что фрилансеры часто страдают от прокрастинации и ненавидят заниматься выставлением счетов клиентам. Ваша идея и главная фишка — приложение, которое автоматизирует процесс оплаты, контролирует сроки выполнения проектов и помогает планировать рабочее время.

Чтобы убедиться, что идея действительно рабочая, проведите опросы в Telegram-каналах фрилансеров или создайте анкету. Вы можете спросить, какие функции для них наиболее актуальны: автоматический расчет налогов, интеграция с платежными системами или отслеживание времени работы. Это поможет сфокусироваться на действительно важных фичах и отсеять второстепенные.

Выбираем платформу и инструменты

Сегодня на российском рынке доминируют две мобильные операционные системы: Android (около 70% пользователей) и iOS (около 30%). Оптимальным решением будет разработка приложения для обеих платформ, особенно если вы ориентируетесь на крупные города, где доля пользователей iOS существенно выше.

Приложения под Android большинство разработчиков пишет на Kotlin, хотя Java до сих пор остается одним из вариантов из-за обширной базы готовых решений и библиотек. Основной средой выступает Android Studio — в ней есть весь необходимый инструментарий для создания, отладки и тестирования приложений. Современные разработчики активно используют Jetpack Compose для построения пользовательского интерфейса, Room для работы с базами данных, Retrofit для сетевых запросов и Dagger или Hilt для внедрения зависимостей.

В мире iOS основным языком программирования стал Swift — современный и безопасный инструмент для нативных приложений. Разработка ведется в среде Xcode, официальной IDE от Apple. Для построения интерфейсов все чаще используется SwiftUI, для управления данными — Core Data, а для сетевого взаимодействия — фреймворк Alamofire. Работа с асинхронными событиями упрощается с помощью фреймворка Combine.

При ограниченных ресурсах можно рассмотреть кросс-платформенную разработку. Так, Flutter использует язык программирования Dart и позволяет создавать производительные приложения с нативным внешним видом. React Native дает возможность применять веб-технологии для мобильной разработки, а Xamarin ориентирован на разработчиков, привыкших к экосистеме Microsoft и языку C#.

Выбор платформы и инструментов должен основываться на характеристиках вашей ЦА, требованиях к функционалу и имеющихся ресурсах. Учитывайте также, что для разных магазинов приложений (RuStore, App Store, Google Play) могут потребоваться специфические оптимизации и настройки.

Продумываем функционал

При разработке функционала важно следовать концепции MVP (Minimum Viable Product) — минимально жизнеспособного продукта. Это позволит быстрее выйти на рынок, получить обратную связь и итеративно улучшить приложение.

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

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

Важно уделить внимание и техническим аспектам функционала:

• Локальное кэширование данных. Поддерживает работу приложения при слабом интернет-соединении или его отсутствии. Сохраняет каталоги, популярные позиции и историю действий пользователя.
• Офлайн-режим. Определяет набор функций, доступных без подключения к сети. Критически важен для удержания пользователей в зонах с плохим интернетом.
• Система пуш-уведомлений. Информирует пользователей о важных событиях, статусах заказов и специальных предложениях. Повышает вовлеченность и возвращаемость в приложение.
• Многопоточная обработка. Выполняет ресурсоемкие операции в фоновом режиме. Гарантирует отзывчивость интерфейса даже при выполнении сложных задач.
• Оптимизация изображений. Внедряет алгоритмы сжатия для быстрой загрузки визуального контента. Обеспечивает комфортное использование даже при ограниченной скорости соединения.

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

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

Выбор правильной архитектуры — это фундамент, который определяет надежность, масштабируемость и удобство поддержки. Вот основные паттерны для мобильных приложений:

• MVVM — рекомендуемый Google подход с разделением UI и бизнес-логики
• MVI — однонаправленный поток данных, хорошо сочетается с реактивным программированием
• MVP — классическая архитектура. Популярна благодаря простоте реализации
• Clean Architecture — многослойный подход с упором на тестируемость и гибкость
• VIPER (iOS) — расширенный MVC со строгим разделением ответственности

Важное значение имеет также выбор технологий для хранения и передачи данных. Для локальной работы подойдут SQLite + Room, Realm или DataStore; для сетевого взаимодействия на Android чаще всего используют Retrofit + OkHttp, а в реактивных сценариях — Ktor Client.

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

Создаем удобный интерфейс

Интерфейс — это лицо приложения. Даже если у вас отличный функционал, но пользоваться им неудобно, людям будет проще удалить программу и найти что-то другое.

Эффективный UI/UX строится на пяти ключевых принципах:

1. Очевидность (интуитивное понимание интерфейса);
2. Экономия внимания (минимум шагов для достижения цели);
3. Консистентность (единообразие элементов с одинаковой функциональностью);
4. Обратная связь (видимый результат каждого действия);
5. Прощение ошибок (возможность отмены операций).

Современные инструменты значительно ускоряют создание качественных интерфейсов. Дизайнеры используют Figma, Adobe XD и Sketch для прототипирования. Android-разработчики предпочитают Jetpack Compose и Material Design Components. Для iOS актуальны SwiftUI, UIKit и Human Interface Guidelines от Apple.

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

Проводим тестирование

Юзабилити-тесты с фокус-группами, A/B-тестирование элементов и аналитика пользовательского поведения дают объективную картину взаимодействия клиентов с приложением.

Комплексное тестирование включает два основных направления:

1. Автоматизированное тестирование: unit-тесты (JUnit, XCTest) для проверки отдельных компонентов; интеграционные тесты для проверки взаимодействия между модулями; UI-тесты (Espresso, XCUITest) для проверки интерфейса; end-to-end тесты для имитации полного пользовательского сценария.
2. Ручное тестирование: функциональное (соответствие требованиям), тестирование производительности (работа под нагрузкой), юзабилити (оценка удобства), кросс-платформенное тестирование (проверка на разных устройствах) и тестирование подключений (поведение при различном качестве интернет-соединения).

Для этого используют специализированные инструменты: Firebase Test Lab для запуска тестов на множестве устройств, Crashlytics для мониторинга сбоев, Android Profiler и Xcode Instruments для анализа производительности. А Accessibility Scanner помогает адаптировать интерфейс для людей с ограниченными возможностями, расширяя потенциальную аудиторию.

Публикуем приложение

После тестирования и исправления проблем наступает ответственный момент публикации. Каждый магазин приложений имеет свои особенности процесса:

• Google Play: создание аккаунта разработчика ($25 единоразово); подготовка материалов (иконка, скриншоты, видео, описание); загрузка APK/App Bundle; заполнение формы оценки контента; настройка дистрибуции и ценообразования; ожидание проверки (до 2 дней).
• App Store: регистрация в Apple Developer Program ($99/год); создание записи в App Store Connect; подготовка маркетинговых материалов; загрузка сборки из Xcode; заполнение информации о возрастных ограничениях; ожидание рассмотрения (1-7 дней).
• RuStore: бесплатное создание аккаунта; подготовка материалов; загрузка APK; заполнение метаданных; быстрая модерация (до часа).

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

Поддерживаем и обновляем

После выпуска начинается непрерывный процесс поддержки и совершенствования продукта. Разработчики регулярно исправляют найденные ошибки, добавляют новые функции и улучшают работу уже существующих.

Для эффективного мониторинга используют комплексные аналитические инструменты: Firebase Crashlytics для отслеживания сбоев, Firebase Analytics/Google Analytics для анализа пользовательского поведения, RuStore Remote Config — бесплатный аналог Firebase, Mixpanel для углубленного анализа пользовательских путей, AppMetrica от Яндекса как комплексное решение для российского рынка.

Автоматизация процессов разработки критически важна для регулярных релизов. CI/CD-системы (GitHub Actions, GitLab CI, Bitrise, Fastlane) позволяют автоматизировать сборку, тестирование и публикацию обновлений, значительно сокращая время выхода новых версий.

Оптимальная стратегия обновлений включает регулярный график релизов (каждые 2-4 недели) с четким приоритетом задач: критические исправления, новые функции, оптимизация производительности. В тренде современной разработки: персонализация на основе ИИ, многофункциональные суперапп-решения, адаптация под новые форм-факторы устройств и повышенное внимание к приватности данных.

Продвигаем приложение

На рынке огромная конкуренция, и без активного продвижения ваш продукт просто затеряется среди тысяч других программ. Важную роль здесь играет ASO (App Store Optimization) — оптимизация для магазина приложений. В некоторых случаях был зафиксирован рост установок до 70% благодаря сильным ASO-стратегиям.

Для Android-приложений это означает настройку страницы так, чтобы пользователи легко находили ваш продукт. Здесь важно правильно подобрать ключевые слова для описания, создать привлекательную иконку и подготовить качественные скриншоты. Чтобы понять, какое оформление работает лучше, разработчики всё чаще используют A/B-тесты — такая возможность есть, например, в RuStore. Она позволяет сравнить разные версии карточки приложения и выбрать ту, которая эффективнее привлекает пользователей.

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

Еще один инструмент для продвижения приложений — социальные сети. Здесь можно показывать функционал программы, общаться с пользователями, отвечать на их вопросы и рассказывать о новых опциях. Это помогает создать активное сообщество вокруг продукта. Так, к примеру, В 2023 году компания Geozilla, разработчик приложения для отслеживания местоположения близких, провела кампанию по продвижению с инфлюенсерами в социальных сетях. В рамках сотрудничества удалось собрать более 1 миллиона просмотров, а коэффициент конверсии из кликов в установки приложения составил 24%.

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

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

Подводим итоги

Создание успешного приложения начинается с четкого определения цели и понимания потребностей пользователей. Затем нужно выбрать подходящие технологии, продумать необходимые функции, спланировать архитектуру и разработать понятный интерфейс. Обязательно проведите тщательное тестирование перед запуском. После публикации важно регулярно обновлять приложение на основе отзывов пользователей и данных аналитики, а также активно продвигать его в магазинах приложений и социальных сетях.

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

iOS или Android? React Native или Flutter? Собираем все новости и гайды по мобильной разработке тут.

Ниже — оставшиеся три паттерна, которые мы не разобрали в прошлой статье.

Хуки и кастомные хуки

Мы уже несколько раз упоминали хуки (Hooks) — пора поговорить о них как о новом паттерне, фактически пришедшем на смену многим предыдущим. Хуки появились в React 16.8 и моментально изменили стиль написания компонентов. Теперь вместо классов с методами жизненного цикла у нас функциональные компоненты, которые используют состояния (useState), эффекты (useEffect) и другие возможности прямо внутри функции. А главное — мы можем писать свои собственные, пользовательские хуки (custom hooks) для повторного использования логики.

Почему же хуки так популярны? Они дают возможность переиспользовать состояние и побочные эффекты, не меняя структуру самих компонентов. Раньше, чтобы два компонента разделяли какую-то логику, приходилось применять HOC или Render Props — то есть вводить дополнительный компонент-обёртку или коллбэк. Теперь же мы можем вынести логику в custom hook useSomething() и вызвать его в нужных нам компонентах или других кастомных хуках. Получается, что хуки позволяют писать более прямолинейный, читаемый код: вместо закулисной магии HOC мы явно вызываем необходимые нам хуки и получаем данные.

Custom hook — это просто функция, название которой по соглашению начинается с use (чтобы линтер React знал, что внутри неё могут быть хуки). Например, давайте перепишем наш HOC withCounter из предыдущего примера как кастомный хук:

Получилось то же самое поведение (счётчик кликов), но без обёрток. Компонент ClickButton сам вызывает useCounter() и получает count и increment. Внутри useCounter может быть любая другая сложная логика, побочные эффекты, вызовы других хуков — компонент, использующий наш хук, об этом не знает и не должен знать. Зато код компонента предельно ясный: он просто берёт нужные ему данные из хука и использует их.

Повторное использование логики — главное преимущество кастомных хуков. Вы можете написать, например, хук useFetch(url) (достаточно распространённое решение), который будет обращаться к API и возвращать состояние загрузки, успеха запроса, данные и ошибки. Далее можно применять этот хук в разных компонентах, страницах, не дублируя сам код запроса.

Кроме того, хуки отлично работают друг с другом. Вы можете внутри одного хука вызвать другой (например, использовать useContext или useReducer внутри своего useAuth хука). Это помогает облегчить написание сложных функциональностей, так как мы используем небольшие хуки, выполняющие простые задачи, из которых как конструктор составляем более сложное поведение.

Плюсы: ясность и лаконичность. Мы не оборачиваем компонент, использующий хук, ни в какие лишние слои, его JSX не замусорен вспомогательными функциями или компонентами, он просто вызывает хук и получает результаты. HOC и Render Props во многом ушли в прошлое из-за того, что хуки решают те же проблемы более естественным для JavaScript способом. Кастомные хуки легко тестировать (это по сути просто функции). Хуки позволяют разделять логику внутри одного компонента на независимые части: например, компонент может использовать одновременно и свой локальный useState, и несколько разных кастомных хуков — каждая часть отвечает за себя, и этот код не переплетается, тогда как при использовании нескольких HOC или Render Props было бы труднее изолировать ответственности.

Минусы: если это можно назвать минусом. Хотя хуки упростили многое, они принесли также свои правила, о которых нужно помнить: вызывать в одном порядке, только в компонентах либо других хуках, не внутри условий. Если нарушить эти правила, React выдаст предупреждение или ошибку. Ещё потенциальный минус: повторное использование хука означает, что каждый компонент получает свою копию состояния. Это обычно то, что нам нужно, но если вдруг требуется разделять одно состояние между несколькими компонентами — хуки напрямую не помогут, придётся выносить состояние выше (или в контекст, или в стор). Впрочем, это уже другая задача.

В целом, сейчас хуки — основной инструмент в React, используемый разработчиками. Большинство новых API, фреймворков, библиотек строятся вокруг хуков. Поэтому если вы видите библиотеку, написанную на HOC либо Render Props, то, скорее всего, у неё уже есть или появится версия на хуках. Хуки сделали код React компонентов более понятным и свели на нет необходимость в классах (почти все новые фичи React рассчитаны только на функциональные компоненты).

Compound Components (Составные компоненты)

Паттерны, о которых говорилось выше, касаются того, как компоненты делятся логикой или данными. А есть подход, делающий фокус на композиции компонентов, позволяя создавать гибкие интерфейсы. Compound Components — это паттерн, при котором несколько компонентов работают вместе как единое целое, обмениваясь общим состоянием (обычно через контекст). Пользователь такого комплекта компонентов может гибко комбинировать его части в JS.

Я познакомился с данным паттерном, когда писал в качестве пет-проекта свой собственный UI Kit. Представьте <Accordion> с множеством <AccordionItem> или <Select> и <Option>. Compound Components — когда мы пишем код таким образом, что компонент <Accordion> не обязан принимать массив пунктов через пропсы и рендерить его внутри. Мы даём разработчику возможность самому в JSX расписать, какие пункты будут у аккордеона и что в них будет находиться, используя заранее предусмотренные дочерние компоненты: <Accordion.Item>, <Accordion.Header> и <Accordion.Panel>.

Возможно, у вас, как и у меня, сразу же возник вопрос в голове: «как же Accordion узнает о своих Item и организует их работу?» Внутри — как раз при помощи React Context. Compound Components обычно реализуются так: родитель (компонент-контейнер) содержит всё состояние (например, какой пункт раскрыт) и методы управления (функция toggle(index)). Он оборачивает children своим контекст провайдером и передаёт туда эти данные и функции. Дочерние компоненты (которые рендерятся где-то внутри children) просто берут нужное из контекста и таким образом получают доступ к состоянию родителя. Они знают, к какому именно контейнеру принадлежат, благодаря тому, что рендерятся внутри него и получают его контекст.

Давайте рассмотрим конкретный пример. Сделаем простой составной компонент Toggle, который будет управлять отображением/скрытием некоторого контента по клику. У нас будет <Toggle> в роли контейнера и его дочерние компоненты <Toggle.On>, <Toggle.Off> и <Toggle.Button>.

Здесь <Toggle> управляет состоянием on (показано/скрыто) и предоставляет через контекст значение { on, toggle } всем потомкам. <ToggleOn> и <ToggleOff> читают on и в зависимости от него либо рендерят children, либо нет. <ToggleButton> получает из контекста функцию toggle и вызывает её при клике. В итоге снаружи мы получаем удобный и декларативный интерфейс: внутрь <Toggle> мы помещаем разные части UI, которые сами знают, когда им отображаться и что делать при клике — мы лишь описываем структуру, не связывая их вручную пропсами.

Обратите внимание: компоненту <Toggle> без разницы, сколько у него внутри <ToggleOn> или <ToggleOff> и какой внутри них JSX. Всё завязано только на состоянии контекста. Это и есть сила композиции: пользователю библиотеки даются «кирпичики» (несколько компонентов), из которых он может сложить нужную конструкцию как ему необходимо, а не один монолитный компонент с десятком пропсов настроек.

Плюсы этого паттерна: огромная гибкость и выразительность. Хороший compound-компонент ощущается как маленький фреймворк. Например, библиотека @reach/ui (предшественник современной radix-ui) много компонентов строила через этот паттерн: диалоги, списки, выпадающие меню . Пользователю легко понять API — просто вкладывай одни компоненты в другие. Появляется возможность тонко настроить итоговую разметку, вставить дополнительные элементы если надо, ведь внутри children мы не ограничены, можем обернуть тот же <ToggleButton> в какой-нибудь <div> с нужным классом. Проще поддерживать визуальное единообразие: все части контролируются одним контекстом, не размазывая логику по нескольким несвязанным компонентам.

Минусы: сложнее реализовать. Необходимо аккуратно продумать как компоненты будут взаимодействовать, предусмотреть, что некоторые могут отсутствовать или повторяться. Если неправильно спроектировать составной компонент, можно столкнуться с багами: например, если <ToggleButton> случайно использовать вне <Toggle> (то есть вне своего провайдера), useContext вернёт undefined и будет ошибка — надо либо избегать такого, либо делать проверки и бросать понятное сообщение об ошибке (мол, «ToggleButton ОБЯЗАТЕЛЬНО должен быть потомком Toggle»).

Ещё один момент связан с производительностью, когда контекстное значение меняется, все потребители контекста перерендерятся. Например, при каждом клике toggle выше перемонтируются и <ToggleOn>, и <ToggleOff>, и <ToggleButton>. В нашем случае это конечно пустяки, но если бы у нас был десяток сложных для ререндера children'ов, подписанных на контекст, и состояние менялось часто, нужно было бы подумать об оптимизации (разбивке контекстов или мемоизации).

Тем не менее плюсы обычно перевешивают: паттерн Compound Components позволяет создать очень понятный и гибкий пользовательский API для ваших компонентов. Это проявление философии React — композиция важнее наследования. Вместо того чтобы делать сложный компонент с кучей условий, мы делаем набор простых компонентов, которые в комбинации собираются в сложное поведение.

Compound Components — довольно «профессиональный» паттерн. В небольших приложениях вы можете не столкнуться с необходимостью его реализовывать, но если разрабатываете библиотеку компонентов, как я в своём пет-проекте, или сложный виджет, такой подход — чуть ли не необходимость. Практически все продвинутые React UI-библиотеки (Material UI, Chakra, Radix и т.д.) используют контекст и композицию под капотом для своих сложных компонентов.

Серверные компоненты и Suspense: современные возможности React

Наконец, давайте поговорим о новейших возможностях, которые принесли нам 18 и 19 версии React’а. Они направлены на улучшение работы с асинхронностью, данными и рендерингом на стороне сервера. В первую очередь, React Suspense и Server Components. Эти вещи ещё не до конца устоялись в среде разработчиков, но их стоит держать в уме.

Suspense — ожидание с комфортом

Когда интерфейсу нужно загрузить данные, всегда возникает задача — показать индикатор загрузки, пока всё не готово. Раньше приходилось вручную писать логику, часто это бывало состояние isLoading и условный рендер либо спиннера, либо контента. С появлением React Suspense командой React был предложен более декларативный способ. Suspense — это специальный компонент, который позволяет нам приостановить рендеринг своих дочерних компонентов, пока те не готовы, и в это время показать fallback UI.

Проще говоря, мы оборачиваем часть дерева компонентов в <Suspense fallback={<Loader/>}> ... </Suspense>, и если внутри этой области происходит задержка (например, идёт загрузка кода или данных), React сам автоматически покажет <Loader> вместо содержимого, а когда всё завершится — отобразит наши компоненты. Suspense берёт на себя координацию этого процесса, освобождая нас от ручного управления состоянием загрузки.

Сегодня Suspense широко используется для ленивой загрузки компонентов (React.lazy + <Suspense>). Например:

Здесь компонент Comments будет подгружён по требованию (и в отдельном бандле). Пока бандл не загрузится, пользователь увидит текст-заглушку «Комментарии загружаются...». Как только код придет, React отрисует <Comments>. Всё это без какого-либо специального кода внутри ArticlePage для отслеживания загрузки. Suspense сам разрулит ситуацию — React.lazy под капотом бросает Promise на время загрузки, а <Suspense> ловит его и показывает фоллбэк.

Кроме ленивой загрузки кода, Suspense постепенно начинает применяться и для асинхронных данных. В React 18 появился экспериментальный API, позволяющий Suspense работать с данными, например, можно использовать специальный use для ожидания промиса прямо внутри компонента (пока официально не стабильно, но фреймворки типа Next.js 13 уже вовсю используют это). Идея та же: компонент, который загружает данные, вместо того чтобы сразу вернуть JSX, может приостановить своё выполнение до получения данных. React, обнаружив это, покажет fallback, а когда данные придут — продолжит рендер компонента. Таким образом, можно писать компонент, который выглядит синхронным, хотя внутри у него асинхронный код — за счёт Suspense'а пользователю не покажется незавершённый результат.

Признаться, Suspense для работы с данными — пока штука из области экспериментов. Если вы пишете обычное приложение на Vite или CRA без Next, то прямо сейчас использовать Suspense для загрузки данных «из коробки» не выйдет — потребуется либо сторонняя библиотека (например, React Query пока не интегрирован с Suspense по умолчанию, но планирует), либо фреймворк. Однако направление понятное: React движется к тому, чтобы сделать работу с асинхронностью более декларативной. Уже сейчас вы можете использовать Suspense для спиннеров и заглушек при загрузке кода, а в ближайшем будущем, вероятно, подобный подход станет нормой и для данных (в React 19+ должны появиться официальные инструменты для этого).

Подводя итог по Suspense: этот паттерн позволяет очень аккуратно организовать отображение состояния загрузки. Вместо большого количества условных isLoading ? <Spinner> : <Content> мы просто заявляем: «Эта часть UI может задержаться, показывай пока вот это». Это улучшает UX (пользователь видит скелетон или лоадер без моргания незагруженного контента) и упрощает код. Обязательно следим за развитием Suspense — возможно, скоро он будет использоваться намного чаще, чем сейчас.

Серверные компоненты — React выходит на сервер

Ещё одна революционная идея команды React — React Server Components (RSC), или серверные компоненты. Это попытка объединить лучшее из мира серверного рендеринга и клиентских SPA. Смысл в том, что если часть ваших React-компонентов может выполняться только на сервере, генерируя готовый HTML, который отправляется клиенту, то пусть они и исполняются на сервере, не загружая клиент. Эти компоненты никогда не попадают в бандл JS, не несут в себе интерактива — они чисто для рендеринга контента. Другая часть компонентов всё также остаётся клиентской, это давно знакомые нам React-компоненты, которые умеют обрабатывать события, имеют какое-то своё состояние и т.д. Разделение происходит явно: React различает, какой компонент предназначен для сервера, а какой — для клиента.

Как же React понимает, в какой среде выполнять код компонента? Введена директива "use client": если файл компонента начинается с этой строки, то компонент клиентский, он будет собран в JS и выполнится в браузере. Если же такой строчки нет — компонент считается серверным и по умолчанию выполнится на сервере (например, при рендеринге страницы на Node.js). Серверный компонент может содержать асинхронный код (запросы к БД, файловой системе и т.п.), ведь он запускается в среде сервера. Но он не может использовать, например, useState или useEffect, ведь у него нет постоянного состояния между запросами, да и доступ к DOM он не имеет.

React 18 (и в полной мере React 19) позволяет фреймворкам использовать эту возможность. Например, Next.js 13 с новым app/ роутером делает все компоненты по умолчанию серверными, если не указать "use client". Таким образом, большую часть страницы вы можете рендерить на сервере, отдавая сразу на клиент сразу готовую разметку, а для интерактивных элементов использовать клиентские компоненты.

Преимущества Server Components:

• Производительность. Серверные компоненты избегают гидрации, клиенту не нужно повторно исполнять JS, чтобы восстановить состояние UI. Вы получаете выгоды SSR (быстрый первый рендер, минимум работы на клиенте) без обычных недостатков SSR (необходимость гидрации большого объёма HTML).
• Безопасность. Чувствительный код остается на сервере, не попадает в бандл, и данные можно получать напрямую на сервере (например, напрямую из базы) без передачи ключей API в браузере.
• Размер бандла существенно сокращается, ведь клиент вообще не получает код серверных компонентов, только итоговую HTML разметку и нужный JS для оставшихся клиентских компонентов.

Как это выглядит на практике? Самый понятный пример:

Представим блог. Страницу поста можно сделать целиком серверным компонентом, на сервере загрузится пост из БД и вернёт нам готовую верстку статьи. А вот кнопка лайка или форма добавления комментария — это уже интерактив, их делаем клиентскими компонентами. В результате пользователь, заходя на страницу, сразу же получит полностью готовую страницу поста (никакого лоадера, всё пререндерено). А JS-код загрузится для кнопки лайка и формы комментария, и только они будут гидрироваться и начнут работать на клиенте. Это сочетание SSR и SPA, orchestrated by React.

React строго определяет, как серверные и клиентские компоненты могут взаимодействовать. Серверный компонент может импортировать и использовать другой серверный или клиентский компонент, а вот клиентский компонент не может импортировать серверный. То есть дерево может быть: Серверный → внутри него Клиентский → внутри него ещё Клиентский и т.д. Но не наоборот. В примере выше серверный компонент страницы может рендерить внутри себя <LikeButton /> (клиентский компонент кнопки). А если бы вы попробовали внутри клиентского компонента сделать import PostDetails from './PostDetails.server.jsx' — сборка не позволит, скажет, что так нельзя. Таким образом, архитектура разделяется: «верхние» уровни страницы — серверные, «листья» интерактивности — клиентские.

Server Components — пока прерогатива фреймворков. То есть в обычном приложении вы не сможете воспользоваться этим вручную без большого труда. Но если вы работаете с Next.js, Remix или в целом с fullstack React-приложениями, то RSC уже доступны. В React 19 они обещают быть полностью стабильными (в React 18 это скорее эксперимент для энтузиастов). Библиотеки тоже начинают подстраиваться: например, React Router v7 планирует поддерживать RSC, Vite тоже экспериментирует с этим.

Что в итоге нам дают серверные компоненты? Потенциально — большой скачок в производительности и удобстве разработки fullstack приложений. Мы получаем паттерн разделения по среде: какие компоненты должны рендериться на сервере, а какие — на клиенте. Это новое измерение при проектировании React приложения. Разработчику теперь нужно будет думать не только о разделении логики и UI, или о переиспользовании кода, но и решать, где лучше его выполнить — на сервере или в браузере. Правильное использование RSC может значительно ускорить приложение без лишних усилий для разработчика (React сам решит, когда и что подгружать, синхронизирует состояние между сервером и клиентом).

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

Заключение

Мы рассмотрели ключевые паттерны React и даже заглянули в будущее React-архитектур.

• Container & Presentational Components привносят порядок, отделяя логику от отображения.
• HOC и Render Props — старые приёмы для переиспользования кода, которые в значительной мере вытеснены более современными хуками, но по прежнему встречаются в проектах.
• Compound Components демонстрируют силу композиции, предоставляя API для гибкой сборки компонентов из небольших частей.
• А Suspense и Server Components — это уже ближайшее будущее, делающее работу с асинхронностью и рендерингом более эффективной и декларативной.

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

От себя добавлю: изучая паттерны, всегда пробуйте их в деле. Напишите свой HOC, переделайте компонент с Render Props на хук, реализуйте небольшой набор Compound Components — так вы прочувствуете их сильные и слабые стороны. React развивается, и появляются новые приёмы, но фундаментальные идеи (композиция, разделение обязанностей, явное управление состоянием) остаются. Владейте этими инструментами, и ваши React приложения будут благодарить вас чистотой и поддерживаемостью кода!

Паттерны в React нужно не только знать, но и применять. Собрали полезные инструменты здесь.