Что произошло

Для проверки типов автор попробовал TSGO — новую реализацию инфраструктуры TypeScript на Go. В его замерах полная первичная проверка сократилась с 66,4 до 6,39 секунды, а среднее потребление памяти — примерно с 447 до 76 МБ. Проект ещё находится в переходном состоянии, поэтому перед внедрением особенно важна проверка на собственной кодовой базе и в непрерывной интеграции.

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

Самое ощутимое изменение связано со сборкой. После Webpack и неудачной для их схемы микрофронтендов попытки перейти на Vite команда выбрала Rsbuild на базе Rspack. Автор сообщает о сокращении горячего обновления примерно с 36 до одной секунды и о меньшем размере итогового пакета. Здесь решающим фактором стала не только скорость, но и поддержка Module Federation.

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

Отдельная операция может занимать всего несколько секунд, но на команде из десятков человек ожидание быстро превращается в потерянные часы. В статье приводится простой расчёт: при 40 разработчиках и 50 циклах проверки в день разница между 36 и одной секундой способна освободить почти 20 часов в сутки. Это оценка автора, однако она хорошо показывает, почему скорость обратной связи — не косметическая метрика.

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

Ещё один слой проблемы — рассинхронизация клиентской и серверной частей. В материале предлагается считать swagger.json единым контрактом и автоматически получать из него типы и функции для API. Тогда изменение контракта становится ошибкой сборки до слияния изменений, а не неожиданностью после выпуска.

На практике

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

Затем улучшения можно вводить небольшими шагами:

1. Подключить TSGO в отдельной проверке непрерывной интеграции и сравнить его результат с текущим tsc.
2. Проверить Oxlint или другой анализатор на существующем наборе правил; несовпадение правил важнее выигрыша в секундах.
3. Для Rsbuild сначала сделать пробную миграцию одной части приложения, особенно если используются Module Federation, нестандартные загрузчики или плагины Webpack.
4. Генерировать клиент API из опубликованного контракта и хранить обновлённые типы вместе с изменением серверного API.
5. Включать React Compiler постепенно, наблюдая за поведением компонентов и оставляя понятные проверки производительности до и после перехода.

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

Итог

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

TSGO, Oxlint, Rsbuild и React Compiler стоит оценивать как части единой цепочки, а не как модные замены. Для небольшого приложения часть переходов не окупится; для большой кодовой базы даже несколько секунд в самых частых операциях могут изменить ежедневный ритм работы.