Хайп-цикл фронтенда, кажется, наконец-то выдохся. Мы вышли из фазы бесконечного переизобретения колеса, где каждый месяц появлялся «убийца React», и вошли в эпоху убийцы Fable инженерной зрелости. Сегодня опытного инженера сложно впечатлить очередным фреймворком: ценность сместилась в сторону предсказуемости, скорости поставки (delivery) и снижения когнитивной нагрузки.

Привет, меня зовут Паша Востриков, и я — архитектор веб-направления в «Лаборатории Касперского». В этой статье хочу разобрать взгляд сообщества на JS-экосистему сезона весна-лето 2026 года.

На HolyJS Spring 2026 мы предложили 120+ инженерам описать свой реальный стек. Получившийся радар мог быть просто списком библиотек, но в итоге вышел срезом того, как выглядит рациональный подход к коду в 2026 году. Мы видим, как разработчики массово идут в сторону предсказуемой скорости масштабирования решений и инженерной гигиены.

Кстати, сам радар можно посмотреть здесь. Сравните его со своим стеком и отметьте технологии, которые используете сами. Чем больше ответов, тем интереснее будет смотреть, куда движется сообщество.

Как устроен радар

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

Каждую технологию участники оценивали по одной из четырех категорий. Adopt означает «используем и считаем надежным рабочим выбором». Trial — «готовы брать в реальные задачи, но пока с оглядкой». Assess ставили технологиям, которые интересно изучать и за которыми стоит следить. Hold — «сейчас не советуем внедрять или развивать без веской причины».

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

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

А теперь к тому, что мы увидели.

Базовый стек умещается в несколько строк

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

В зоне Adopt прочно закрепились TypeScript, Git, pnpm, Code Review, CI/CD, Vite и Unit-тесты. Эти технологии построены вокруг двух важных аспектов: паттернов и инфраструктуры. Именно они позволяют не умереть при поддержке прода.

Мы проанализировали ответы и увидели закономерность: команды, которые выходят за рамки этого «базового набора» без острой бизнес-необходимости, тратят до 30% своего времени на «поддержание жизни» тулчейна. Выбирая, например, pnpm или Vite как стандарт, команда покупает себе предсказуемость.

Аналитика для команд

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

TypeScript: от выбора синтаксиса к стандарту эксплуатации

Дискуссия «JS против TS» в 2026 году выглядит примерно как спор о пользе электричества. TypeScript давно перестал быть способом получить подсказки в IDE. Сегодня это производственная необходимость и фундамент contract-first проектирования.

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

Если вы до сих пор решаете, нужен ли TS, то уже проигрываете гонку за единообразие экосистемы. TypeScript в 2026 году выбирают ради эксплуатационной безопасности.

Архитектурные парадоксы: где сообщество не может договориться

Интереснее всего рассматривать технологии, где голоса Adopt (активное использование) и Hold (решение избегать / не развивать) разделились почти поровну. Здесь кроется ответ на вопрос, как современные инженеры оценивают риски.

FSD: 46 Adopt против 57 Hold

Feature-Sliced Design — хороший пример технологии, про которую сложно сказать просто «берите» или «не берите». Сторонникам FSD нравится предсказуемая структура. Когда проект становится большим, правила расположения кода действительно начинают экономить время: разработчику не приходится каждый раз заново разбираться, куда положили бизнес-логику, где искать модель и как устроены зависимости.

Но за эту предсказуемость приходится платить дополнительными правилами. Для большого продукта с длинным жизненным циклом такая цена может быть оправдана. Для MVP или небольшой команды тот же подход способен превратиться в архитектуру ради архитектуры.

В цифрах раскол выглядит так: 46 голосов за Adopt против 57 за Hold. Сторонники ценят строгость структуры, которая позволяет масштабировать проект на сотни разработчиков без превращения кода в... ну, вы сами знаете во что. Противники говорят про избыточную сложность для небольших и средних продуктов.

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

Микрофронтенды: после хайпа пришли счета

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

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

Радар показывает растущий скепсис и высокий Hold. Сообщество наелось микрофронтендами в 2023–2024 годах, и сейчас заметен откат к модульным монолитам. Микрофронтенды выглядят как архитектурный налог: без десятка независимых команд, которым нужно деплоиться без оглядки друг на друга, вы получите проблемы с оркестрацией, версионностью библиотек и производительностью, но почти ничего не выиграете.

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

