Flask в 2025 году: замедление развития, состояние экосистемы и что это значит для разработчиков
Команда Flask и связанных с ним библиотек прожила один из самых тихих годов за всю историю проекта. Если смотреть только на релизы, 2025‑й для Flask можно охарактеризовать как «минимальное обслуживание без заметного движения вперёд». Но картина становится ещё выразительнее, если добавить к этому статистику по активности на GitHub и динамику pull request’ов.
При этом автор ежегодного обзора экосистемы Flask подчёркивает важную деталь: все цифры и выводы получены «по-старому» — без использования больших языковых моделей и генеративных инструментов. Это снижает риск искажённых или вымышленных данных, но не исключает человеческих ошибок в подсчётах. Поэтому любые найденные неточности подлежат исправлению, если на них укажут.
Релизы Flask: год почти без событий
За весь 2025 год Flask вышел всего два раза, и оба раза речь шла не о новых возможностях, а о патчах к версии 3.1.0, релиз которой состоялся ещё в ноябре 2024 года. Фактически развитие ограничилось точечными исправлениями, без новых фич и серьёзных архитектурных шагов.
Чтобы понять масштаб замедления, достаточно взглянуть на динамику релизов, начиная с 2018 года — момента выхода Flask 1.0.0:
- 2018 — ветка 1.0, всего 5 релизов, из них 4 патч‑релиза;
- 2019 — ветка 1.1, 3 релиза;
- 2020 — переход к версии 2.x;
- 2021 — ветка 2.0;
- 2022 — ветки 2.1 и 2.2, всего 8 релизов, 6 из которых патч‑релизы;
- 2023 — версии 2.3 и 3.0;
- 2024 — релиз ветки 3.1;
- 2025 — только два патча к 3.1.0.
Если раньше новый минорный релиз почти всегда сопровождал год, то теперь 2025‑й становится первым периодом, когда проект живёт только за счёт мелких исправлений уже существующей ветки. С точки зрения пользователя это означает: критические баги исправляют, но эволюция фреймворка заметно замедлилась.
GitHub‑активность: нисходящий тренд подтверждается
О релизах можно спорить: мало релизов не всегда значит отсутствие работы. Поэтому полезно посмотреть на число объединённых pull request’ов (PR) в репозиториях Flask и Werkzeug — двух ключевых компонентах экосистемы. Если объединить их показатели, получаем следующую картину по годам (с 2018 года):
- Flask + Werkzeug:
- 2018 — 204 замёрженных PR;
- 2019 — 245;
- 2020 — 282;
- 2021 — 353;
- 2022 — 226;
- 2023 — 131;
- 2024 — 43.
Небольшое количество прямых коммитов («мимо PR») здесь не меняет общей картины: мейнтейнеры редко коммитят напрямую, поэтому статистика по PR достаточно точно отражает реальную активность. И тренд однозначен — пик пришёлся на 2021 год, после чего количество принятых изменений неуклонно падает, причём в 2024‑м и 2025‑м этот спад становится особенно резким.
Иными словами, ощущение «затишья» вокруг Flask не иллюзия. Это закрепившийся тренд, а не временный сбой.
PR без мерджа: резкий скачок отказов
Интереснее всего выглядит статистика по pull request’ам, которые были закрыты без слияния. Если раньше доля отклонённых PR долгое время держалась примерно на уровне 30%, то в 2025 году она взлетела до 72%.
По годам (Flask + Werkzeug, суммарно):
- несколько лет подряд — около 26–36% PR закрывались без мерджа;
- 2023 — показатель колеблется в районе 30+%;
- 2025 — уже 72% закрытых без слияния.
То есть почти три из четырёх предложений по изменению кода в 2025 году так и не попали в основной репозиторий. Это нетипично для зрелой, но ещё живой экосистемы и само по себе требует объяснения.
Возможные причины роста доли отклонённых PR
Автор обзора рассматривает, по крайней мере, два правдоподобных объяснения:
1. Проект воспринимают как в целом завершённый.
Мейнтейнерам может казаться, что Flask достиг точки зрелости, когда он и так делает всё необходимое. Разработка концентрируется на поддержке и исправлении редких багов, а не на внедрении новых идей. В такой логике естественно, что всё больше PR признаются избыточными или не вписывающимися в видение проекта.
2. Взрывной рост PR, сгенерированных с помощью AI‑инструментов.
В 2025 году многие разработчики начали использовать генеративный ИИ для создания патчей и даже целых PR. На практике это часто приводит к шаблонным, поверхностным или просто некорректным изменениям. Авторы таких PR нередко не разбираются в контексте кода и не готовы доводить свой вклад до состояния, приемлемого для включения в проект.
Характерный пример — одно и то же простое замечание в документации. На него существует один нормальный, ожидающий ревью PR. Но параллельно было открыто и затем закрыто семь других PR с «конкурирующими» правками. Большинство из них были отправлены позже актуального и при этом не решали проблему корректно. Картина очень похожа на результат массового применения генеративных подсказок: много шума и мало ценного содержания.
Что реально изменилось в Flask за год
Контентной частью 2025‑го для Flask можно считать набор точечных правок:
- исправлена ошибка, из-за которой `stream_with_context` не работал в асинхронных маршрутах;
- выполнен ряд доработок, связанных с типизацией в Python (улучшены аннотации типов, корректность подсказок для IDE и статического анализа);
- изменён порядок, в котором пробуются ротируемые секретные ключи (важно для безопасности и миграций ключей).
Все эти изменения полезны, но вряд ли можно назвать их драйверами развития. Они больше про аккуратное обслуживание и поддержание стабильности.
Werkzeug, основной WSGI/HTTP‑компонент в экосистеме Flask, в 2025 году также получил лишь незначительные обновления, без крупных фич и переломных изменений.
Взгляд на будущую версию 3.2.0: объединённый контекст
Из 43 замёрженных в 2025 году PR по Flask и Werkzeug автор обзора специально выискивал те, что могут принести заметные изменения в будущем, даже если пока не вошли в релиз. Одной из таких запланированных новинок станет объединение контекста приложения и контекста запроса в единый контекст, который появится в версии Flask 3.2.0.
Идея непростая: ранее разработчики явно манипулировали контекстами (например, `app_context` и `request_context`), а теперь их объединяют, чтобы упростить внутреннюю модель и сделать API более логичным. Однако эффект для обычного пользователя может оказаться не таким уж впечатляющим.
Отношение автора обзора к этому изменению можно выразить как сдержанный скепсис — что-то вроде «ну ладно, пусть будет». С технической точки зрения это крупное внутреннее перераспределение, способное облегчить жизнь мейнтейнерам и немного упростить API, но для массовых проектов на Flask оно вряд ли станет переломным моментом.
Quart и асинхронный контекст: чего ждать дальше
На фоне общего замедления развития Flask всё чаще вспоминают о Quart — фреймворке, совместимом с API Flask, но изначально построенном вокруг асинхронной модели и протокола ASGI.
Для тех, кто хочет «тот же Flask, но с полноценной асинхронностью», Quart выглядит естественным кандидатом. Однако широкого перехода на него пока не случилось, во многом из‑за:
- высокой инерции больших проектов на Flask/Werkzeug;
- консервативной части сообщества, предпочитающей WSGI‑подход;
- растущей конкуренции не со стороны Quart, а со стороны FastAPI и других ASGI‑фреймворков.
На практике Quart остаётся нишевым решением для тех, кто хочет сохранять знакомый стиль разработки, но уже живёт в мире async/await. Если Flask будет продолжать двигаться столь медленно, Quart может получить второй шанс — но пока он не стал мейнстримом.
Flask vs FastAPI и другие фреймворки
Одновременно с внутренним замедлением Flask рынок веб-фреймворков для Python продолжает активно развиваться. Особенно заметно это на фоне FastAPI, который:
- изначально проектировался под асинхронный стек и ASGI;
- уделяет большое внимание валидации данных и типам (Pydantic и аннотации);
- агрессивно позиционируется как современное решение для API‑сервисов.
На этом фоне Flask всё больше воспринимается как стабильный, проверенный временем инструмент, но уже не находящийся «на переднем крае» трендов. Свою нишу он продолжает удерживать:
- для компактных сервисов и прототипов, где важна простота;
- для старых и средних по размеру проектов, где переписывать всё на FastAPI нет смысла;
- там, где нужна предсказуемость и глубокая интеграция с огромной базой уже существующих расширений.
Однако для новых проектов всё чаще звучит вопрос: «если начинать с нуля в 2025 году, стоит ли вообще выбирать Flask?». И ответ всё сильнее зависит от конкретного сценария, а не от былой популярности.
Расширения Flask: зрелость вместо бурного роста
Один из исторических плюсов Flask всегда заключался в богатой экосистеме расширений. Она и сейчас остаётся одним из ключевых аргументов в пользу фреймворка: ORM, аутентификация, админ‑панели, интеграция с облаками и сторонними сервисами, инструменты логирования и трейсинга — почти всё уже когда‑то написано.
Но и здесь видно, что стадия активного роста сменилась этапом зрелости:
- новых расширений появляется меньше;
- многие популярные пакеты поддерживаются в режиме «минимальных обновлений»;
- часть расширений постепенно устаревает или теряет актуальность (особенно там, где требуются асинхронные или высоконагруженные решения).
Для разработчиков это означает, что «волшебная коробка», в которой есть решение под любую задачу, всё чаще требует переосмысления. Перед внедрением того или иного расширения в 2025 году полезно проверить:
- насколько жив проект (последние коммиты и релизы);
- поддерживает ли он свежие версии Flask и Python;
- не проще ли реализовать нужную часть самостоятельно, чем тащить старый и тяжёлый пакет.
Что всё это значит для практикующих разработчиков
Снижение активности вокруг Flask не делает его автоматически «плохим» или «умершим» фреймворком. Скорее, он входит в фазу зрелой стабильности, когда:
- интерфейсы мало меняются, а значит, долгоиграющие проекты не страдают от частых миграций;
- багов относительно немного, и большинство критичных проблем уже решены;
- новые возможности появляются редко, поэтому ждать, что фреймворк подтянется к новейшим трендам (полная асинхронность, встроенный типобезопасный слой и т.п.), — вряд ли разумно.
Практические выводы:
1. Если у вас есть крупный проект на Flask, паниковать не нужно.
Поддержка продолжается, критические баги исправляют, архитектуру ломать не планируется. Проект можно безопасно эксплуатировать ещё долгие годы.
2. Если вы стартуете новый сервис в 2025 году, имеет смысл осознанно сравнить Flask с альтернативами.
Для простых синхронных API и админок Flask по‑прежнему даёт быструю разработку и предсказуемый результат. Но если на горизонте асинхронная нагрузка, микросервисы и плотная работа с типами, разумно ориентироваться и на современные ASGI‑фреймворки.
3. Если вы хотите вкладываться во вклад в open source, будьте особенно аккуратны.
Массовые, поверхностные PR — особенно сгенерированные ИИ — с высокой вероятностью будут закрываться без мерджа. Чтобы ваш вклад оказался полезным:
- разбирайтесь в кодовой базе перед изменениями;
- читайте открытые и закрытые issues и PR по близкой теме;
- не отправляйте «альтернативные» варианты исправлений, если уже существует качественный, ожидающий ревью PR.
Стратегия использования Flask в ближайшие годы
На фоне описанных тенденций разумная стратегия выглядит так:
- Для существующих проектов:
- следить за релизами 3.1.x и будущей 3.2.x;
- постепенно адаптировать код к изменениям контекста (объединение app/request‑контекстов), если это затронет используемые паттерны;
- избегать привязки к устаревающим расширениям, по возможности выносить критичный функционал в свой код.
- Для новых проектов:
- честно сформулировать требования к асинхронности, производительности и типобезопасности;
- выбирать Flask, если нужны: простота, быстрый старт, минимум магии и богатство проверенных решений;
- рассматривать FastAPI, Quart и другие ASGI‑фреймворки, если в приоритете: async/await, масштабируемость, современная работа с типами и тесная интеграция с экосистемой асинхронных библиотек.
- Для команд и архитекторов:
- учитывать, что «золотой век» стремительного развития Flask позади, но это одновременно и плюс — меньше неожиданных изменений;
- планируя архитектуру, не завязывать бизнес‑логику на конкретные особенности Flask, чтобы при необходимости упростить миграцию на другой фреймворк.
Итог: Flask остаётся, но уже не ведёт
2025 год для Flask — это год замедления, а не падения. Проект жив, но растёт уже не вширь, а вглубь стабильности. Новые возможности появляются редко, активность мейнтейнеров снизилась, доля отвергнутых PR необычно высока, конкуренты набирают обороты.
Для разработчиков это не сигнал к немедленной миграции, а напоминание: выбор фреймворка стоит делать не по инерции и не «по привычке Flask», а по здравому расчёту. Flask по‑прежнему отлично решает многие задачи, но он уже не единственный и не всегда лучший выбор по умолчанию — особенно в мире, где асинхронные фреймворки и инструменты типизации становятся фактическим стандартом.
