Когда Windows-приложение лучше не переводить в веб: таблица решений и разделение как рабочий вариант

«Пора перевести наше внутреннее Windows-приложение в веб» — таких запросов с каждым годом больше. Мотив часто здравый. Но когда разбираешь задачу, нередко оказывается, что в веб хотят перевести целиком как раз то приложение, которому после этого станет хуже пользоваться и дороже жить.

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

1. Сначала вывод (таблица решений)

Смотреть нужно не на приложение целиком, а на каждую функцию и свойство по отдельности.

Символы значат следующее. ◎ = эффект от перевода в веб большой / ○ = перевод в веб подходит / △ = осторожно (при части условий не подходит; сначала посмотрите решения вне веба) / × = не подходит (ограничение заложено в устройство браузера, дополнительной разработкой его почти не обойти).

И сразу вывод.

• За запросом «хотим в веб» обычно стоят три разные проблемы. Затраты на развёртывание, ограничения по месту работы и устаревшая технология. У каждой свой ответ, и перевод в веб закрывает лишь часть из них (глава 2).
• Если есть связь с оборудованием, обработка локальных файлов или офлайн-режим, эти части в веб лучше не выносить. Браузер специально ограничивает доступ к локальным ресурсам — это не дыра в вебе, а заложенная модель безопасности¹. Обходные пути есть, но они приносят свои затраты: не все браузеры поддерживают нужные API, эксплуатация усложняется (главы 3–5).
• Перевод в веб — это не «перенос», а «переписывание». Готовые экраны как есть не уедут, а после сдачи появится новая постоянная статья — эксплуатация сервера. Если смета этого не учитывает, план развалится на полпути (глава 7).
• Рабочий вариант — разделение. Просмотр, агрегацию и отчёты — в веб, связь с оборудованием и ввод на площадке — оставить в Windows, связать общим API и базой данных. Начинать можно с меньшего объёма, чем при полном переводе в веб, и идти по убыванию эффекта (глава 8).

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 21, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Разбираем, что стоит за запросом «хотим в веб»

Когда приходит запрос на перевод в веб, первым делом раскладываем его на части. За словами «хотим в веб» обычно стоит одно из трёх (или несколько сразу).

(1) Хотим убрать трудозатраты на развёртывание и обновления. Типичная жалоба: «на каждую новую версию обходим все компьютеры и ставим заново». Перевод в веб это действительно закрывает, но закрыть это можно и без веба. Перейдите на способ развёртывания с автообновлением — ClickOnce или MSIX: Windows-приложением останетесь, а разворачивать почти ничего не придётся. Подробнее — в статье «Как выбрать способ развёртывания Windows-приложения». Если мотив только в развёртывании, перевод в веб — избыточная инвестиция.

(2) Хотим работать откуда угодно и с любого устройства. Несколько площадок, доступ у клиента или из дома, просмотр с планшета — здесь как раз сильная сторона веба. Но и тут стоит отдельно спросить: нужны «все функции откуда угодно» или «данные хотим видеть откуда угодно»? На практике чаще второе, и тогда хватает раздельной схемы из главы 8: в веб выносят только просмотр и агрегацию.

(3) Хотим уйти с устаревшей технологии. Звучит как «автор уволился» или «страшно оставаться на .NET Framework». Проблема настоящая, но ответ не обязан быть вебом. Если всё равно переписывать, а по характеру работы это десктоп, можно переписать на актуальном .NET, оставаясь Windows-приложением (таблица решений WinForms / WPF / WinUI). И ещё одно: веб сам по себе от устаревания не спасает. Ещё недавно на слуху были внутренние веб-системы, написанные только под IE: когда поддержку IE закрыли, им негде стало работать (см. «Как продлить жизнь внутренней веб-системе через режим IE и какой из него выход»). Веб-приложение тоже нужно сопровождать под изменения фреймворков и браузеров. «Перевели в веб» не значит «сопровождение закончилось».

После такого разбора видно, что закрывается только вебом, что закрывается и иначе, а что веб не закрывает вовсе. Дальше проверяем, нет ли функций из списка «эти лучше в веб не выносить».

У следующих случаев разная природа. Случаи 1–4 (главы 3–6) — про то, что технически веб не подходит. Случай 5 (глава 7) — про то, что путают структуру затрат. Если сработало первое, эту функцию в веб не выносят. Если сработало второе, это не повод всё останавливать: нужно поправить предпосылки сметы.

3. Случай 1: приложение напрямую связано с оборудованием и периферией

