Создатель PowerShell объяснил, почему у Microsoft нет стратегии GUI уже 30 лет
Изобретатель PowerShell разобрал, как внутренняя война команд Windows и .NET породила 17 GUI-фреймворков — и ни одного внятного ответа для разработчиков.
Несколько лет назад на совещании в Microsoft кто-то задал простой вопрос: «Какой фреймворк выбрать для нового десктопного Windows-приложения?» Повисла тишина. Один предложил WPF. Другой — WinUI 3. Третий спросил, не взять ли Electron. Совещание ушло в сторону, и на вопрос так никто не ответил.
Эту историю рассказал Jeffrey Snover — изобретатель PowerShell, бывший Distinguished Engineer и Technical Fellow в Microsoft. Его тезис: у Microsoft нет связной стратегии GUI-разработки уже более 30 лет. Последний раз внятный ответ на вопрос «как писать под Windows» существовал в 1988 году.
Ключевые выводы
- Последняя связная стратегия GUI Windows — книга Петцольда 1988 года (Win32 API)
- С тех пор Microsoft выпустила 17+ GUI-фреймворков, ни один не стал единственным ответом
- Корневая причина — не технические провалы, а внутренняя война команд Windows и .NET
- Каждый «новый ответ» (WPF, Silverlight, UWP, MAUI) убивался политикой или сменой стратегии
- Сегодня самый популярный GUI-фреймворк на Windows — Electron. Microsoft к этому не имеет отношения
1988: последний раз, когда ответ был один
В 1988 году Чарльз Петцольд выпустил Programming Windows — 852 страницы, Win16 API на C. Одна книга, один API, один язык — и это работало. Win32 был сложнее, но оставался единой моделью: циклы сообщений, оконные процедуры, GDI. Сновер называет это «F=ma для Windows» — просто, мощно, предсказуемо.
Когда платформа не может ответить на вопрос «как мне написать UI?» за десять секунд — она провалила своих разработчиков. Точка.
Эта ясность работала, потому что стимулы совпадали: новая версия Windows → новые возможности для разработчиков → приложения, которым нужно новое железо → продажи финансируют следующий цикл. Разрыв этой цепочки и стал корневой причиной 30-летнего хаоса.
2003–2006: WPF и гражданская война внутри Microsoft
На PDC 2003 Microsoft показала Longhorn — одну из самых убедительных технических демонстраций в истории компании. Три столпа: WinFS (реляционная файловая система), Indigo (коммуникации) и Avalon (позднее WPF) — GPU-ускоренный UI на декларативном XAML. Разработчики были в восторге.
К августу 2004 года проект полностью сбросили — по словам вице-президента Джима Аллчина, Longhorn превратился в «свинью», которую невозможно довести до релиза. Начали заново с кодовой базы Server 2003. Руководство Windows выпустило тихую директиву: никакого managed-кода в Windows. Новый код — только на C++. WPF вышел вместе с Vista, но сама оболочка Windows его не использовала.
Обида команды Windows на .NET не зажила. С их точки зрения, ставка на managed-код привела к самому позорному провалу в истории компании. Эта обида породила 13-летнюю гражданскую войну между командами Windows и .NET — которая в итоге осиротила WPF, убила Silverlight, обрекла UWP и создала тот хаос с GUI-фреймворками, который мы видим сегодня.
Silverlight: паттерн установлен (2007–2010)
WPF вышел в 2006-м. Если бы Microsoft сделала его единственным ответом и инвестировала непрерывно — история могла бы сложиться иначе. Вместо этого в 2007-м запустили Silverlight — браузерный плагин-конкурент Flash, кроссплатформенный и элегантный.
В 2010-м на конференции PDC 2010 менеджер Microsoft заявил в Q&A, что Silverlight — не кроссплатформенная стратегия, а инструмент для Windows Phone. Отныне политика — HTML5. Команду Silverlight не предупредили. Разработчики, поставившие бизнес-приложения на Silverlight, узнали об этом из Q&A на конференции.
Silverlight убила не техническая проблема. Технология была хорошей. Её убило бизнес-решение, и разработчики узнали последними. Запомните этот паттерн — он повторится.
Metro, UWP и бесконечный спрол (2012–2025)
Apple продала 200 млн iPhone. Microsoft ответила Windows 8 и Metro — touch-first рантайм WinRT, намеренно не построенный на .NET. Помните обиду команды Windows? Вот она в действии. WinRT — нативный C++ рантайм. Чистый разрыв с WPF, WinForms и десятилетием инвестиций разработчиков в .NET.
На //Build 2012 разработчики услышали: будущее — WinRT, а ещё HTML+JS — первый класс, а ещё .NET работает, а ещё C++ вернулся, а ещё пишите Metro-приложения, а ещё WPF никуда не делся. Это не стратегия — это Голодные Игры, где шесть команд борются за ваше внимание.
Потом пришёл UWP (2015) — «пиши один раз, запускай на ПК, телефоне, Xbox, HoloLens». На бумаге убедительно. Проблема: Windows Phone умирал, а собственные флагманские приложения Microsoft — Office, Visual Studio, оболочка — не использовали UWP.
Когда UWP забуксовал, официальный ответ стал «зависит от ситуации»: используй UWP для нового, WPF для старого, добавь XAML Islands, подожди WinUI 3, но WinUI 2 — это для UWP, а Project Reunion всё починит, только мы переименовали его в Windows App SDK, и он до сих пор не заменяет UWP полностью...
Зоопарк без смотрителя: 17 фреймворков
Вот что реально используется для GUI на Windows сегодня — Сновер насчитал 17 подходов:
Нативные фреймворки Microsoft
- Win32 (1985) — живёт. Петцольд до сих пор актуален
- MFC (1992) — C++-обёртка над Win32. Режим поддержки. Живёт в enterprise и CAD
- WinForms (2002) — .NET-обёртка. «Доступен, но не рекомендуется». Всё ещё быстрейший для data-entry форм
- WPF (2006) — XAML, DirectX-рендеринг, open source. Новых инвестиций от Microsoft нет
- WinUI 3 / Windows App SDK (2021) — «современный» ответ. Роадмап неясен
- MAUI (2022) — кроссплатформенный наследник Xamarin. Текущая ставка команды .NET
Веб-гибриды Microsoft
- Blazor Hybrid — .NET Razor-компоненты в нативном WebView
- WebView2 — встроенный Chromium в Win32/WinForms/WPF
Сторонние фреймворки
- Electron — Chromium + Node.js. VS Code, Slack, Discord. Самый популярный десктопный GUI на Windows — и Microsoft к этому не имеет отношения
- Flutter (Google) — Dart, собственный рендерер, кроссплатформа
- Tauri — Rust-бэкенд, лёгкая альтернатива Electron
- Qt — C++/Python/JS. Серьёзный кроссплатформенный вариант
- Avalonia — open-source духовный наследник WPF. Используют JetBrains, GitHub, Unity — разработчики, которые устали ждать Microsoft
- Uno Platform — WinUI API на всех платформах. Более привержены WinUI, чем сама Microsoft
- React Native for Windows — порт мобильного фреймворка Facebook, поддерживается Microsoft
- Delphi / RAD Studio — жив, быстр, до сих пор в вертикальном ПО
- Java Swing / JavaFX — да, всё ещё в продакшене. Enterprise не забывает
17 подходов. Пять языков программирования. Три философии рендеринга. Это не платформа.
Урок: провалы были организационными, не техническими
Каждая провалившаяся GUI-инициатива Microsoft прослеживается к одной из трёх причин:
- Внутренняя политика команд — война Windows vs .NET определяла технические решения
- Анонс на конференции вместо стратегии — Metro и UWP родились из желания произвести впечатление на keynote, а не из потребностей разработчиков
- Разворот бизнес-стратегии — Silverlight убили без предупреждения, разработчики узнали последними
Ни одна из причин — не техническая. Технологии часто были хороши: WPF был хорош, Silverlight был хорош, XAML хорош. Организационный провал — вот настоящий продукт.
Либо у вас есть правдоподобная теория успеха, покрывающая весь жизненный цикл — adoption, инвестиции, поддержку и миграцию — либо у вас есть keynote на конференции для разработчиков. Одно — стратегия. Другое — 30-летний бардак.
Петцольд написал шесть изданий Programming Windows, пытаясь успеть за каждым новым анонсом Microsoft. Он остановился после шестого — о WinRT для Windows 8. Это был 2012 год. Сновер его не винит.
Часто задаваемые вопросы
Какой фреймворк выбрать для нового Windows-приложения в 2026?
Единого ответа нет — в этом и проблема. Для кроссплатформы: Electron, Tauri, Flutter, Avalonia. Для Windows-only enterprise: WPF (зрелый) или WinUI 3 (если верите в роадмап). Для быстрых форм ввода данных: WinForms. Для .NET-кроссплатформы: MAUI или Avalonia.
Почему Microsoft не может выбрать один фреймворк?
По мнению Сновера — внутренняя конкуренция команд. Команда Windows и команда .NET десятилетиями продвигали конкурирующие решения. Каждый новый фреймворк отражал, чья команда имела политическое влияние в данный момент.
WPF ещё жив?
Да, WPF open source и работает. Но Microsoft не инвестирует в него — новых возможностей не появляется. Для новых проектов это риск: технология в режиме поддержки без активного развития.
Кто такой Jeffrey Snover?
Создатель PowerShell, бывший Distinguished Engineer и Technical Fellow в Microsoft. Один из самых влиятельных людей в истории Windows-платформы. Его мнение о GUI-стратегии Microsoft — инсайдерская оценка, а не внешняя критика.
Electron правда самый популярный GUI на Windows?
По факту — да. VS Code, Slack, Discord, Figma, Notion — все построены на Electron. Это технология Google (Chromium + Node.js), и Microsoft не имеет к ней отношения, хотя сама использует её для VS Code.
Выводы
Статья Сновера — не просто ностальгия по Win32. Это диагноз: когда организационная структура определяет технические решения, разработчики платят за это десятилетиями. 17 живых GUI-фреймворков на одной платформе — не богатство выбора, а отсутствие лидерства.
Если вы выбираете фреймворк для десктопного приложения — учитывайте не только технические характеристики, но и то, кто стоит за ним и как долго они готовы его поддерживать. История Microsoft показывает, что обещания на конференции — не гарантия.
А на чём вы пишете десктопные приложения в 2026 году? WPF, Electron, Avalonia — или что-то экзотическое? Расскажите в комментариях.
Источник: Jeffrey Snover — Microsoft Hasn't Had a Coherent GUI Strategy Since Petzold
