Несколько лет назад я присутствовал на встрече разработчиков, где один из участников задал, казалось бы, простой вопрос: «А какой фреймворк выбрать для написания десктопного приложения под Windows?»
Воцарилась мёртвая тишина. Спустя какое-то время, кто-то предложил WPF. Ещё один человек назвал WinUI 3. Третий упомянул Electron. В итоге беседа ушла в сторону, и ответ на поставленный вопрос так и не был дан.
В этой статье я буду говорить о причинах той воцарившейся тишины, поведав историю, которая началась тридцать с лишним лет назад.
Если вы в течение десяти секунд не можете ответить на вопрос «Какой подход будет оптимальным для разработки UI на платформе X?», значит, эта платформа сильно заплутала на своём пути. Пора тормозить.
Последний раз, когда для Windows можно было дать конкретный ответ
В 1988 году Чарльз Петцольд выпустил книгу «Programming Windows» объёмом 852 страницы. Это была инструкция о том, как писать программы для Windows с помощью API Win16 на C. И среди огромного объёма материала она содержала одну важную вещь: целостный и уверенный ответ на вопрос о том, как правильно писать приложение под Windows. В бизнесе мы называем это «стратегией».
Появившийся следом интерфейс Win32 был уже масштабнее, но всё такой же связный и последовательный. Циклы сообщений, оконные процедуры, GDI. Сама ментальная модель была странноватой, но зато целостной. Петцольд всё объяснял. Это была своеобразная формула F=MA для Windows. Простая. Мощная. Вы её осваивали. Использовали. Добивались успеха.
Ясность — ваш друг! Одна ОС, один API, один язык, одна книга. Не было никакого комитета, который бы спорил о применении альтернатив на основе управляемого кода. Был только Win32 и Петцольд. И всё работало. Это была физика, а не химия (когда что-то работает только для этого элемента таблицы Менделеева. Только при определённом давлении и определённой температуре. И только, если Луна находится в седьмом доме Юпитера).
Далее же мы наблюдали показательный пример того, как компания с умнейшими специалистами и огромными ресурсами может в течение тридцати лет творить несуразицу,* оптимизируя продукт не под те задачи. Иначе говоря, это был пример того, как умнейшие люди делают глупые вещи.
*Прим. пер.: в оригинале автор использует оригинальный термин boof-a-rama. По тексту он переведён контекстуально в соответствии с предполагаемым смыслом.
Объектно-ориентированный делирий (1992—2000)
У Win32 были реальные ограничения, поэтому в Microsoft сделали то, что делали всегда: к моменту конференции разработчиков они приготовили некое новшество. Несколько новшеств.
В 1992 году было решено завернуть Win32 в C++ с помощью библиотеки MFC. Win32 сам по себе выглядел невзрачно, а в одеянии MFC он будто нарядился в смокинг, сшитый из других смокингов. Потом появились технологии OLE, COM, ActiveX. Ни одна из них не являлась настоящим фреймворком для GUI — это были компонентные архитектуры — но они проникли во все уголки разработки под Windows, создав такой уровень когнитивной сложности, после которого даже Кьеркегор покажется Хэмингуэем.
В конце девяностых я прослушал целый доклад на конференции, стараясь понять разницу между документом OLE, объектом COM и управляющим элементом ActiveX. Я весь час смотрел на выступающего с недоумением, будто у него изо рта торчал крысиный хвост.
Microsoft продавала не целостную историю, а технологические примитивы, предлагая разработчикам разбираться с ними самостоятельно. Это был ключевой доклад конференции, по сути, о бардаке — для компании было важнее впечатлить публику ярким выступлением одного из директоров, нежели обеспечить реальную пользу для конечных потребителей или разработчиков.
PDC 2003 и видение, которое утонуло само в себе
На конференции PDC 2003 Microsoft презентовала Longhorn — поистине одну из самых убедительных технических концепций, какие компания предлагала разработчикам. В её основе лежало три столпа: WinFS (реляционная файловая система), Indigo (унифицированная система коммуникаций) и Avalon — позднее WPF — векторная подсистема UI с аппаратным ускорением на GPU и управляемая декларативным языком XAML. Разработчики оказались потрясены демонстрацией возможностей Avalon. Это было правильное видение.
А ещё, как его описал Джим Аллчин во внутренней записке от января 2004, это была неповоротливая, тяжёлая «свинья».
К августу 2004 компания объявила о полном перезапуске разработки. Было решено начать с переписывания кодовой базы Server 2003. После перезапуска руководство выпустило негласное распоряжение: «никакого нахрен управляемого кода в Windows!». Весь новый код писался на C++. Как результат, WPF включили в Vista, но сама оболочка ОС продолжила использовать старые решения.
После этого инцидента у команды Windows возникла к .NET стойкая неприязнь, которая сохранилась надолго. Они считали, что ставка на новый фреймворк с управляемым кодом привела к самому позорному провалу в истории компании. Эта неприязнь породила внутреннюю тринадцатилетнюю войну между разработчиками Windows и командой .NET. В конечном итоге WPF осталась не у дел, Silverlight загнулась, UWP не взлетела, и в экосистеме GUI возник тот хаос, который мы наблюдаем сегодня.
Silverlight: паттерн закрепился (2007—2010)
WPF вышла в конце 2006 года. Проект был выдающимся — здесь вам и XAML, и рендеринг на GPU, и реальная привязка данных. Если бы только в Microsoft сделали на нём уверенную ставку и хорошенько вложились, исход мог оказаться совсем иным. Но вместо этого компания в 2007 году запустила Silverlight — облегчённый плагин для браузера, который должен был составить конкуренцию Flash. Он был кроссплатформенным, элегантным и лёг в основу Windows Phone. К 2010-му году этот фреймворк уже выглядел как решение, за которым стоит будущее функциональных клиентских приложений.
Вот только позднее на конференции MIX 2010 представитель Microsoft, отвечая на вопросы, сказал, что Silverlight больше не рассматривается как кроссплатформенный стандарт и предполагается только для Windows Phone. Компания свернула в сторону HTML5. Причём команду Silverlight об этом не предупредили. И разработчики, которые выбрали его в качестве основы для своих бизнес-приложений, тоже узнали об этом повороте только из конференции.
Так что Silverlight оказался загублен не техническим провалом. Сама технология была в порядке. Его убило стратегическое решение, о котором разработчики узнали последними.
Запомните этот паттерн. Он ещё повторится.
Паника вокруг Metro и война двух команд (2012)
На тот момент компания Apple продала 200 миллионов iPhone, а их iPad начали отъедать часть рынка ПК. Ответом со стороны Microsoft стала Windows 8 с её концепцией Metro. В основу этой версии легла среда выполнения WinRT, ориентированная на сенсорный ввод и намеренно реализованная не на базе .NET. Помните про разногласия между командами? Вот вам одно из их проявлений. WinRT была реализована как нативная среда выполнения на C++, резко отойдя от WPF, WinForms и десятилетий разработки под .NET.
Тогда в Microsoft параллельно развивалось две истории. Команда Windows создавала WinRT, а команда .NET всё также проповедовала идею WPF. Разные подразделения, разные вице-президенты, разные стратегические планы.
В итоге на конференции //Build 2012 разработчики услышали такие тезисы: будущее за WinRT; акцент на HTML+JS; .NET продолжает жить; C++ возвращается; вам также нужно писать приложения под Metro; ваш код для WPF продолжит работать. Это не стратегия. Это этап «Голодных игр», когда шесть команд яростно сражаются за получение вашего внимания.
Корпоративные разработчики взглянули на реализованную в UWP изоляцию приложений, требование распространять их только через Store, отсутствие API Win32, после чего развернулись и ушли. Фреймворк, созданный с целью затянуть их в новую парадигму разработки, был оптимизирован под магазин приложений для планшетов, который так и не увидел свет.
UWP и разрастание WinUI (2015 — сегодня)
В Windows 10 появилась Universal Windows Platform с лозунгом — пиши один раз, запускай на ПК, смартфоне, Xbox и HoloLens. На бумаге всё выглядело весьма заманчиво. Но была одна проблема: Windows Phone умирала, а флагманские приложения Microsoft — Office, Visual Studio, да и сама оболочка — UWP не использовали. Перспективы стали очевидны, хотя вслух их никто не озвучивал.
Когда UWP забуксовала, официальные рекомендации стали расплывчатыми и ситуативными. Используйте UWP для новых приложений; оставляйте WPF для существующих; добавляйте современные API через XAML Islands; ожидайте появления WinUI 3; вообще-то есть WinUI 2, но он только для UWP; Project Reunion всё исправит, вот только мы переименовываем его в Windows App SDK, и он всё равно не заменит UWP полноценно; и так далее…
Умнейшие люди делают глупые вещи. Какое-то броуновское движение в мире технологий.
Project Reunion и WinUI 3 действительно представляют прогресс. Но задайтесь вопросом, откуда вообще взялась проблема? Средства управления UWP были привязаны к ОС, потому что ими полностью владела команда Windows. Ни команда .NET. Ни команда DevDiv. В этом свете Project Reunion стала организационным костылём, преподнесённым как техническое решение.
Вот выдержка из отчёта одного разработчика, который он написал в 2024: «Я прошёл через все постоянные изменения траектории Microsoft: UAP, UWP, замена C++/CX на C++/WinRT без поддержки инструментов, XAML Islands, XAML Direct, Project Reunion, перезапуск WinAppSDK, хаотичный переход от WinUI 2.0 к 3.0…». Четырнадцать лет. Четырнадцать крутых поворотов. Этот человек заслуживает медали и извинений — именно в таком порядке.
Зоопарк без смотрителя
Перечислю все технологии для создания GUI, которые сегодня поставляются с Windows.
Нативные фреймворки Microsoft:
Win32 (1985) — по-прежнему в деле. Книга Петцольда до сих пор актуальна.
MFC (1992) — C++ обёртка для Win32. В режиме поддержки. Используется в корпоративной среде и CAD.
WinForms (2002) — обёртка .NET для Win32. «Доступна, но устарела». По-прежнему самый быстрый механизм обработки форм для ввода данных.
WPF (2006) — XAML, отрисовка через DirectX, открытый исходный код. Находится в режиме поддержки, без нововведений.
WinUI 3 / Windows App SDK (2021) — «современное» решение. Планы развития туманны.
MAUI (2022) — кросс-платформенный последователь Xamarin.Forms. Текущий приоритет команды .NET.
Microsoft web-hybrid:
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/JavaScript. Серьёзный кроссплатформенный вариант.
React Native для Windows — порт мобильного фреймворка Facebook, разработанный при поддержке Microsoft.
Avalonia — духовный наследник WPF с открытым исходным кодом. Используется платформами JetBrains, GitHub, Unity — то есть теми разработчиками, которые устали ждать Microsoft.
Uno Platform — WinUI API для любой платформы. Ориентированы на развитие WinUI больше, чем Microsoft.
Delphi / RAD Studio — всё ещё на плаву, по-прежнему отличается высокой скоростью и используется при создании специализированных приложений.
Java Swing / JavaFX — да, до сих пор в продакшене. Корпоративный сектор без них никуда.
Семнадцать разных подходов. Пять языков программирования. Три философии рендеринга. Это не платформа. У меня нет отдельного словарного определения для таких вещей, кроме как цирк.
Выводы
В корне провал любого проекта для разработки GUI был вызван одной из трёх причин: внутренние разногласия (Windows против .NET), объявление на конференции разработчиков, породившее преждевременный интерес к платформе (Metro, UWP) или же стратегический поворот, который подставил разработчиков без какого-либо предупреждения (Silverlight). Ничто из этого не стало следствием технического провала. Сами технологии зачастую были действительно хороши — WPF была хороша, Silverlight был хорош, и XAML тоже. Проблема крылась в организационных моментах.
У вас есть либо Реалистичная теория успеха, включающая весь жизненный цикл продукта — внедрение, инвестирование, обслуживание и миграцию — либо громкое заявление для конференции разработчиков.
Первое называется стратегией, а второе — затяжным цирком.
Стараясь поспеть за каждым объявленным Microsoft нововведением, Чарльз Петцольд написал шесть редакций «Programming Windows». Последняя была посвящена WinRT для Windows 8. Это был 2012 год.
И я его нисколько не виню.