О Себе

Занимаюсь разработкой уже более 10 лет. За это время побывал на разных позициях начиная от рядового разработчика до руководителя Frontend департамента.

До этого несколько лет в финтехе: проекты для Visa, p2p exchanger, Europe banking, crypto exchanges. Там углублялся в требования к скорости feature delivery и надёжности и именно оттуда пришло понимание, насколько критичен DX при высокой скорости разработки.

Также были кейсы другого масштаба где была платформа на базе Module Federation, которую строили с нуля. За два года команда выросла до 70+ фронтенд-разработчиков, развернули более 15 микрофронтов, каждый со своим бэкендом. Руководил core-командой, которая занималась в первую очередь ускорением разработки — инфраструктурой, инструментами, DX.

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

Введение

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

• Сделать разработку комфортнее и избавить инженеров от ежедневных раздражителей, замедляющих работу.

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

• Уменьшить количество галюцинаций AI агентов/промптов

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

Последние несколько лет вся индустрия обсуждает AI. Copilot, ChatGPT, генерация кода — об этом пишут на каждой конференции. Но если честно посмотреть на повседневную работу большинства команд, bottleneck находится совсем в другом месте.

Разработчики и агенты по-прежнему:

• Ждут окончания сборки

• Ждут завершения линтера

• Ждут проверки типов

• Ждут исправления рассинхрона между фронтом и бэкендом

И при этом продолжают работать с инструментами, которые были актуальны 5–10 лет назад: Webpack, Babel, ESLint, ручные API-клиенты, useMemo/useCallback/memo в каждом втором компоненте.

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

В этой статье разберу пять направлений, в которых мы получили измеримый эффект:

1. Type checking — TSCheck vs TSGO

2. Linting — ESLint vs Biome vs Oxlint

3. Bundling — Webpack → Vite → Rsbuild

4. API-контракты — автогенерация кода из swagger.json

5. React — React Compiler в production

1. Typescript: TSCheck vs TSGO

TypeScript стал жертвой собственного успеха

Когда проект маленький, tsc --noEmit отрабатывает мгновенно. Ты не думаешь о производительности компилятора — он просто работает.

Но со временем кодовая база растёт. Появляются десятки тысяч файлов, тысячи типов, сложные generic-конструкции, монорепозиторий. И в какой-то момент:

• IDE начинает заметно тормозить

• CI тратит минуты на type checking

• Разработчики переключаются на другую задачу, пока ждут результата проверки

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

Что такое TSGO

TSGO — это инициатива Microsoft по переписыванию TypeScript-инфраструктуры на Go. Цель — радикальное ускорение проверки типов, компиляции и работы Language Server при сохранении полной совместимости с существующей семантикой.

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

Что мы сравнивали

Мы прогнали оба инструмента на нашей production-кодовой базе и замерили несколько ключевых метрик:

Результаты и выводы

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

Важно отметить: TSGO как раз обновился до Release candidate. Теоретически могут быть проблемы совместимости, edge cases, не покрытые новой реализацией. Но в нашем случае — на production-кодовой базе — проблем мы не обнаружили. Работает стабильно.

Мы используем TSGO в связке с Oxlint — оба инструмента работают и в IDE, и на уровне CI. Вместе они дали огромное порядковое ускорение проверки кода, которое чувствуется в ежедневной работе каждого разработчика, но об этом чуть попозже :)

Направление абсолютно очевидно: компиляторная инфраструктура постепенно уходит от JavaScript-реализаций к Go и Rust. И это логично — когда инструментом пользуются миллионы разработчиков, каждая миллисекунда в компиляторе умножается на миллионы.

2. Linter: ESLint vs Biome vs Oxlint

Мы не просто "оценивали" разные линтеры в песочнице. Мы прошли через каждый из них в production – с реальной кодовой базой, реальной командой и реальными проблемами.