CSS-in-JS: браузер постепенно забирает работу обратно

Еще один заметный сдвиг связан с отношением к CSS-in-JS. Styled-components и Emotion не стали плохими инструментами, просто сместилась исходная точка отсчета.

За последние годы браузер получил огромное количество возможностей, ради которых раньше приходилось подключать отдельные библиотеки: <dialog>, popover, container queries, CSS-переменные, новые способы позиционирования. На этом фоне все сложнее объяснить, зачем отправлять пользователю дополнительный JavaScript, если задачу уже умеет решать сама платформа.

Отсюда закономерный интерес к zero-runtime-подходам и обычному CSS. Позволю себе немного самоиронии: CSS Modules вместе с CSS-переменными внезапно оказались тем самым old but gold. Мы и сами постепенно выпиливаем остатки CSS-in-JS из прода. Иногда инженерный прогресс выглядит как удаление технологии.

Весом бандла инженерное сообщество в 2026 году буквально одержимо. На радаре это выражается в массовом отказе от тяжелых рантайм-библиотек в пользу zero-runtime и нативных возможностей платформы. Мотивация простая: чем меньше JS уезжает в браузер, тем выше производительность.

AI-Driven-разработка: от второго пилота к аудитору

Данные State of JS и State of CSS за 2025–2026 годы показывают, как ИИ меняет повседневность. Но роль ИИ сильно зависит от масштаба задачи, и сводить все к формуле «теперь нейросеть пишет код за разработчика» я бы не стал.

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

В больших системах ситуация другая. Там проблема обычно не в том, что некому написать еще одну функцию: кода и так достаточно. Гораздо интереснее использовать AI для анализа уже существующей системы: искать отклонения от архитектурных правил, разбираться в legacy, находить подозрительные участки репозитория, готовить контекст для код-ревью, объяснять зависимости, помогать при больших рефакторингах. В этом сценарии AI работает как очень быстрый технический аудитор.

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

Что требуется большим проектам, а что — маленьким

По итогам радара и трендов последних двух лет вырисовываются два пути.

Маленьким и продуктовым проектам нужна скорость. Нативные браузерные API убивают целые классы библиотек, индустрия возвращается к формуле «меньше JS, выше производительность», тяжелые рантаймы CSS-in-JS уступают zero-runtime и нативной кастомизации. Философия здесь простая: чем меньше кода уезжает клиенту, тем лучше. Vite, TypeScript и минимальная база закрывают почти все, усложнять не стоит.

Большим системам нужны стандарты. Единообразие оказывается важнее крутых фич, а инвестиции идут в монорепозитории, строгие линтеры и контрактное проектирование через OpenAPI и общие типы. Стоимость сопровождения системы превышает стоимость ее написания примерно в десять раз, поэтому за строгость архитектуры имеет смысл платить. Ставка здесь на стандартизацию: общие типы, жесткие контракты API, ИИ-ассистенты на ревью.

На первый взгляд требования выглядят противоположными. Маленькому продукту не хочется неделями проектировать идеальную архитектуру перед первым релизом: взяли TypeScript, Vite, понятный набор библиотек, используем возможности браузера и двигаемся. Большому проекту нужны общие типы, контракты, правила зависимостей, единый тулчейн, автоматические проверки.

Oh wait.. получается, что для больших и маленьких проектов один путь, ведущий к быстрому старту и надёжному масштабированию. Так вот он какой, главный инсайт от HolyJS Spring 2026. Мы не играем в выбор технологий, мы внимательно выбираем куда бежать. При ассистировании AI. Мы ассистируем AI..

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

Вместо итога

JS-разработка проще не стала. Браузер, приложения, инфраструктура стали сложнее, а требования пользователей выше. К этому добавились SSR, edge, несколько вариантов рендеринга, огромные дизайн-системы, распределенные команды и теперь еще AI.

Хорошая новость в том, что мы постепенно перестаем отвечать на эту сложность еще большей сложностью. Новый фреймворк уже не выигрывает у старого автоматически. Микрофронтенды не выигрывают у монолита. Абстракция не становится хорошей от того, что она красивая, а библиотека вполне может проиграть API, который уже есть в браузере. Это я и назвал бы инженерной зрелостью JS-экосистемы в 2026 году.

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

Посмотреть JS Tech Radar и сравнить его со своим стеком