Обмен с производственным оборудованием, приём данных с измерительных и контрольных приборов, весы и сканеры штрихкода по serial (RS-232C), тонкое управление специализированными принтерами — если приложение само разговаривает с железом, эту часть в веб структурно выносить не стоит.

Причина простая: код в браузере живёт в песочнице, изолированной среде. Страница, которую только что открыли, не должна сама обращаться к файлам и устройствам на компьютере, поэтому браузер специально ограничивает доступ к локальным ресурсам. Это не дыра в вебе, а сама модель безопасности. Даже в Blazor WebAssembly, где веб-клиент пишут на C#, код выполняется внутри песочницы браузера; доступ к файловой системе и произвольное сетевое соединение дают PlatformNotSupportedException¹. Можно только то, что умеет сам браузер².

Возражение «но ведь есть Web Serial API и WebUSB, из браузера можно работать с последовательным портом» тоже слышно. API существуют, но поддерживают их не все браузеры. Web Serial API есть в Chromium (Chrome, Edge и др.), а с Firefox 151 (май 2026) — и в настольном Firefox. Safari по-прежнему нет (на мобильных Chrome для Android умеет serial лишь частично, через Bluetooth). WebUSB до сих пор только в Chromium³. Главный плюс веба — «откроется в любом браузере» — вы сами сужаете. Плюс при подключении устройства (как минимум в первый раз и при каждом новом приборе) пользователь должен в диалоге браузера выбрать устройство и дать разрешение. Как средство связи с оборудованием в бизнес-системе это часто просто не окупается.

Совместимость браузеров из этого раздела — быстро меняющиеся и короткоживущие сведения (поддержка Web Serial API в Firefox тоже появилась недавно). Не используйте формулировки статьи как есть: перед решением смотрите раздел Browser compatibility на страницах соответствующих API на MDN. А вот принцип «песочница ограничивает доступ к локальным ресурсам» — это модель, и за короткое время она не изменится.

Есть и обход «веб-приложение плюс агент интеграции, который постоянно работает на каждом компьютере». Но тогда Windows-программа, которую нужно разворачивать и обновлять, всё равно остаётся. Само по себе это не плохо: по сути это одна из форм раздельной схемы из главы 8. На этапе планирования нужно честно сказать: это уже не та надежда, с которой начинали — «после перевода в веб на компьютеры ничего ставить не придётся».

По проектированию связи с оборудованием см. также «Как проверять и показывать состояние внешнего оборудования».

4. Случай 2: тесная связь с локальными файлами и другими приложениями

Следующий частый случай — когда ядро работы завязано на файлы на компьютере и на другие программы.

• Мониторинг общей или локальной папки: появился файл — его автоматически обрабатывают
• Пакетное преобразование, переименование, разбор по папкам сотен и тысяч файлов
• Запуск Excel и сборка отчёта через COM, стыковка с уже существующими макросами Excel
• Обмен данными с другими бизнес-приложениями через файлы или межпроцессное взаимодействие

У браузера доступ к файлам по умолчанию ограничен тем, что пользователь сам выбрал в диалоге в этот момент. Пакетный доступ без действий пользователя и мониторинг, который продолжает работать при закрытом браузере, невозможны. File System Access API позволяет ходить по выбранной пользователем папке; есть и экспериментальный API (FileSystemObserver), который следит за изменениями в этой папке, пока страница открыта. Но и то и другое — только Chromium⁴, та же проблема «привязки к поддерживаемым браузерам», что и со связью с оборудованием. Запустить из браузера другой локальный процесс (Excel и т. п.) и им управлять нельзя вовсе.

Если такие функции переносить в веб, придётся менять сам процесс: «пользователь загружает файлы на сервер, обработка идёт на сервере». Если бизнес в такой логике живёт — вариант. Но если повседневно работают с файлами на гигабайты, данные нельзя выпускать за периметр и всё обрабатывается локально, или система плотно сцеплена с наработками в Excel, эту часть разумнее оставить Windows-приложением (а для обработки без человека — мониторинг папки, пакетные задачи — Windows-службой). Отдельно следите, куда кладёте COM-связь с Excel. Microsoft не рекомендует и не поддерживает автоматизацию Office из сред без пользователя и без UI, в том числе из служб⁵. Код, который сам управляет Excel, держите в настольном приложении, где пользователь вошёл в систему, либо перепишите чтение и запись на библиотеки Open XML, без запуска Office. Как строить выгрузку в Excel — в «Как формировать отчёты в Excel», мониторинг папки — в «Безопасные основы FileSystemWatcher».