Есть ирония в том, что на многих проектах сборка уже работает быстрее, чем линтер. Вы оптимизируете бандлер, переходите на Vite или Rsbuild – и вдруг обнаруживаете, что ESLint стал самым медленным звеном в вашем CI.

Этап 1. ESLint

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

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

Именно долгий CI и время линтинга стали причиной, по которой мы начали искать альтернативу.

Этап 2. Biome

Biome позиционируется как всё-в-одном: линтер + форматтер, написанный на Rust. На бумаге звучит идеально. И по скорости на CI он действительно быстрее ESLint и Oxlint. Но в реальной эксплуатации мы столкнулись с проблемами, из-за которых пришлось уходить дальше:

• Процесс Biome часто крашил IDE. Это не теоретическая проблема — разработчики регулярно сталкивались с зависанием процесса Biome в VS Code. Приходилось перезапускать, терять контекст, ждать. Когда инструмент, который должен ускорять работу, блокирует её — это сводит на нет весь выигрыш в производительности.

• Многие правила недоступны. Часть правил, которые мы активно используем в проекте, в Biome просто отсутствует. Мигрировать с ESLint и при этом потерять часть проверок — неприемлемый компромисс для production-команды.

Этап 3. Oxlint

И вот мы пришли к Oxlint — и остались, аналогичное Biome решение линтер + форматер. На мой взгляд, это сейчас наиболее интересный и практичный вариант.

Почему:

• Экстремальная скорость. Oxlint написан на Rust и работает настолько быстро, что линтинг перестаёт быть заметным этапом в рабочем процессе. На нашей кодовой базе разница с ESLint — в десятки раз.

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

• Стабильность. Никаких крашей в IDE, никаких утечек памяти на больших проектах. Простая и стабильная работа.

Мы используем Oxlint в связке с TSGO — оба инструмента настроены и в IDE, и на CI уровне. Вместе они покрывают type checking и linting за время, которое раньше уходило только на один ESLint.

Benchmark:

Вывод

Если ваш приоритет — максимальный Developer Experience без компромиссов, Oxlint на сегодняшний день выглядит как наиболее практичный выбор. Быстрее всех, покрывает все правила, не зависает. Сложно просить больше от линтера.

3. Bundling: Webpack vs Vite vs Rsbuild

Bundler это не просто инструмент сборки, это основа движка CI/CD вашего проекта. Мы прошли через три этапа, и каждый из них дал ощутимый прирост. Но финальный шаг изменил ощущения от разработки радикально. В итоге многие разработчики из команды приходили в восторг от осознания что всего лишь 1 изменение может так сильно ускорить и упростить их работу. Ну что поехали?)

Этап 1. Webpack

Наш проект начинался на Webpack. Стандартный выбор для своего времени, ничего необычного.

Без оптимизаций hot reload занимал ~40 секунд. Сорок секунд ожидания после каждого изменения в коде. Работать в таком режиме было мучительно.

Мы потратили значительное время на оптимизацию: babel, tsc, выбор между swc/esbuild, настройка css/scss/less loader-ов настройка кеширования, ограничение scope, точечный тюнинг лоадеров и плагинов. После всех усилий удалось снизить время до ~10 секунд.

10 секунд — терпимо, но:

• Конфигурация стала сложной и многоуровневой

• Стоимость поддержки этой конфигурации была высокой как и вероятность совершить ошибку

• Новые разработчики тратили время на понимание сборки вместо бизнес-логики

Этап 2. Vite

Далее мы решили опробовать Vite. Конфигурация стала проще на порядок. Скорость в dev-режиме выросла за счёт поддержки ESM и esbuild из коробки. Разработчки тоже были рады что конфиг стал сильно компанее. Но в момент тестирования перехода мы столкнулись с критически важными ограничениями сборщика. На нашем крупном проекте с Module Federation Vite показал себя не с лучше стороны и имел ряд недоработок при работе с MF. Это было критичной проблемы для нашего проекта и привело к пониманию, что это не финальная точка.

