ГлавнаяБлогFlask + браузер: почему Python UI живет в вебе
Python

Flask + браузер: почему Python UI живет в вебе

Узнайте, почему для десктопного приложения на Python выбрали Flask + браузер вместо PyQt или Electron. Получите практические инсайты для своего проекта.

Al
Редакция Algolitalgolit.ru
6 мин чтения16 июня 2026 г.

Зачем читать эту статью?

Вы когда-нибудь задумывались, почему некоторые десктопные приложения на Python открываются в браузере, а не в нативном окне? Это не случайность, а осознанный архитектурный выбор. В этой статье я разберу четыре реальных подхода к созданию UI для Python-приложения, покажу, почему Flask + системный браузер победили, и раскрою неочевидные последствия такого решения.

Четыре реалистичных варианта

Для инструмента автоматизации обслуживания WordPress на Python мы рассматривали четыре подхода:

ПодходUIРазмер дистрибутиваСтоимость разработкиДоп. работа под ОС
Нативный (Swift / WPF)Окна ОСМалый–среднийВысокая (отдельная реализация под каждую ОС)Большая
PyQt / PySideВиджеты QtСредний (~80 МБ)СредняяМалая
ElectronВеб-UI на ChromiumБольшой (~150+ МБ)СредняяМалая
Локальный Flask + браузерВкладка браузераМалый (~50 МБ)СредняяМалая

Почему PyQt и Electron не подошли

PyQt

PyQt был серьёзным кандидатом. Python-стек привлекателен, но стили виджетов незаметно отличаются между ОС, система компоновки Qt требует постоянного внимания, а разрешение плагинов Qt под PyInstaller — муторное занятие. Скорость разработки оказалась ниже ожидаемой.

Electron

Electron — стандарт индустрии для кроссплатформенного UI, и HTML/CSS-интерфейсы пишутся быстро. Но дистрибутив весит более 100 МБ, а потребление памяти высокое. Для инструмента, который часто работает в фоне, такие накладные расходы неприемлемы.

Почему локальный Flask + браузер победил

Итоговая структура: Flask (лёгкий веб-фреймворк Python) + системный браузер для UI. Решение опиралось на три оси:

  1. Бэкенд всё равно должен быть на Python. SSH-соединения через fabric/paramiko, автоматизация браузера через playwright, шифрование через cryptography — все ключевые библиотеки живут в экосистеме Python. Писать бэкенд на другом языке не было вариантом. Если Python уже требуется на бэкенде, размещение UI тоже на Python упрощает дистрибуцию.
  2. HTML/CSS/JS ускоряет итерации UI. Flask рендерит templates/index.html, а UI построен на Tailwind CSS и ванильном JS. Любой с опытом веб-разработки может быстро добавлять функции. Изучать каждый раз новый словарь нативных виджетов замедляет итерации гораздо сильнее.
  3. Дистрибутив примерно в три раза меньше Electron. Не встраивая Chromium, артефакт PyInstaller весит около 50 МБ. Одна и та же кодовая база Python и папка templates/ работают и под macOS .app, и под Windows .exe. Почти никакой дополнительной работы под ОС — это самый большой практический выигрыш.

Побочные эффекты браузерного UI

У этой структуры есть цена.

Вкладка браузера — это и есть UI. Если пользователь закрывает вкладку, приложение всё ещё работает, но до него не добраться. Повторный двойной клик по приложению не помогает, потому что macOS LaunchServices видит «приложение уже запущено» и просто переключает на него, не открывая новую вкладку.

Решение потребовало проверки живости на основе heartbeat в сочетании с самозатирающимся lock-файлом. (Подробнее в статье «когда macOS-приложение отказывается перезапускаться».)

Другие побочные эффекты: занят фиксированный порт (нужно обнаружение коллизий портов), приватный режим браузера ломает сессию входа и т.д. Ничего из этого не возникло бы с нативным окном.

Размышление — выбор структуры зависит от требований

«Локальный Flask + браузер» — не универсальное лучшее решение. Для приложений, которые сильно полагаются на нативные компоненты (центр уведомлений, иконка в трее, интеграция с keychain), или где запуск часто происходит офлайн, PyQt или нативный подход имеют больше смысла.

Но в условиях, которые реально стояли перед автоматизацией обслуживания WordPress — тяжёлый бэкенд, дашборд-подобный UI, малый дистрибутив, обязательная поддержка двух ОС — Flask + браузер оказался правильным балансом. Мы оптимизировали скорость разработки и размер дистрибутива, приняв другие компромиссы.

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

Практический вывод

Если вы создаёте десктопное приложение на Python с бэкенд-ориентированной логикой и простым дашбордом — попробуйте связку Flask + системный браузер. Вы получите малый размер дистрибутива и быструю разработку. Но не забудьте обработать кейс с закрытой вкладкой и коллизией портов. Начните с минимального прототипа:

from flask import Flask, render_template
import webbrowser

app = Flask(__name__)

@app.route('/')
def index():
    return render_template('dashboard.html')

if __name__ == '__main__':
    # Открываем браузер после запуска сервера
    webbrowser.open('http://127.0.0.1:5000')
    app.run(port=5000)

Этот код — основа, которую можно расширять под свои задачи.

#Flask#десктопное приложение#Python UI#браузер#кроссплатформенность
Al
Редакция Algolit

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

Хочешь закрепить знания на практике?

Решай задачи на Algolit — интерактивная платформа для обучения

Начать бесплатно →