5. Случай 3: работа на площадке с нестабильной сетью, где процесс нельзя останавливать

Веб-приложение по устройству живёт, пока жива сеть. Это верно и для приложений с серверным рендерингом, и для популярного в мире C# Blazor Server: каждое действие в UI идёт через постоянное соединение с сервером, поэтому если связь пропала, приложение останавливается. В официальной документации прямо сказано: офлайн не поддерживается².

Это становится проблемой в таких условиях:

• Завод, склад, улица: Wi-Fi режут металлические стеллажи и станки, короткие обрывы — норма
• Линия, которую нельзя останавливать: экран записи или указаний завис на несколько минут — уже сказывается на производстве или отгрузке
• Площадка с тонким или нестабильным каналом: временный офис на мобильном интернете, судно, горы

Нативное Windows-приложение естественно собирается так: данные лежат локально, в офлайне работа продолжается, после восстановления канала — синхронизация. Офлайн-работу сама Microsoft называет одной из причин выбирать нативное приложение⁶. Сделать веб-приложение офлайн-способным технически можно — PWA (Service Worker) или данные на клиенте, — но синхронизация и разбор конфликтов тянут заметные дополнительные вложения. Это уже против исходной надежды «переведём в веб — станет дешевле».

Вопрос для решения: «если сеть пропадёт на 30 минут, эта работа может подождать?» Если нет, экран, который её ведёт, должен работать локально — как минимум он.

6. Случай 4: в центре работы — быстрый массовый ввод с клавиатуры

Ввод накладных, регистрация проверки и отгрузки, экран оператора колл-центра — работа, где человек весь день сидит за одним экраном и гоняет большие объёмы данных, в основном с клавиатуры. Здесь десктопный UI уже очень зрелый, и после перевода в веб субъективное качество часто падает.

• Задержка отклика. В схеме с постоянным соединением с сервером, как у Blazor Server, в каждое действие пользователя вклинивается круговой обмен по сети, задержка UI растёт². Даже десятки миллисекунд на одно действие при тысячах операций за день ощущаются как «подтормаживание».
• Поведение клавиатуры. Переход по полям по Enter, назначение функциональных клавиш, проверка прямо во время ввода — для ввода данных это «так и должно быть». В браузере это приходится собирать, конфликтуя с его значениями по умолчанию (Enter отправляет форму, F1 открывает справку и т. п.). Сделать можно, но вы доплачиваете, чтобы догнать качество, которое десктопный фреймворк и грид дают сразу.
• Грид на больших данных. Чтобы в вебе получить грид уровня десктопа — плавная виртуальная прокрутка на десятках тысяч строк, правка ячеек, закрепление столбцов, копирование и вставка, — нужен мощный коммерческий компонент и немалая настройка.

Для просмотра, согласования и редкой регистрации веб-формы хватает. Но экран, где скорость ввода напрямую связана с производительностью, стоит трезво проверить: люди реально получат плюс «можно открыть откуда угодно» — или этим экраном всё равно пользуются только с фиксированного места в офисе? Если место фиксировано, перевод в веб ничего не даёт, только отнимает.

7. Случай 5: в смете закладывают «перенос», а по факту начинают переписывание

До сих пор речь шла о функциях и о том, как приложением пользуются. Теперь — о структуре затрат. Типичный развал плана перевода в веб: считают как «перенесём то, что есть, в веб», а потом выясняется, что это было переписывание.

• Готовые экраны с собой не уедут. Реалистичного способа автоматически превратить описания и логику экранов WinForms или WPF в веб нет: UI проектируют и пишут заново, экран за экраном. Число экранов, умноженное на сложность, и есть трудозатраты.
• Сначала нужна инвентаризация бизнес-логики. В приложениях с долгой жизнью правила, которых нет в спецификации, нередко живут только в коде. Перевод в веб включает работу: всё это вытащить и реализовать снова. Здесь прямо ложится принцип «не переписывать всё сразу», о котором мы писали в статье про миграцию бизнес-приложений на VB6 / Access.
• После сдачи эксплуатация структурно дорожает. Десктопное приложение — это забота о компьютерах. Веб-приложение добавляет постоянную работу: разворачивать, мониторить, бэкапить сервер (или облако), обновлять сертификаты и закрывать дыры. Если своей команды на это нет, каждый месяц уходит внешним подрядчикам. Сравнивать стоимость перевода в веб нужно не только по первоначальной разработке, но и по этим текущим затратам.
• Меняется исходная точка по безопасности. Пока приложение жило только в корпоративной LAN, одно. Как только его вынесли в веб и открыли доступ снаружи, планка по аутентификации, авторизации, шифрованию канала и защите от атак поднимается на ступень. Это тоже часть «стоимости перевода в веб».