Причины отказа перехода на Vite:

1. Разработчик запускает Host App
   - Не поддерживал загрузка модулей через dynamic remotes при получение их с бекенда а не сборке внутри конфига
   - Невозможность обработки исключений падения shared модуля приводящие к краху всего Host приложения

2. Разработчик запускает Remote App
   - Vite не сообщает Host приложению об изменении своего кода, что приводит к невозможности использования Hot Reload shared module-я в Host приложении

Этап 3. Rsbuild

И вот мы решили мигрировать на Rsbuild. Благо Rsbuild отлично умеет работать с Module Federation. Результат — около 1 секунды для hot reload. На проекте, где работают 40+ разработчиков, с Module Federation, с большим количеством страниц и сложной архитектурой.

Ощущения разработчиков изменились качественно. Когда feedback loop настолько короткий, ты перестаёшь его замечать. Изменил код — результат уже на экране. Процесс разработки из "написал → подождал → посмотрел" превращается в непрерывный поток.

Почему Rsbuild настолько быстрый:

Rsbuild построен на [Rspack](https://rspack.dev/) — бандлере, написанном на Rust командой, которая также стоит за Module Federation. Это не случайное совпадение — те же люди, которые придумали архитектуру микрофронтов, создали бандлер, который наилучшим образом её поддерживает. Ключевые особенности:

• Rust-производительность. Парсинг, трансформация и бандлинг выполняются на скомпилированном языке, а не в JavaScript runtime.

• Совместимость с Webpack API. Rspack поддерживает большую часть Webpack-экосистемы: лоадеры, плагины, конфигурацию. Это критически важно для миграции — не нужно переписывать весь build pipeline с нуля.

• Минимальная стоимость миграции. Именно совместимость с Webpack API сделала переход реалистичным на проекте нашего масштаба. Мы не могли позволить себе остановить разработку на недели ради миграции бандлера.

• Сокращение размера бандла. Rsbuild помог не только со скоростью сборки, но и с размером output — мы сократили размер бандла более чем в 5 раз благодаря более умному tree-shaking и code splitting.

• Отличная поддержка Module Federation. Все наши проблемы которые мы получали с Vite спокойно решались 1 к 1б также как и при использовании Webpack.

Benchmark:

Важно: все замеры проводились на Rsbuild 1.x. С выходом Rspack 2.0 и Rsbuild 2.0 производительность стала ещё выше — очень советую сразу использовать вторую версию и результаты будут только лучше.

Важно2: Тут нет Vite так как технически он не смог решить проблемы которые решали с Webpack & Rsbuild поэтому и его замеры не включены в итоговый результат.
Разное поведение = Несправедливое сравнение

Важно3: В марте 2026 выше Vite 8.0 с Rust-based bandler-ом, возможно теперь он сможет сравнится с Rsbuild по скорости сборки и минификации.

Кто-то из вас скорее всего уже подумал да подумаешь, 10 секунд на hot reload. Можно успеть налить себе чашечку кофе.

Но давайте посчитаем:

• В команде 40+ разработчиков.

• Допустим, каждый делает 50 циклов "изменил код → посмотрел результат" в день (в реальности часто больше).

Вот формула для тех кто хочет убедиться:

40 разработчиков × 50 циклов × 36 секунд = 72 000 секунд = 20 часов в день

Вывод

В итоге переход с Webpack на Rsbuild дал ПОЧТИ 100 часов экономии в неделю. Обратив внимание на график мы увидим экспоненциальный рост с увеличением разработчиков. На первый взгляд кажется, что речь всего лишь об ускорении Hot Reload. Но на практике мы ускоряем главный процесс при разработке:

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

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

4. API-contract: автогенерация кода без AI и prompt-ов

Одна из самых любимый частей на выступлениях. Кодогенерация это безумно прекрасно, составив правильный алгоритм можно автоматизировать и закрывать целые пласты задач. Это особенно хорошо видно на проектах с микросервисной архитектурой. На той платформе, где я руководил Frontend-департаментом, у нас было 15+ микрофронтов, каждый со своим бэкендом. Десятки контроллеров, сотни эндпоинтов, тысячи моделей.

На старте любого проекта ручные API-клиенты кажутся разумным решением. 2 контроллера, 20 DTO, горстка эндпоинтов. Написать типы руками — дело получаса.

Но когда масштаб уходит за десятки сервисов:

• Frontend типы расходятся с Backend типами

• Новые поля появляются в API, но фронт о них не знает

• Старые поля удаляются, но фронт продолжает их использовать

• Ошибки интеграции ловятся не на этапе компиляции, а в production

• Backend & Frontend говорит на разных языках и моделях

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

swagger.json – это единственный источник истины API

У нас контрактом между фронтендом и бэкендом является swagger.json. Это не рекомендация, не best practice, в документации — это правило, вшитое в процесс.

Никаких ручных DTO. Никаких ручных API-клиентов.

Как это работает в нашем процессе:

Когда бэкенд-разработчик меняет API, в рамках PR-а обновляется swagger.json. Это триггер для фронтенда.

Фронтенд-разработчик запускает генерацию клиентов: pnpm apigen

Эта команда сначала скачивает актуальный swagger.json с бэкенда, затем перегенерирует типы и клиентские функции(endpoints) автоматически. Если контракт изменился так, что фронтенд-код перестаёт компилироваться — TypeScript сразу об этом скажет.

Разработчик видит, что сломалось, и правит прямо в рамках того же PR-а. Ошибка ловится до merge, до staging, до production.

Backend PR → обновлённый swagger.json
        ↓
Frontend: pnpm apigen
        ↓
TypeScript build check
        ↓
Если сломалось → фикс в рамках PR
        ↓
Если собралось → merge

Почему это критически важно

Компиляция становится интеграционным тестом.

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

Фронт всегда знает актуальный API.

IDE сразу показывает новые поля, удалённые поля, изменённые типы. Автокомплит работает с реальным контрактом, а не с тем, что кто-то когда-то описал руками. Ваша Develop ветка всегда имеет актуальный Api контракт с вашего бекенда.

Рассинхрон ловится до релиза.

Если бэкенд убрал поле, а фронт его использует — сборка упадёт. Не в production с ошибкой 500, а прямо на CI, до merge.

Инструмент генерации

Мы используем swagger-typescript-api . Выбирали между несколькими вариантами, но именно эта библиотека подошла лучше всего по гибкости кастомизации и качеству генерируемого кода.

Наша команда pnpm apigen — это наша надстройка над swagger-typescript-api: она автоматически скачивает свежий swagger.json, запускает генерацию и раскладывает результат по нужным директориям и делает нужный нейминг для моделей и методов api. Один вызов — и весь клиентский код актуален.

Сколько сервисов нужно, чтобы начать?

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

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

Кейс 1 — маленький проект:

• 1 BFF (Backend For Frontend)

• 26 Controllers

• 135 Models

Кейс 2 — средний проект:

• 2 BFF

• 83 Controllers

• 571 Models

Кейс 3 — крупная платформа:

• 12 BFF

• 645 Controllers

• 4 342 Models

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

Вот реальные цифры по времени, которое тратит разработчик на интеграцию с изменённым API:

Вывод

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

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

Спасибо вам за честный и приятный фидбек моей работы ❤️

5. React Compiler: Путь к лучшей жизни

Многие годы мы делали одни и те же ритуалы оптимизации:

const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]);
const memoizedCallback = useCallback(() => handleClick(id), [id]);
export const memo(MyComponent);

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

