Всем привет! Меня зовут Алексей Золотых, я тимлид команды веб-редакторов в МойОфис. Недавно мы запустили новое шоу АйТир Лист. В каждом выпуске мы берём одну тему из мира разработки и раскладываем всё по тир-листу: от FAIL до GOD.
В пилотном выпуске мы с коллегой — Александром Коротаевым, фронтенд-гуру и энтузиастом креативного кодинга, прошлись по популярным опенсорс-инструментам для фронтенда: от тех, которые пора отпускать, до тех, что стали эталоном. Эта статья — расширенная версия выпуска. Под катом рассказываем, что у нас попало в FAIL, кто выжил на уровне MVP, кого мы поставили в SENIOR и кто, по нашему мнению, заслужил звание GOD.
Дисклеймер: мы с большим уважением относимся ко всем упомянутым проектам. Многие из них помогли индустрии вырасти. Но сегодня мы смотрим на них через призму вопроса: что бы мы посоветовали новичку или команде в 2025 году.
Как работает наш тир-лист
В шоу мы берём определённую область в разработке, затем выбираем самые известные инструменты, практики, фреймворки и раскладываем всё по полочкам: от откровенных фейлов до бог-уровня.
Зачем так делать?
Потому что в индустрии слишком много инструментов, а времени разбираться в каждом — мало. У каждого разработчика есть сформированные вкусы и набор библиотек, которые он будет защищать до последнего коммита. Но когда садишься разбирать всё по тир-листу, внезапно оказывается, что некоторые легенды не пережили проверку временем, а молодые проекты уже претендуют на статус стандарта.
Мы условно разделили инструменты на четыре категории:
FAIL
Решения, которые были полезны «когда ничего лучше не было», но в 2025 году применять их в боевых проектах — такое себе удовольствие. Часто они прожили достойную жизнь, но сейчас честнее сказать им спасибо и отпустить.
MVP
Инструменты, которые работают, иногда даже хорошо, но использовать их стоит с пониманием ограничений. Они не плохие, просто… не идеальные. Порой это переходные технологии или вещи, которые исторически прижились, но уже давно требуют переоценки.
SENIOR
Мощные, зрелые инструменты, которые стали важной частью индустрии. У них есть недостатки, шероховатости, спорные решения, но без них невозможно представить современные фронтенд-проекты. Это такой надёжный инструмент, который всегда под рукой.
GOD
Инструменты, которые делают своё дело. Минимум настроек, максимум пользы, точность, предсказуемость, элегантность. Они не пытаются быть всем и сразу, но внутри своей ниши это эталоны.
Ещё раз отметим, что тир-лист — не абсолютная истина, а возможность взглянуть на знакомые вещи под новым углом и понять, что из инструментов тащит индустрию вперёд, а что продолжает жить лишь по инерции.
Поехали по уровням!
FAIL: инструменты, с которыми пора попрощаться
Дети, запомните: если дядя из туториала предлагает вам начать проект на Express.js, лучше вежливо кивните и тихо отойдите. Раньше, когда выбор был не такой широкий, Express и правда помогал быстро создать прототип. Но в 2025 году начинать на нём новый проект — всё равно что запускать стартап на jQuery: технически возможно, но это создаст лишние проблемы.
Express по-прежнему широко используется в уже существующих проектах, и это нормально — наследие остаётся с нами. Но для новых задач лучше сразу смотреть в сторону современных фреймворков. Для простых приложений отлично подойдёт Next.js, а для более серьёзных бэкендов — Fastify, Nest.js или любой другой инструмент, который развивается и не застрял в прошлом.
Использовать Create React App в 2025 году всё равно что отправлять SMS. Раньше все так делали, но сейчас отправителями остались в основном операторы связи и МЧС.
CRA был отличным решением для своего времени, но это время прошло.
В ИТ-проектах есть два пути:
первый — давать больше и больше настроек, чтобы можно было «подогнать всё под себя»;
второй — убирать настройки, чтобы разработчику не приходилось тонуть в конфигурации.
CRA пошёл по второму пути в максимально радикальном виде. Идея была простая: запускаем React одной командой без единого лишнего параметра. Минимум настроек, минимум гибкости, всё строго по учебнику.
На практике это превратилось в жёстко закрытую коробку. Как только требовалось сделать что-то нетривиальное, начинались пляски с переопределением webpack-конфига через дополнительные тулзы. С учётом того, что команда React давно перешла к другим подходам, можно честно сказать: CRA свою миссию выполнил, но эпоха закончилась.
«Остановись, мгновение, ты прекрасно!» — примерно так я отреагировал, когда впервые увидел Moment.js после мучений с new Date() и ручного прибавления минут. Красиво, удобно, читаемо — мечта.
Но эйфория длилась ровно до релиза. В бою Moment.js показывал свою тёмную сторону: значения дат мутировали, «два часа назад» внезапно превращались в «полтора», баги расползались по всей кодовой базе.
Проблемы росли быстрее, чем их могли чинить. Это и огромный размер библиотеки, и отсутствие нормального tree shaking, и необходимость вручную игнорировать пакеты локалей в сборке, и сложность контроля мутабельности.
В итоге Moment.js стал жертвой собственной популярности. Он перерос сам себя и превратился из удобного инструмента в источник постоянных сюрпризов. Сейчас есть лёгкие и предсказуемые альтернативы, которые закрывают те же задачи без боли. Поэтому да, это честный FAIL.
Когда webpack только появился, он казался шагом в будущее: «Давайте пересоберём всё иначе и дадим фронтенду взрослый бандлер, пайплайны, транспиляцию, лоадеры, middleware!» И первые версии действительно стали большим прорывом.
Но затем началось... Плагинов стало слишком много, конфигурации разрастались до размеров эпоса, инструмент стал гибким до степени «сломай себе всё, если ошибёшься в одной строчке». Экосистема стала тяжёлой и непредсказуемой, а корпоративные хотелки встраивались внутрь, утяжеляя проект.
Финальным аккордом стал модуль federation: в теории это была интересная идея для микрофронтендов, на практике — ещё один слой сложности, который часто делает систему менее управляемой.
Webpack по-прежнему используется и будет использоваться ещё долго. Но в качестве инструмента для новых проектов он уже проигрывает современным решениям: Vite, esbuild, rspack и другим быстрым минималистичным сборщикам.
Поэтому в нашем тир-листе webpack — это FAIL не как «плохой проект», а как «заслуженный ветеран, который давно перетрудился».
MVP: живём, но с оговорками
Казалось бы, что ещё можно придумать в мире React, чтобы перевернуть рынок? Но Next.js сумел: вырос от «ещё одного фреймворка» до полноценной экосистемы с огромным комьюнити. Сейчас Next.js — это почти WordPress для React, только куда более пригодный для серьёзной разработки.
Лично мне Next.js не слишком близок. Порой кажется, что его используют, когда хотят через силу заставить фронтендеров писать бэкенд, в который они идти не планировали, да и не всегда умеют. Сервер-компоненты, собственный рантайм, сложное окружение — всё это превращает Next в инструмент, который требует отдельной экспертизы.
Раньше у Next были проблемы с производительностью: из-за особенностей рантайма задержки примерно в 200 мс на ответ в проде считались нормой. Но Александр Коротаев убедил меня, что большинство этих болей уже исправили, и даже показал кейс, где Next.js действительно раскрывается. Речь про Static Site Generation, который позволяет выкладывать проекты прямо на GitHub Pages или другие хостинги без серверов. Генератор сам собирает страницы на основе данных. Для документации, блогов и многих pet-проектов это идеальный вариант.
В итоге Next.js — рабочий, зрелый и популярный инструмент, который сообщество на самом деле любит. Но лично я не стал бы ставить его выше TypeScript, поскольку охват и влияние у TS куда шире, а дальнейшая судьба Next.js остаётся открытой. Фреймворк всё активнее превращается в экосистему, а это чревато сценарием, где проект начинает прогибаться под корпоративные запросы и постепенно обрастает тем, что ему изначально не было нужно.
Create React App откровенный FAIL, а вот Craco много лет был способом сделать жизнь с CRA чуть легче. Фактически Craco — это инструмент, который позволяет переопределять webpack-конфиг, скрытый внутри CRA. В своё время он был очень удобным: гибким, понятным и с большим набором возможностей. Но сама идея подобных прослоек показывает, что базовая архитектура CRA была слишком жёсткой.
Когда CRA обновлялся, Craco обычно ломался. Его конфигурации со временем разрастались и становились больше оригинального webpack.config. Получался бесконечный цикл: CRA -> прослойка -> костыль для прослойки -> ещё один костыль. Жить можно, но долго так существовать было невозможно.
Сегодня Craco уже не нужен, так как экосистема React ушла далеко вперёд. Но как важный артефакт эпохи CRA, он заслуживает честное место в MVP: рабочий инструмент, который выполнял свою задачу, но появился лишь потому, что основная система не справлялась.
От Lodash хотелось отказаться ещё лет десять назад, но он по-прежнему используется. Не потому, что он незаменим, а потому что его лень выпиливать, а старые код-стайлы не дают вмешиваться в привычную структуру проекта.
Когда-то Lodash был настоящим спасением. Он дал удобные, понятные методы для работы с коллекциями, упростил жизнь разработчикам и стал «общим языком» внутри команд. Потом появились нативные методы, но Lodash жил по инерции, а теперь живёт как часть инфраструктуры, которую «опасно трогать».
Тем не менее Lodash до сих пор приносит пользу. Понятные и узнаваемые названия методов делают код более предсказуемым и помогают командам легко договариваться. И важно помнить: сам Lodash вырос из underscore, той самой библиотеки с нижним подчёркиванием, которая плохо сжималась, и поэтому её фактически переписали. Сегодня Lodash скорее привычка, чем необходимость. Он не мешает, но и не является обязательным инструментом для современного фронтенда.
tsnative — это наш новый опенсорс-проект, компилятор TypeScript native. Обычно TypeScript-код исполняется в браузере через JavaScript-рантайм, а tsnative позволяет собрать из него нативный бинарник, что даёт возможность применять TS в новых сценариях и расширять его область применения.
Важно уточнить, что сейчас tsnative не готовый к выпуску продукт, а скорее исследовательский прототип, выпущенный в августе 2025 года. Он помогает решать задачи там, где важна скорость запуска, и позволяет писать на TypeScript за пределами браузера. Когда проект дозреет, он вполне может оказаться на верхних строчках тир-листа. Но пока это честное MVP: интересная и нужная технология, которой нужно время, чтобы доказать свою зрелость.
SENIOR: отличные, но не идеальные решения
Полезное зло нашего мира. Когда-то мы писали на JavaScript и всё было хорошо (или казалось, что хорошо), пока в индустрию не пришёл TS и не объяснил, что «строки это не числа» и что вообще-то типы полезны. Сегодня TypeScript — базовый инструмент: как хороший тяжёлый молоток, которым можно и гвозди забивать, и по пальцам себе заехать.
Но у него есть своя тёмная сторона. TS подталкивает разработчиков к созданию монструозных конструкций: дженерики, вложенные в дженерики, вложенные в дженерики… В какой-то момент код начинает напоминать бесконечный лабиринт типовых фанфиков. Спецификация местами плавает, типы иногда «протекают», а сложные узлы приходится распутывать вручную.
Тем не менее, жить без него уже сложно. Это как поход в МФЦ: идти не хочется, но приходишь, и внезапно всё работает чётко и быстро. Точно так же с TypeScript: иногда раздражает, но в итоге делает кодовую базу крепче и команду спокойнее.
Любовь с первого взгляда. Когда-то был Selenium, который работал, ломался, снова работал и снова ломался. Цикл страданий длился годами. И вдруг на наших глазах появился Playwright — стабильный, удобный, быстрый и, что немаловажно, предсказуемый. Инструмент моментально стал новым стандартом автоматизации браузера.
Но и у Playwright есть ограничения. Среда браузера нестабильна по своей природе: API постоянно меняются, поведение может отличаться от версии к версии. В таких условиях невозможно создать идеальный фреймворк для автотестирования. Но Playwright — это максимально близкое к идеалу решение.
Хороший фреймворк (говорю это, пригибаясь от виртуальных гнилых помидоров, которые уже начали бросать фанаты Vue и Svelte). Он занял большое место в индустрии и, нравится нам это или нет, с нами ещё надолго. Пока частичная реактивность наконец не победит или пока ИИ не решит, что фронтенд можно писать без людей.
У React есть свои проблемы. Он немного устал: на него постоянно навешивают новые концепции вроде React Server Components, и порой кажется, что хочется просто «заморозить» его в стабильном состоянии. Однако факт остаётся фактом: React стал инфраструктурой, как TypeScript или Next.js. Его не обязательно любить, но игнорировать уже невозможно.
Делать React стандартной библиотекой браузера я бы уже не стал: порог сложности слишком высок. Но в мире фронтенда React остаётся уверенным, опытным SENIOR, который прошёл всё и пережил всех.
Это библиотека, которую по-настоящему любят. Она до сих пор популярна, до сих пор живая и по-прежнему предлагает гибкую экосистему плагинов. Да, современный фронтенд давно ушёл вперёд, но jQuery не испортился. Он просто не стал частью «новой школы».
Я сам использовал его очень давно и всё ещё вспоминаю с теплом. Несмотря на возраст, у jQuery продолжают выходить новые версии: аккуратные, точечные, с небольшими улучшениями. Но рекомендовать его для современных приложений с активным DOM-манипулированием я бы уже не стал. Это инструмент эпохи, которую мы прошли, но которая оставила после себя много хорошего.
GOD: решения, которые можно считать эталонными
Редкий случай, когда инструмент делает единственную вещь и делает её идеально, не пытаясь выполнять больше, чем должен. Это приятный форматтер с минимальным количеством настроек, буквально несколькими флагами, которые сложно даже назвать «конфигурацией».
На вопрос «А можно подстроить Prettier под наш код-стайл?» всегда есть только один ответ: «Нет». Есть ровно один стиль, и именно в этом его сила. В экосистеме JavaScript давно не хватало такого жёсткого и предсказуемого подхода, как в Go или в Python с PEP 8. Когда нет настроек и бесконечных споров: «а давайте поменяем отступы?», «а может, двойные кавычки?», «а давайте добавим 14-й форматтер?» — работать становится проще.
Парадоксально, что Create React App, тоже минималистичный инструмент без настроек, у нас попал в FAIL, а Prettier с таким же отсутствием гибкости оказался в GOD-tier. Но разница в масштабе задач: CRA хотел быть «всё-в-одном», а Prettier хочет быть просто… Prettier. Маленький, компактный, надёжный и невероятно полезный. Он тихо удерживает опенсорс в едином стиле не хуже линтеров и код-ревью.
Идея Testing Library проста и прекрасна: тестировать интерфейс так, как с ним взаимодействует реальный пользователь, а не искать элементы по внутренним классам, которые меняются каждую неделю.
Testing Library заставляет смотреть на accessibility: использовать роли, aria-атрибуты, реальные элементы интерфейса. В итоге UI становится лучше не только для автоматизации тестов, но и для людей, особенно для тех, кто использует скринридеры.
Это семейство библиотек давно стало де-факто стандартом. Оно есть для всех популярных фронтенд-фреймворков: React, Vue, Angular, Svelte, Solid. И подходит не только для тестов — это инструмент, который дисциплинирует и заставляет писать интерфейсы осмысленно.
Отдельный забавный факт: автор Testing Library монетизирует проект через образовательные курсы и учитывает региональные коэффициенты и для разработчиков из России его курсы стоят заметно дешевле.
Testing Library по-настоящему меняет культуру разработки интерфейсов. И за это место в GOD-tier он получает абсолютно заслуженно.
Финал
Вот такой получился наш тир-лист опенсорсных фронтенд-инструментов: от легендарных ветеранов, которые пора отпускать, до эталонных решений, которые тихо держат индустрию на своих плечах. Делитесь в комментариях своими вариантами: что вы бы отправили в FAIL, что подняли бы в GOD и какие темы хотите разобрать в следующих выпусках.
В шоу мы обсуждаем всё ещё подробнее, спорим, шутим и приводим реальные кейсы. Видео выпуска можно посмотреть здесь:
romant094
Я бы еще Biome добавил в раздел Senior. Однажды попробовав его, я навсегда отказался от eslint и prettier. Работает в разы быстрее чем ранее упомянутая пара и активно развивается.
zolotyh Автор
Мне тоже сама идея кажется очень перспективной! Единственное, он пока не так широко используется.
zolotyh Автор
Еще конечно пугает то, что он написан не на JS/TS (Rust). С одной стороны, именно это дает скорость, с другой стороны я уже не могу отлаживать код, если что-то идет не так
romant094
Как раз таки если все работает идеально, дебажить ничего не требуется. Вы пишете именно об этом про prettier.
Я уже год использую Biome и вижу, как он активно развивается, там появилось очень много недостающих фичей, в том числе и сортировка импортов. Круто, что все это из коробки идет, никаких кастомных плагинов.