Для внутреннего согласования и сравнения вариантов удобно привести к одной форме.

Итого = первоначальная разработка (трудозатраты на переписывание) + ежемесячная эксплуатация × 12 × ожидаемые годы жизни + разовые затраты переходного периода (перенос данных, обучение, период параллельной работы)

Главное — сравнивать варианты на одном горизонте лет. «Перевод в веб» и «модернизация Windows-приложения как есть (актуальный .NET, способ развёртывания, обновление UI)» ставят, например, на 5 лет и считают полную сумму. Если смотреть только старт, из поля зрения выпадает постоянная эксплуатация сервера; если смотреть только ежемесячный платёж — не видно масштаба переписывания. Горизонт лет лучше брать из реального цикла замены бизнес-систем: когда в компании меняли такое в прошлый раз.

Повторим: это не аргументы «веб не делать». Это материал, чтобы смета стояла на верных предпосылках. Если даже с переписыванием и текущими затратами плюсы веба всё равно больше — делайте. Если нет, сначала проверьте, не закрывает ли большую часть мотива меньшими вложениями модернизация Windows-приложения как есть (актуальный .NET, способ развёртывания, обновление UI).

8. Рабочий вариант: не сводить выбор к «всё в веб или всё в Windows»

Если сказанное выше переложить на практику, ответ чаще не «полный перевод в веб» и не «оставить как есть», а разделение.

Идея простая: таблицу из главы 1 прикладывать не к приложению целиком, а к каждой функции. Общая картина такая.

flowchart TB
    subgraph WEB["Вынести в веб — браузер"]
        W["Просмотр, поиск, агрегация<br/>скачивание отчётов, согласование<br/>ведение справочников"]
    end
    subgraph WIN["Оставить в Windows — приложение на каждом компьютере"]
        D["Связь с оборудованием и периферией<br/>мониторинг локальных файлов и пакетная обработка<br/>офлайн-работа и быстрый ввод"]
    end
    API["Общая бизнес-логика и API"]
    DB[("База данных")]
    W --> API
    D --> API
    API --> DB

Рис. 1. Общая схема раздельной архитектуры. Головной офис и другие площадки работают из браузера, площадка — из Windows-приложения; данные и бизнес-логика общие.

• Что выносить в веб: просмотр, поиск и агрегация данных, которые нужны нескольким площадкам и нескольким людям; скачивание отчётов; лёгкие операции вроде согласования. Ведение справочников обычно тоже сюда.
• Что оставлять в Windows: связь с оборудованием и периферией, мониторинг и пакетная обработка локальных файлов, работа на площадке, которую нельзя останавливать даже в офлайне, экраны быстрого ввода.
• Что делать общим: база данных и бизнес-логика. Данные сводят в одно место, веб-приложение и Windows-приложение ходят в один и тот же API (или в одну БД). Если эта часть общая, получается схема, которая закрывает большую часть мотива «хотим в веб»: «на площадке вводят в Windows-приложении, в головном офисе сразу видят в браузере».

У такой схемы есть практические плюсы, которых нет у полного перевода в веб: переписывать сразу нужно меньше, можно идти поэтапно с самых выгодных частей (просмотр) и не ломать удобство на площадке. Обратная сторона: сопровождать придётся две линии — Windows-приложение и веб-приложение. Если само приложение небольшое и почти всё сводится к просмотру, иногда честнее сразу сделать полный перевод в веб. И здесь тоже не «или-или», а степень.

Отдельно: если требование звучит как «экраны хотим на веб-технологиях, но к локальным ресурсам тоже нужен доступ», есть гибридный путь — Electron или Blazor Hybrid (WebView2). UI на веб-технологиях без ограничений песочницы браузера. Но это настольное приложение, которое нужно разворачивать, и на запрос «хотим только из браузера» это не ответ.

9. Чек-лист до решения о переводе в веб

Перед запросом сметы и внутренним согласованием стоит пройти список — меньше потом переделывать.