• Усложнял чтение

• Увеличивал объём кода

• Требовал ручного управления массивами зависимостей (что само по себе — источник багов)

• Создавал ложное ощущение необходимости «ручного контроля» производительности

• Повышал порог входа для молодых разработчиков

• Добавлял абстракций в бизнес логику

Что делает React Compiler

React Compiler переносит оптимизацию из runtime в compile-time. Компилятор сам анализирует компоненты и дописывает оптимизационный код за вас — вставляет мемоизацию там, где она действительно нужна. Разработчику больше не нужно думать об этом вручную.

Интересный факт: команда, которая разрабатывает Oxlint, сейчас работает над реализацией React Compiler на Rust — вместо текущего Babel-плагина. Это обещает ещё большее ускорение compile-time в будущем.

Наш реальный опыт

Это не теория и не пересказ анонса с конференции. Мы используем React 18 + React Compiler в production более 7 месяцев и хочу вам сказать это замечательная вещь.

За это время:

• Серьёзных проблем не обнаружили. Ни одного инцидента в production, связанного с React Compiler. Ни одного rollback.

• Удалили большую часть memo, useMemo, useCallback. Код стал чище и проще. Меньше boilerplate — меньше мест, где можно допустить ошибку.

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

• Количество boilerplate уменьшилось значительно. Это не субъективное ощущение — это видно в diff'ах при миграции компонентов.

Пример: до и после

До (с ручными оптимизациями):

import { memo, useCallback, useMemo } from 'react';

interface UserListProps {
  users: User[];
  onSelect: (id: string) => void;
  filter: string;
}

const UserList = memo(({ users, onSelect, filter }: UserListProps) => {
const filteredUsers = useMemo(
    () => users.filter(u => u.name.toLowerCase().includes(filter.toLowerCase())),
    [users, filter]
  );

const handleSelect = useCallback((id: string) => {
    onSelect(id);
},[onSelect]);

return (
 <div>
  {filteredUsers.map(user => (
    <UserItem key={user.id} user={user} onSelect={handleSelect} />
  ))}
 </div>
)});

После (с React Compiler):

interface UserListProps {
  users: User[];
  onSelect: (id: string) => void;
  filter: string;
}

const UserList = ({ users, onSelect, filter }: UserListProps) => {
const filteredUsers = users
    .filter(u => u.name.toLowerCase().includes(filter.toLowerCase()));

return (
 <div>
  {filteredUsers.map(user => (
    <UserItem key={user.id} user={user} onSelect={()=> onSelect(id)} />
  ))}
 </div>
)};

Тот же результат. Меньше кода. Никакой ручной оптимизации. Компилятор разбирается сам.

Замеры с последнего React Conf 2025:

Вывод

React Compiler — одна из немногих технологий последних лет, которая одновременно:

• ускоряет приложение

• уменьшает объём написанного кода

• упрощает поддержку

• снижает порог входа для новых разработчиков

Заключение

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

На практике самые большие улучшения в нашем инженерном процессе пришли со стороны:

• Oxlint проверяет код в десятки раз быстрее ESLint — без компромиссов по правилам.

• Rsbuild сократил feedback loop с 40 секунд до 1 секунды — и качественно изменил ощущения от разработки для всей команды.

• TSGO ускоряет проверку типов — и показывает, куда движется вся компиляторная инфраструктура.

• Генерация API-клиентов из swagger.json устранила целый класс интеграционных ошибок — ошибки ловятся на этапе компиляции, а не в production.

• React Compiler избавил от тонн ручных оптимизаций — код стал проще, а приложение не стало медленнее.

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

Это хорошие алгоритмы, быстрые компиляторы и продуманные инженерные решения. Алгоритмы рулят.

P.S. Конечно же, это не все оптимизации, которыми занимался и продолжаю заниматься непосредственно я и наша инженерная команда. Но надеюсь, что данная статья дала вам возможность лучше углубиться в решение проблемы медленного feature delivery и более приятной и комфортной работы как программиста, так и бизнеса.

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