1. Разложить мотив. Что на самом деле болит: развёртывание, место работы или устаревшая технология? Если только развёртывание — не хватит ли смены способа развёртывания?
2. Связь с оборудованием. Есть ли прямой обмен с serial/USB, измерительными приборами, специализированными принтерами? Если да, сначала решите, что с этой частью делать (оставить в Windows / схема с агентом).
3. Зависимость от локальных ресурсов. Есть ли мониторинг папки, пакетная обработка файлов, обмен с процессами вроде Excel? Можно ли переложить процесс на обработку на сервере?
4. Офлайн. Если сеть пропадёт на 30 минут, эта работа может подождать?
5. Доля ввода. Есть ли экран, за которым весь день печатают? Им правда будут пользоваться «откуда угодно»?
6. Кто, откуда, что делает. Кто, откуда и что хочет видеть или вводить? «Всем все функции снаружи компании» или «головному офису просто нужны данные»?
7. Кто будет эксплуатировать. Кто разворачивает, мониторит и обновляет сервер по безопасности? Сколько это в месяц?
8. Где живёт бизнес-логика. Спецификация совпадает с кодом? Срок на инвентаризацию заложили в смету?

Если из пунктов 2–5 что-то срабатывает, лучше опираться не на полный перевод в веб, а на раздельную схему. Общую подготовку перед заказом см. также в «Что прояснить перед заказом внешней разработки Windows-приложения».

Итог

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

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

Связанные статьи

• Что прояснить перед заказом внешней разработки Windows-приложения
• Продление жизни и миграция бизнес-приложений на VB6 / Access — таблица решений «оставить, обернуть или заменить»
• Таблица решений WinForms / WPF / WinUI
• Как выбрать способ развёртывания Windows-приложения (MSI / MSIX / ClickOnce / xcopy / свой updater)
• Как продлить жизнь внутренней веб-системе через режим IE и какой из него выход
• Как проверять и показывать состояние внешнего оборудования
• Безопасные основы FileSystemWatcher
• Как формировать отчёты в Excel

Связанные направления консультаций

KomuraSoft LLC консультирует по вопросам: стоит ли переводить существующее Windows-приложение в веб, как спроектировать раздельную архитектуру веб + Windows, как разрабатывать и дорабатывать бизнес-приложения со связью с оборудованием и локальной обработкой.

• Разработка Windows-приложений
• Доработка и сопровождение существующих Windows-программ
• Техническая консультация и разбор архитектуры
• Связаться с нами

Источники

Похожие статьи

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

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Если мы всё равно обновляем старое Windows-приложение, не перевести ли его заодно в веб?

Переводить в веб только потому, что приложение «старое», мы не рекомендуем. По трудозатратам это ближе к переписыванию, чем к переносу, а веб-приложения тоже устаревают (типичный пример — внутренняя веб-система, которая так и осталась только под IE). Смотреть нужно не на возраст технологии, а на то, как приложением пользуются. Если им работают с нескольких площадок и хочется меньше сопровождать клиентские машины, плюсы перевода в веб есть. Но если в центре — связь с оборудованием или обработка локальных файлов, чаще выгоднее модернизировать Windows-приложение как есть: перейти на новую версию .NET, обновить UI.

Разве после перевода в веб не исчезнут установка и развёртывание на компьютерах?

На клиентах ставить ничего не придётся, но если цель только в этом, есть более лёгкий путь, чем перевод в веб. Смените способ развёртывания на тот, где обновления ставятся сами — ClickOnce или MSIX: Windows-приложением вы останетесь, а обходить каждое устройство с установщиком почти не придётся. Зато после перевода в веб появляется новая постоянная работа: разворачивать, мониторить и обновлять по безопасности сервер (или облако). Считайте и то, что уходит, и то, что появляется.

Можно ли перевести в веб только часть приложения?

Можно, и на практике чаще именно так и выходят из положения. Типичная схема: просмотр данных, агрегацию, отчёты и доступ с нескольких площадок вынести в веб, а связь с оборудованием, быстрый ввод на площадке и обработку локальных файлов оставить Windows-приложением и связать обе части общим API и базой данных. Переписывать сразу всё не нужно, и можно идти поэтапно — с тех частей, где перевод в веб даёт наибольший эффект.

А промежуточные варианты вроде Electron, PWA или Blazor Hybrid?

Здесь смешаны разные вещи, их нужно развести. Electron и Blazor Hybrid (WebView2) работают как настольные приложения: к файлам и устройствам ходят без ограничений песочницы браузера, а экраны можно писать веб-технологиями. Но разворачивать и обновлять их всё равно нужно, и на запрос «пусть работает только из браузера» это не ответ. PWA можно закрепить на панели задач и пользоваться почти как установленной программой, но внутри это по-прежнему веб-приложение в браузере, с теми же ограничениями доступа к локальным ресурсам. Сначала разберите, какую именно проблему вы хотите закрыть переводом в веб.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.