Microsoft-ui-xaml: Обсуждение: WinUI против ElectronJS и кроссплатформенность (улучшите WinUI, чтобы устранить причины для использования ElectronJS вместо WinUI)

То же самое касается нового приложения Xbox Beta. Он использует 400 МБ, будучи открытым как прославленный Магазин. Microsoft Store использует только 117 МБ во время работы.

Пока Microsoft не разработает кроссплатформенную структуру пользовательского интерфейса, которая позволяет использовать единый пользовательский интерфейс и дизайн управления на всех платформах, ElectronJS и ему подобные будут использоваться.

Пример удивительной скорости ElectronJS/Teams:
Во-первых, для сравнения я замерил, сколько времени требуется, чтобы открыть Microsoft Outlook и просмотреть самое последнее сообщение в папке «Входящие» (почтовый ящик, содержащий очень большое количество сообщений). Это заняло всего пару секунд — на самом деле это было так быстро, что я не мог остановить секундомер достаточно быстро, чтобы получить точное измерение.
Затем я замерил, сколько времени требуется, чтобы открыть Microsoft Teams и просмотреть самое последнее сообщение в чате с коллегой: 27 секунд! Это время может быть больше или меньше в зависимости от того, сколько сообщений и изображений существует в области чата.

( ОБНОВЛЕНИЕ 9-НОЯБРЯ-2019: _Выпущена новая версия Teams, в которой сокращается время, необходимое для просмотра самого последнего сообщения чата. Вышеупомянутый пример с 27 секундами теперь описывает предыдущую версию Teams. Спасибо сотрудникам Microsoft. участники, которые работали над этим улучшением._ )

На прошлой неделе я щелкнул значок «Справка» в Teams, затем щелкнул «Отправить отзыв» и набрал сообщение. Это было удивительно медленно: каждый раз, когда я нажимал клавишу на клавиатуре, для появления каждого символа требовалось несколько секунд! (Однако, когда я снова тестировал «Оставить отзыв» сегодня, он отставал гораздо меньше, чем на прошлой неделе, поэтому, очевидно, воспроизвести эту конкретную проблему сложно.)

Если бы Teams был написан с использованием WinUI, у него не было бы этих проблем со скоростью и различных других необычных ошибок. Например, приложения WinUI используют формат даты/времени, настроенный в параметрах Windows, тогда как Teams всегда использует формат даты/времени в 12-часовом формате США, когда для Teams установлен английский язык, и игнорирует параметры Windows. приложения должны работать. Затем я попробовал изменить язык Teams сегодня, и он сказал: «Произошла ошибка, Teams восстанавливается»_. А потом не удалось загрузить несколько изображений в сообщениях в панели чата.

Точно так же, если бы Teams был написан с использованием WinUI, он не создал бы 5 процессов Teams.

@mdtauk

Пока Microsoft не разработает кроссплатформенную структуру пользовательского интерфейса, которая позволяет использовать единый пользовательский интерфейс и дизайн управления на всех платформах, ElectronJS и ему подобные будут использоваться.

Хотя в целом я согласен, в этой истории должно быть нечто большее, потому что, например, Microsoft OneNote доступен для Windows, Android и Mac, но он не использует ElectronJS (насколько мне известно) и не страдает такой ужасной производительностью, как Команды.

@mdtauk

Пока Microsoft не разработает кроссплатформенную структуру пользовательского интерфейса, которая позволяет использовать единый пользовательский интерфейс и дизайн управления на всех платформах, ElectronJS и ему подобные будут использоваться.

Хотя в целом я согласен, в этой истории должно быть нечто большее, потому что, например, Microsoft OneNote доступен для Windows, Android и Mac, но он не использует ElectronJS (насколько мне известно) и не страдает такой ужасной производительностью, как Команды.

У Microsoft есть ресурсы для создания приложений для каждой платформы, максимально возможного совместного использования кода, но без использования общего пользовательского интерфейса.

Я хотел бы услышать любые аргументы против использования платформы Uno, ориентированной на несколько платформ (Windows, iOS, Android, Интернет), для создания высокопроизводительных пакетов приложений с использованием UWP API сейчас, WinUI позже. Он использует все Microsoft — VS, C#, Xaml, Xamarin, mono, .Net...
Не исходит ли напрямую от Microsoft основная причина, по которой некоторые избегают этого?

Я хотел бы услышать любые аргументы против использования платформы Uno, ориентированной на несколько платформ (Windows, iOS, Android, Интернет), для создания высокопроизводительных пакетов приложений с использованием UWP API сейчас, WinUI позже. Он использует все Microsoft — VS, C#, Xaml, Xamarin, mono, .Net...
Не исходит ли напрямую от Microsoft основная причина, по которой некоторые избегают этого?

Это было бы лучшим аргументом несколько лет назад, но многие компании, желающие инвестировать в создание приложения или системы, должны знать, что платформа, для которой они разрабатывают, имеет поддержку и долговечность крупной компании с огромными ресурсами, такой как Microsoft.

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

Таким образом, вы не можете обвинять новых разработчиков в переходе на веб-платформы, если они хотят запускать подключенные сервисы, или в том, что они сосредоточились на платформах, которые активно разрабатываются и, похоже, будут иметь сильную поддержку в будущем.

В то же время есть несколько крупных компаний, таких как Adobe, с устаревшими приложениями, поэтому перемещение платформ с ними будет практически невозможным. Есть также любители и предприятия с заказным программным обеспечением.

Microsoft хорошо справилась с поддержкой .NET и Win32. И WinUI может быть шансом разрешить Win32 и .NET, но с современным пользовательским интерфейсом.

Silverlight, WinRT, UWP — все было заброшено. (Я знаю, что технически это не UWP, но WinUI, скорее всего, будет рассматриваться как замена).

Zune, Windows Media Center, Windows Phone 7, Windows Phone 8, Windows 8 — подвели энтузиастов и тех, кого они пытались евангелизировать.

То, как Microsoft позиционирует WinUI, а также обеспечивает безопасность будущего Windows, будет _абсолютно важным_.

WinUI для рабочего стола выглядит многообещающе, но я чувствую, что по крайней мере часть его XAML должна работать в Интернете; WinUI в Интернете, как новый Silverlight, но работающий на .NET 5 и WebAssembly.

Silverlight, WinRT, UWP — все было заброшено. (Я знаю, что технически это не UWP, но WinUI, скорее всего, будет рассматриваться как замена).

Zune, Windows Media Center, Windows Phone 7, Windows Phone 8, Windows 8 — подвели энтузиастов и тех, кого они пытались евангелизировать.

Согласен.
Не могу поверить, что некоторые из моих приложений Silverlight (web0-приложения все еще ежедневно используются некоторыми пользователями.
Следовать за Microsoft было все труднее. Люди, стоящие за Uno Platform, разрабатывают и поддерживают ее для поддержки своего бизнеса приложений для хлеба с маслом. Это с открытым исходным кодом со многими участниками. Я чувствую, что езжу на очень хорошем автобусе с первоклассными водителями, хорошо знающими, как ориентироваться в лабиринте или беспорядке Microsoft.

Мои 2 цента: единственная надежда UWP и WinUI, если они быстро сделают его кросс-платформенным, веб-включенным, прежде чем от него ничего не останется.
Платформа Uno — это быстрый, простой и, возможно, самый безопасный способ добиться этого.
Как упомянул @zipswich , Uno всегда была Microsoft; в руководствах по кодированию, инструментах, выборе языка и рендеринге, а также готов к дизайну Fluent.
Например, он в 100 раз более ориентирован на Microsoft, чем Xamarin. Не говоря уже о React или Electron и всех уродливых технологиях HTML, CSS или JS, которыми MS так одержимо льстить и обманывать.

И позвольте мне быть резким, C # - это всего лишь серверный язык с отсутствием в .NET Standard инфраструктуры пользовательского интерфейса.
Чем дольше это будет продолжаться, Dart или другие технологии станут серверными языками и полностью возьмут верх.
Вы видите, что люди готовы использовать неприятные языки (JS) в качестве жертвы, чтобы иметь возможность использовать кодовую базу на одном языке как на клиенте, так и на сервере. C# может исчезнуть так же, как XAML, или он может выиграть вместе с XAML, если будет предоставлено экстренное спасение.

Я не верю, что за Uno будущее. Он очень похож на Xamarin.Forms, являясь урезанным фреймворком Xaml с множеством недостающих функций и добавлением множества сложных дополнительных вещей, позволяющих каким-то образом интегрировать его на все платформы, с некоторыми хаками и обходными путями. Конечно, вы можете его использовать, но вы очень ограничены в том, какие элементы управления у вас есть и какие API вы можете использовать. Основная проблема заключается в том, что он пытается реализовать пользовательский интерфейс Xaml с собственными элементами управления каждой платформы. Это всегда проблематично и оставляет вам лишь небольшой набор функций, которые работают на всех платформах.

Будущее будет заключаться в использовании реального WinUI и предоставлении реального средства визуализации для каждой платформы, реализованного в собственном 3D-движке платформы. Это дало бы нам полный набор функций, все преимущества WinUI, работу с собственной производительностью, кроссплатформенность.

На самом деле у Microsoft уже было что-то подобное, работающее очень хорошо: пользовательский интерфейс UWP был основан в основном на коде Silverlight, и у Microsoft были плагины Silverlight для всех основных платформ, что означает, что у них уже есть базовые механизмы рендеринга для всех этих платформ. Они не актуальны, так как на данный момент UWP имеет множество дополнений по сравнению с Silverlight. Но это база, на которую можно опираться.

У Microsoft наверняка есть ресурсы, чтобы осуществить это. Это то, чего хотят люди, и это то, что они должны делать.

C# может исчезнуть так же, как XAML >

Определенно не согласен с этим утверждением относительно C#. C# намного больше, чем XAML. Если вы следите за Blazor, вы знаете, что это не может быть правдой. Я вижу, что Blazor меняет правила игры для меня, в первую очередь использующего UWP / Xamarin, и для разработчиков C# в целом, специально ориентированных на бизнес-пользователей.

Было бы неплохо иметь x-платформу WinUI, но я думаю, что самый простой путь к веб-платформе / x-платформе — это Blazor, особенно теперь, когда Blazor также поддерживает частичные классы, что означает, что я могу взять большую часть моего существующего кода как есть и начать использовать его в Блейзор. Пара заминок может быть альтернативой Sqlite, Shared Projects и ReactiveUI. Я должен иметь возможность использовать существующую архитектуру MVVM и довольно легко перенести ее в Blazor.

Самым главным камнем преткновения для меня является отсутствие поддержки .net core 3 в UWP. Я думаю, что для MS очень важно согласовать Blazor + UWP в опыте разработчиков. Я знаю, что команда UWP работает над этим.

Кроме того, я хотел бы видеть страницы Blazor в приложениях UWP/WInUI. Гибридная модель пользовательского интерфейса отлично подошла бы мне в приложениях UWP, чтобы я мог использовать лучшие доступные ресурсы пользовательского интерфейса. (html5 по сравнению с XAML), а также не копировать мои усилия по созданию пользовательского интерфейса между UWP и Blazor, где это имеет смысл.

В настоящее время Electron использует Javascript, HTML + CSS. Нет причин, по которым мы не можем использовать Electron с Blazor => C#, HTML + CSS + gRPC

но вы очень ограничены в том, какие элементы управления у вас есть и какие API вы можете использовать.

@lucasf Вы пробовали Уно? Знаете ли вы, что Uno позволяет использовать любой собственный API через Xamarin, если нет подходящего API UWP. Я использую только несколько собственных API в своих приложениях на основе Uno, даже для своего приложения для потоковой передачи видео в реальном времени, которое использует аппаратный кодек и требует малой задержки.

но вы очень ограничены в том, какие элементы управления у вас есть и какие API вы можете использовать.

@lukasf Вы пробовали Уно? Знаете ли вы, что Uno позволяет использовать любой собственный API через Xamarin, если нет подходящего API UWP. Я использую только несколько собственных API в своих приложениях на основе Uno, даже для своего приложения для потоковой передачи видео в реальном времени, которое использует аппаратный кодек и требует малой задержки.

@zipswich Набор стандартных элементов управления Xaml в Uno довольно мал, и далеко не то, что могут предложить полные UWP или WinUI3. Чтобы реализовать хорошие/сложные пользовательские интерфейсы, вам обычно приходится встраивать дополнительные собственные элементы управления и код пользовательского интерфейса для конкретной платформы. Таким образом, в конце концов вы окажетесь со смесью нескольких платформ пользовательского интерфейса (Uno Xaml, родной Android, родной iOS, может быть, родной Windows или WebAssembly). Это не то, что я называю отличным опытом разработчика.

Если бы у нас были встроенные рендереры x-платформы для WinUI, у нас был бы только один единственный пользовательский интерфейс с полным набором функций WinUI, без каких-либо специфичных для платформы вещей. И WinUI будет напрямую рендерить на GPU с полной производительностью, как и следовало ожидать. Нет необходимости добавлять дополнительные элементы управления Android или дополнительные элементы управления iOS. Вот как должна выглядеть разработка для x-платформы.

Чего не хватает WinUI (и как его можно улучшить), чтобы убедить руководителей программ Microsoft для Microsoft Teams перейти с ElectronJS на WinUI/UWP?

Отличный вопрос. Огромное количество пользователей будут очень рады, если они это сделают.

Важным фактором является отсутствие показателей производительности, сравнивающих фреймворки. Страницы, которая сравнивает эквивалентные приложения, созданные в UWP и Electron, и сравнивает скорость и использование памяти, было бы достаточно. Это может распространяться на другие фреймворки. Из этих затрат для пользователей, влияния на использование и преимуществ консолидации кода можно сопоставить финансовые затраты.

Текущее отсутствие этого исследования помогает неэффективным фреймворкам становиться популярными.

Честно говоря: я сомневаюсь, что у MS есть какие-либо планы сделать «WinUI» ( Windows UI) кроссплатформенным. Кроме того, тот факт, что теперь это открытый исходный код, обычно означает, что Microsoft больше не считает его критически важной/стратегической технологией. Вместо этого они пытаются использовать ресурсы сообщества, чтобы уменьшить внутреннюю численность персонала, сохранив при этом его жизнь. Не поймите меня неправильно, я рад, что WinUI теперь с открытым исходным кодом, и ценю все время, которое разработчики Microsoft вкладывают в платформу, доводя ее до WinUI 3.0 — это отличный шаг для консолидации платформы представления Windows как для нативных, так и для управляемые приложения. Я просто не думаю, что Microsoft видит в Windows будущее, и я не думаю, что они заинтересованы в том, чтобы сделать его кроссплатформенным (конечно, это их ошибка, если это правда).

Настоящая кроссплатформенная среда разработки, которая не вынуждает разработчиков использовать некачественные технологии, — это то, что нужно миру. Кажется, большинство людей здесь согласны. В основном это означает следующее:

• Библиотека элементов управления и разметка (XAML), которые могут отображаться так же, как собственные проекты платформы (нам понадобятся только стили элементов управления для iOS, Android и т. д.).
• Должен быть написан в управляемом коде, таком как WPF. Только базовые слои в C++, элементы управления никогда не должны быть ничем иным, как C#.
• Рендеринг должен выполняться с помощью Metal/Vulcan/DirectX (не поверх существующих элементов управления, таких как Uno).
• Ввод должен быть повторно реализован на X-платформе
• Доступность — это большая проблема, которую, к сожалению, гораздо легче решить с помощью подхода Uno.

Если это то, чего мы хотим, WinUI, я думаю, этого не сделает. Сам факт и способ его реализации (некоторый промежуточный уровень COM/.net) означает, что было бы очень сложно использовать эту кросс-платформу. Вместо этого у нас есть UNO и Авалония. Авалония — настоящий свет в конце туннеля, но у них нет ресурсов. Сейчас более-менее возможно использовать технологию рендеринга Avalonia в качестве серверной части WPF (управляемая часть). Это дало бы нам настоящую кросс-платформенную структуру пользовательского интерфейса за короткий промежуток времени. Проблема в том, что WPF разработан для настольных компьютеров, и в UWP было проделано много работы, чтобы сделать WPF/Silverlight удобным для устройств размером с телефон и современным сенсорным/интерактивным вводом.

Я искренне думаю, что на данный момент нам было бы лучше, если бы все мы просто бросали деньги и вкладывали код в Avalonia. Мы слишком долго просили Microsoft о кросс-платформенном пользовательском интерфейсе, и они готовы сами переключиться на веб-технологии. Microsoft сейчас даже конвертирует приложения UWP, такие как XBox, в Electron и веб-технологии. Приложения также не продаются в Microsoft Store.

Ирония в том, что Microsoft была настолько успешной в прошлом, потому что давала разработчикам инструменты, необходимые для создания отличных приложений. Это привлекает пользователей, и у вас есть очень конструктивная обратная связь. В какой-то момент это было забыто. Теперь разработчики прибегают к низкопробным технологиям (HTML/CSS изначально никогда не разрабатывались для приложений... они предназначались для разметки документов!) намного перевешивают жертвы в плане функциональности, системной интеграции и производительности в настоящее время.

Ирония в том, что Microsoft была настолько успешной в прошлом, потому что давала разработчикам инструменты, необходимые для создания отличных приложений. Это привлекает пользователей, и у вас есть очень конструктивная обратная связь. В какой-то момент это было забыто. Теперь разработчики прибегают к низкопробным технологиям (HTML/CSS изначально не предназначались для приложений... они предназначались для разметки документов!)

Хорошо сказано. Помимо BASIC, я начал использовать Microsoft IDE с Quick C, затем VC++... Раньше Microsoft развивалась, внедряла инновации устойчивым, последовательным и несколько предсказуемым образом. Мы пытались следовать за ним, и он, кажется, следует за тенденцией тех, кто должен следовать за нами. Раньше я советовал стажерам из ведущих исследовательских университетов использовать технологии Microsoft для корпоративных приложений, над которыми их просили работать. Сопротивления не было, и они быстро подхватили материал Microsoft. Мне было интересно, следит ли Microsoft за тем, что нравится детям в наши дни, а затем следите за ними.

Приложения также не продаются в Microsoft Store.

Правда печально. Однако я виню худший магазин приложений (для пользователей и издателей), а не технологии разработчиков. Соотношение ежедневных загрузок UWP и Android-версии приложения: 1:20 . Они стоят примерно одинакового количества усилий для разработки. Это не преувеличение. Я только что взглянул на вчерашние данные о загрузке. Если бы я работал счетчиком бобов, меня бы немедленно уволили за то, что я потратил так много усилий на версию UWP, которая приносит так мало прибыли.

Правда печально. Однако я виню худший магазин приложений (для пользователей и издателей), а не технологии разработчиков.

@zipswich , да, ты прав. Я просто предположил, что Microsoft внутренне видит цифры продаж и предполагает (правильно), что экосистема умирает. Затем это убеждает их в том, что типы базовых технологий разработки, о которых мы говорим, устарели, поэтому они начинают инвестировать и двигаться в другом направлении. На самом деле, большинство разработчиков приложений Microsoft видят явную потребность в кросс-платформенной среде, которая написана не с учетом последних 20 лет технического прогресса пользовательского интерфейса (WPF действительно изменил правила игры, когда он появился).

Нам нужна не только кросс-платформенность: нам нужно что-то, что делается с помощью мощных/масштабируемых языков и разметки и имеет значимую область применения (предназначенную для приложений, хороший каталог управления) с самого начала. Я не думаю, что мы можем больше рассчитывать на Microsoft в этом. Они ясно дали понять, что видят более высокую прибыль, тратя свое время/ресурсы в других областях.

Меня бы немедленно уволили за то, что я потратил так много усилий на версию UWP, которая приносит так мало прибыли.

Я слышу вас, я сделал это заявление на основе моего собственного приложения в Магазине Microsoft.

@robloo У тебя есть несколько хороших моментов, но я не очень тебя понимаю. Вот некоторые мысли:

• Microsoft также вложила много усилий и ресурсов в другие платформы с открытым исходным кодом, такие как .NET Core, ASP.Net Core, EF Core. Очевидно, они видят будущее в кроссплатформенной разработке с открытым исходным кодом (по крайней мере, для серверных приложений). Они также вкладывают ресурсы в компиляцию AOT, поэтому .NET Core можно также скомпилировать для iOS и Android (где JIT не разрешен). Поэтому я не могу согласиться с тем, что вы говорите, что WinUI мертв только потому, что они сделали его открытым исходным кодом. Я имею в виду, что это может быть правдой, но если ваш единственный аргумент «потому что они делают его открытым исходным кодом», то это не очень убедительно.

• Qt — это кроссплатформенная среда пользовательского интерфейса, реализованная на родном языке C/C++. Он имеет аппаратно-ускоренные рендереры OpenGL/Direct3D, поэтому он выглядит одинаково и имеет отличную производительность на всех платформах. Код для конкретной платформы не требуется, все элементы управления работают на всех платформах, включая iOS и Android. Так почему технически невозможно запустить WinUI на iOS и Android, если Qt может это сделать? WinUI реализован в WinRT, который является родным языком C++, как и Qt. Внутри он использует только несколько COM-технологий (интерфейс IUnknown плюс заводская система COM). Не должно быть слишком сложно абстрагироваться от этого или повторно реализовать то, что необходимо для других платформ. Я не думаю, что какой-либо COM-код напрямую используется в коде WinUI.

• Silverlight использовал ту же технологию и был доступен для x-платформ.

• Windows по-прежнему остается настольной операционной системой номер 1, активно используемой не только дома, но и (особенно) на предприятиях. В сочетании с лицензиями на Office это приносит Microsoft солидный доход. Они потеряют этот доход, если позволят всем основным платформам разработки пользовательского интерфейса умереть. WinForms и WPF уже мертвы, поэтому WinUI — единственная активная платформа пользовательского интерфейса в Windows. Я не верю, что они хотят избавиться от полной системы Windows/Office/Enterprise, поэтому я не верю, что они хотят избавиться от WinUI.

• Создание WinUI с открытым исходным кодом отлично подходит для разработчиков, а не только для Microsoft.

• Возможно, UWP умрет. Многие разработчики избегают этого из-за глупых ограничений. Магазин Windows не работает удаленно. Windows Phone мертв, что было основной причиной запуска всего UWP.

• Использование WinUI в настольных приложениях с помощью WinUI 3.0 и создание открытого исходного кода может стать шагом к его спасению, а не уничтожению!

Я просто предположил, что Microsoft внутренне видит цифры продаж и предполагает (правильно), что экосистема умирает. Затем это убеждает их в том, что типы базовых технологий разработки, о которых мы говорим, устарели, поэтому они начинают инвестировать и двигаться в другом направлении.

@robloo Это не обязательно так. Я все время говорил, что это худший магазин приложений, который убил Windows Phone, лучшую мобильную платформу.

Они могут убить двух зайцев одним выстрелом: передать магазин компетентной третьей стороне и положить конец кошмару .Net Native. Это уменьшит их стоимость и (я полагаю) удвоит, учетверит... Приложение для Windows загружается быстрее. Более 90% проблем с моими приложениями UWP связаны исключительно с кошмаром .Net Native.

@lukasf Я думаю, ты неправильно истолковал многое из того, что я сказал.

Я не могу согласиться с тем, что вы говорите, что WinUI мертв только потому, что они сделали его открытым исходным кодом.

Я бы никогда не сказал, что WinUI мертв. Я сказал, что Microsoft, вероятно, больше не рассматривает его как критический/стратегический долгосрочный продукт. Они видят более высокую прибыль в других областях (услугах и облаке), поэтому стараются проводить свое время там, где акционеры получают более высокую прибыль. Это означает, что я думаю, что они не будут значительно расширять WinUI, чтобы сделать его кроссплатформенным и просто поддерживать его, что я обязательно сказал вместо « мертвого ». (Я не кого-то на UWP/WinUI является мертвым вагоном). Я также очень уверен, что Microsoft отлично справляется с WinUI 3.0, о чем я говорил. Это позволяет консолидировать всю Windows, встроенную и управляемую Win32, в одну структуру пользовательского интерфейса.

Так почему технически невозможно запустить WinUI на iOS и Android?

Технически возможно все. Я говорил, что это будет чрезвычайно сложно, поскольку он был разработан и реализован исключительно для Windows. Я также привел пример того, как он взаимодействует с управляемым кодом, поскольку я думаю, что было бы очень сложно использовать кроссплатформенность. Хотя было бы хорошо для всех нас, если бы я ошибся здесь.

Silverlight использовал ту же технологию и был доступен для x-платформ.

И Silverlight мертв не потому, что это было технически невозможно, а потому, что это больше не было хорошим бизнес-кейсом, что на самом деле является моей самой важной точкой зрения. Обратите внимание, что он также умер из-за тех же технологий HTML/CSS/JS, которые теперь захватили разработку для настольных компьютеров и мобильных устройств.

Они потеряют этот доход, если позволят всем основным платформам разработки пользовательского интерфейса умереть.

Это, вероятно, можно было бы обсудить несколькими способами, но, вероятно, довольно быстро полностью выходит за рамки темы (что, я знаю, я уже делаю). В итоге, конечно, Microsoft не позволит умереть всем платформам пользовательского интерфейса Windows. Вы все еще должны писать приложения для Windows... Я никогда не говорил иначе.

Создание WinUI с открытым исходным кодом отлично подходит для разработчиков, а не только для Microsoft.

Я сказал: «Я рад, что WinUI теперь с открытым исходным кодом, и ценю все время, которое разработчики Microsoft вкладывают в платформу, доводя ее до WinUI 3.0». причин, которых я не коснулся. Например, даже Uno Platform, которая теперь имеет доступ к исходникам, — это здорово, как они заявили на UnoConf.

Возможно, UWP умрет.

Подожди, а ты на чьей стороне? хаха. А если серьезно, я считаю, что WinUI/UWP, по сути, одно и то же, и UWP просто претерпит небольшую эволюцию в WinUI без каких-либо серьезных сбоев для разработчиков.

Использование WinUI в настольных приложениях с помощью WinUI 3.0 и создание открытого исходного кода может стать шагом к его спасению, а не уничтожению!

Я согласен с вами и никогда не хотел сказать обратное. Тем не менее, я рассматривал некоторые более крупные тенденции в изображении, а также говорил о том, чтобы сделать его кроссплатформенным.

@зипсвич

Они могут убить двух зайцев одним выстрелом: передать магазин компетентной третьей стороне и положить конец кошмару .Net Native. Это снизит их стоимость и (я полагаю) вдвое, вчетверо.

Хорошая новость заключается в том, что Microsoft уже решила убить .net native. Технически у него был ряд нелепых ограничений, которые не соответствовали спецификациям .net, с которыми, похоже, вы более чем знакомы. Я думаю, что это было сделано быстро/грязно, чтобы исправить проблемы с запуском и производительностью на Windows Phone, и они никогда не удосужились вернуться и исправить что-то с тех пор, как Windows Phone умер.

Сейчас Microsoft разрабатывает полноценную высокопроизводительную компиляцию AOT с использованием технологий Mono и LLVM. Я думаю, что это должно выйти к следующему году, а также полезно для Blazor на стороне клиента с веб-сборкой. Микель де Икаса сделал хорошую презентацию, касающуюся этого, в начале этого года на UnoConf: https://www.youtube.com/watch?v=tYk2us6W6Gg (он первый докладчик).

@robloo Хорошо, может быть, я ошибся в некоторых моментах.

Так почему технически невозможно запустить WinUI на iOS и Android?

Технически возможно все. Я говорил, что это будет чрезвычайно сложно, поскольку он был разработан и реализован исключительно для Windows. Я также привел пример того, как он взаимодействует с управляемым кодом, поскольку я думаю, что было бы очень сложно использовать кроссплатформенность. Хотя было бы хорошо для всех нас, если бы я ошибся здесь.

Silverlight использовал ту же технологию и был доступен для x-платформ.

И Silverlight мертв не потому, что это было технически невозможно, а потому, что это больше не было хорошим бизнес-кейсом, что на самом деле является моей самой важной точкой зрения. Обратите внимание, что он также умер из-за тех же технологий HTML/CSS/JS, которые теперь захватили разработку для настольных компьютеров и мобильных устройств.

Моя точка зрения такова: Silverlight уже работал на разных платформах. Его можно использовать с управляемым кодом. Уровень пользовательского интерфейса UWP Xaml из Windows 8 был в основном Silverlight, только с новым пространством имен и некоторыми добавленными метаданными. К настоящему времени он развился, но в начале это был просто Silverlight Xaml с новым пространством имен. Так что, если раньше они могли запускать кросс-платформенный Silverlight, они также могут запускать кроссплатформенный WinUI. И я не думаю, что это будет «чрезвычайно сложно», но я бы скорее сказал, что это будет довольно легко для такой огромной компании, как Microsoft. У них уже был кроссплатформенный слой рендеринга для Silverlight Xaml. Не должно быть слишком сложно обновить его, чтобы он мог работать с последней версией WinUI.

Возможно, UWP умрет.

Подожди, а ты на чьей стороне? хаха. А если серьезно, я считаю, что WinUI/UWP, по сути, одно и то же, и UWP просто претерпит небольшую эволюцию в WinUI без каких-либо серьезных сбоев для разработчиков.

WinUI — это просто уровень пользовательского интерфейса Xaml, а UWP — это полноценная платформа приложений и уровень системного API, привязанный к Магазину Windows и имеющий множество ограничений по сравнению с классическими настольными приложениями. Так что это две очень разные вещи. Я действительно не знаю, видит ли Microsoft будущее в UWP и Магазине Windows. Неустранение серьезных ограничений UWP и не работа над проблемами Магазина Windows не вселяют во мне особого оптимизма. Но им определенно нужна какая-то структура пользовательского интерфейса, и это будет WinUI, независимо от того, используется ли он из UWP или из настольных приложений. И если они действительно хотят добиться успеха, они должны сделать его кроссплатформенным. В противном случае люди уйдут на другие фреймворки, а затем могут в какой-то момент полностью покинуть платформу Windows. Сделать WinUI кроссплатформенным — значит заставить разработчиков придерживаться Windows.

Моя точка зрения такова: Silverlight уже работал на разных платформах. Его можно использовать с управляемым кодом. Уровень пользовательского интерфейса UWP Xaml из Windows 8 был в основном Silverlight, только с новым пространством имен и некоторыми добавленными метаданными. К настоящему времени он развился, но в начале это был просто Silverlight Xaml с новым пространством имен. Так что, если раньше они могли запускать кросс-платформенный Silverlight, они также могут запускать кроссплатформенный WinUI. И я не думаю, что это будет «чрезвычайно сложно», но я бы скорее сказал, что это будет довольно легко для такой огромной компании, как Microsoft. У них уже был кроссплатформенный слой рендеринга для Silverlight Xaml. Не должно быть слишком сложно обновить его, чтобы он мог работать с последней версией WinUI.

Я не знал, что история использования базы Silverlight для UWP/Win8 в то время, если это так, то это дает мне больше оптимизма в отношении того, насколько это возможно. Спасибо за исправление!

WinUI — это просто уровень пользовательского интерфейса Xaml, а UWP — это полноценная платформа приложений и уровень системного API, привязанный к Магазину Windows и имеющий множество ограничений по сравнению с классическими настольными приложениями. Так что это две очень разные вещи.

Да, вы правы, и мне следовало более тщательно подобрать формулировку. Конечно, модель UWP в приложении и упаковка пока будут продолжать существовать. Однако уровень пользовательского интерфейса переключится на WinUI, о чем я и пытался сообщить. Я думаю, что в ближайшие годы будет больше изменений с заменой .net native, но упаковка/модель приложения/API, представленные с UWP, все еще будут существовать в той или иной форме. Я определенно согласен с тем, что Microsoft может не видеть здесь будущего. К счастью, пока XAML и C# все еще существуют, миграция на новую модель приложения или упаковка/распространение обычно происходит относительно быстро. Если бы только с Авалонией было покончено...

И если они действительно хотят добиться успеха, они должны сделать его кроссплатформенным. В противном случае люди уйдут на другие фреймворки, а затем могут в какой-то момент полностью покинуть платформу Windows. Сделать WinUI кроссплатформенным — значит заставить разработчиков придерживаться Windows.

Я также согласен с вами на 100% и заявил то же самое в нескольких местах. Я пришел к выводу, что по ряду причин этого не произойдет.

Я не могу не согласиться достаточно сильно с комментаторами, говорящими:

WinUI 3.0 должен быть кроссплатформенным!

1) UI-фреймворк нужен сейчас, а не через N лет, когда теоретически кроссплатформенный проект будет стабильным.
2) Нам нужен UI-фреймворк, максимально приближенный к ОС. С кроссплатформенностью всегда есть компромисс. Либо наименьший общий знаменатель для функциональности, либо несогласованный рендеринг элементов управления из-за пользовательского рендеринга.

Решение, на мой взгляд, состоит в том, чтобы иметь другую структуру, которая строится либо поверх WinUI 3.0 (если вы хотите поддерживать Fluent и мало работаете с рендерингом, тестированием попаданий и т. д.), либо с нуля с помощью WinUI Composition. если вам нужна максимальная производительность, и вы не возражаете самостоятельно выполнять весь рендеринг и тестирование попаданий (за счет потенциальной стоимости несогласованности).

Помню, несколько дней назад я видел эти строки:
«Операционная система больше не является для нас самым важным уровнем... Для нас важнее всего модель приложения и опыт».
Таким образом, очевидно, что WinUI должен быть лучшим интерфейсом с графическим интерфейсом, и я думаю, что он будет, как и лучшее из WPF, UWP и Windows 10,

Но очевидно, что Интернет и его старый javaScript + HTML используются повсеместно, а их веб-фреймворки и стеки используются массово не потому, что они лучше, а потому, что они легко доступны в веб-браузере телефона и настольном веб-браузере. Вы можете создать HTML-файл в Блокноте, поместить тег Script с предупреждением («Hello World»); и у вас есть приложение.

Так что я вижу, что можно и даже нужно заменить его на .NET+XAML с помощью WebAssembly. Нам нужно, чтобы .NET был таким же вездесущим, как сегодня javaScript.

Silverlight был светом надежды... и теперь с WebAssembly я вижу, что к Silverlight можно вернуться.

Я был бы рад этому:
WinUI — это полноценный графический интерфейс, работающий от ОС, и, по крайней мере, часть его XAML, способная работать в веб-браузере.

Так что я считаю команду UNO очень важной и надеюсь, что в ближайшем будущем они присоединятся к Microsoft, чтобы объединить усилия в таком замечательном начинании, как WinUI.

@MarkIngramUK

Сделайте WinUI лучшим выбором пользовательского интерфейса для всех, кто рассматривает возможность разработки для Windows. Заканчивать:

• Проверка ввода и собственный элемент управления сеткой данных
• Другие ~ 170 предложений функций здесь
• Остальные ~300 открытых тикетов
• .NET Native > Миграция .NET Core (для .NET Core 3+5, .NET Standard 2.1+ и C# 8...)
• Новый компилятор AOT
• Получить и опубликовать более последовательные руководства по беглому дизайну
• Уточните систему стилей/тем
• Уменьшите акцент на отвлекающих элементах композиции (наклон, интенсивное использование акрила, раскрытие) и больше сосредоточьтесь на системе глубины и теней и анимации (которые вносят ясность и помогают пользователям).

Это вещи, которые сделают WinUI более привлекательным для людей, рассматривающих его по сравнению с Electron в будущем.

Тогда вишенкой на торте будет:

• Инструмент(ы), помогающий синхронизировать стили CSS <-> XAML.
• Рекомендации по отделению логики приложения от представлений для максимального повторного использования кода .NET на других платформах.
• Некоторый инструмент для создания единовременного чернового перевода элементов управления HTML > XAML, чтобы разработчики начали работу со своими собственными приложениями WinUI (вместо того, чтобы предполагать, что большинство разработчиков будут начинать с приложений XAML и хотят перейти к HTML)

2. We need a UI framework that is as close to the OS as possible. With cross-platform, there is always a trade off. Either lowest common denominator for functionality, or inconsistent control rendering due to custom rendering.

@MarkIngramUK Silverlight был кроссплатформенным, полнофункциональным и одинаково отображался на всех платформах. Qt является кроссплатформенным, полнофункциональным и одинаково отображается на всех платформах. Вы получите несогласованную отрисовку и элементы управления с наименьшим общим знаменателем, только если попытаетесь реализовать свои элементы управления, внутренне транслируя их в собственные элементы управления другой платформы (что и пытаются сделать Xamarin и Uno). Если вы выполняете абстракцию не на уровне управления, а на самом низком уровне (уровень рендеринга графического процессора), вы можете получить 100% одинаковый результат на всех платформах с полным набором элементов управления. Набор управления уже есть, это WinUI 3.0, и он отличный даже сейчас. Единственное, чего не хватает, так это реализации слоев рендеринга для других платформ (и они могли быть частично взяты из старых исходников Silverlight).

Я бы очень хотел заняться кроссплатформенной разработкой приложений. Но ни Xamarin, ни Uno мне не кажутся привлекательными, и мне не очень нравится JS/HTML и все, что на нем основано. К сожалению, разработка исключительно для Windows Store — плохой выбор, если вы действительно собираетесь зарабатывать на этом деньги. По крайней мере, у меня был довольно плохой опыт с этим, а затем, когда Microsoft убила экосистему Windows Phone, я более или менее положил этому конец (несмотря на некоторые небольшие проекты «просто для удовольствия»). Я бы немедленно начал снова работать над новыми приложениями, если бы WinUI стал кроссплатформенным.

Все современные кроссплатформенные фреймворки имеют более или менее серьезные ограничения и/или плохой опыт разработки. Если Microsoft сможет сделать WinUI кроссплатформенным, это действительно может стать прорывной технологией. Xamarin уже довольно успешен, несмотря на все его грани, углы и ограничения. Только представьте, насколько успешным мог бы быть WinUI, если бы он работал на всех платформах с полным набором функций и первоклассным опытом разработки Visual Studio.

@lukasf , это моя точка зрения:

Silverlight был кроссплатформенным, полнофункциональным и отображался одинаково на всех платформах.

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

@MarkIngramUK Я вижу это так: простые приложения привязаны к стандартным элементам управления пользовательским интерфейсом платформы. Отличные приложения имеют свой внешний вид. Им не нужны стандартные элементы управления платформой. Посмотрите на Spotify, Netflix или другие отличные и успешные приложения, доступные для нескольких платформ. Вы не можете сказать, какую платформу они используют, просто взглянув на их элементы управления.

Я бы хотел, чтобы мои кроссплатформенные приложения выглядели одинаково на всех платформах.

@MarkIngramUK Рад, что вы затрагиваете реальность, выходящую за рамки теории. Вот реальность для меня: у меня есть куча приложений, которые произошли от SL/WP > WinRT > UWP, которым вчера нужно было ориентироваться на несколько платформ. Я изучил Phonegap/Cordova и провел много времени, очень серьезно изучая Xamarin, и в конце концов сдался. Я влюбился в Uno по многим причинам, как только начал его использовать. На данный момент я не знаю никакой другой многообещающей практической технологии X-платформы, дружественной к C# и Xaml, которую я мог бы использовать прямо сейчас . Когда через 1, 2 или 3 года WinUI превратится в X-платформенный API, первоклассные разработчики Uno перенесут Uno с UWP на WinUI, и все мои приложения на основе Uno смогут соответствующим образом и быстро мигрировать. Мне не о чем беспокоиться сейчас.
Я ни в коем случае не против интригующих теоретических дискуссий здесь. Люблю слышать всевозможные идеи.

Разве WinUI/MS не может использовать проект Blazor для отображения WinUI как «Blazor Native» приложения?

Я знаю, что Стив Сандерсон представил Blutter, в котором Flutter от Google можно отображать с помощью Blazor (и это пользовательский интерфейс на основе XML). Кажется, у команды Blazor есть хорошая технология на стороне рендеринга пользовательского интерфейса, позволяющая использовать различные фреймворки пользовательского интерфейса. Если Blazor может обрабатывать Flutter, он должен быть в состоянии обрабатывать эквивалент типа WinUI/Sillverlight.

Потенциал заключается в менее фрагментированной экосистеме MS и гораздо более мощной, начиная с Интернета и заканчивая x-платформой собственных приложений с использованием унифицированной .net 5.

@лукасф :

@MarkIngramUK Я вижу это так: простые приложения привязаны к стандартным элементам управления пользовательским интерфейсом платформы. Отличные приложения имеют свой внешний вид. Им не нужны стандартные элементы управления платформой. Посмотрите на Spotify, Netflix или другие отличные и успешные приложения, доступные для нескольких платформ. Вы не можете сказать, какую платформу они используют, просто взглянув на их элементы управления.

Я бы хотел, чтобы мои кроссплатформенные приложения выглядели одинаково на всех платформах.

Мы комбинируем оба подхода для наших приложений (https://affinity.serif.com). Наши клиенты могут быть весьма громкими, если мы не принимаем общие стандарты платформы, например, порядок кнопок в диалогах (Windows обычно «ОК», затем «Отмена», тогда как macOS «Отмена», а затем «ОК»), кнопки со скругленными углами, состояния наведения, флажки и переключатели, макет. элементов управления и т. д. Так что да, на первый взгляд наши приложения выглядят одинаково на платформах Windows и macOS, но у нас есть небольшие различия (рендеринг и взаимодействие с пользовательским интерфейсом). Мы также в полной мере используем преимущества нашей хост-платформы, используя их собственные API-интерфейсы, и поэтому мы никогда не сталкиваемся с проблемами наименьшего общего знаменателя.

Я все еще думаю, что приведенное выше обсуждение вводит в заблуждение, WinUI — это среда пользовательского интерфейса самого низкого уровня, которую предоставляет Microsoft. Если вам нужна кроссплатформенная библиотека, создайте ее поверх нее. Это все равно, что сказать: «Win32 должна быть кроссплатформенной!». Нет, Win32 должен быть лучшим фреймворком для платформы Windows. Здесь тот же аргумент: WinUI должен быть лучшим фреймворком для платформы Windows 10.

@MarkIngramUK написал:

WinUI — это платформа пользовательского интерфейса самого низкого уровня, предоставляемая Microsoft. Если вам нужна кроссплатформенная библиотека, создайте ее поверх нее.

Это кажется мне практическим решением, которое действительно может быть успешным, в зависимости от деталей (хотя и не обязательно единственным решением). Два слоя:

1. Microsoft WinUI: не кроссплатформенный.
2. Microsoft CrossXYZ-UI: кроссплатформенный. Его внутренняя реализация для Windows будет написана с использованием WinUI.

Такое двухуровневое решение помогло бы смягчить проблему, о которой я упоминал в своем первоначальном сообщении:

Потенциально новые версии WinUI могут быть существенно задержаны из-за увеличения объема работы/сложности поддержания поддержки нескольких различных операционных систем. Например, «Мы могли бы уже выпустить эту новую версию WinUI несколько месяцев назад, за исключением проблемы, связанной с тем, что мы закончили ее отладку только для Windows, а не для Android, MacOS или Apple iOS».

Исходя из моего опыта кроссплатформенной разработки в прошлом, я бы отметил, что это двухуровневое решение было бы более успешным, если бы в WinUI были реализованы различные изменения/дополнения с целью поддержки и помощи отдельному кроссплатформенному «CrossXYZ». слой "UI". В противном случае, если WinUI ничего не делает для поддержки кросс-платформенного уровня, то, по моему опыту, это обычно означает, что кросс-платформенный уровень часто вынужден прыгать через искаженные обручи, которые затрудняют и откладывают программирование и надежность.

Согласно теории слоев, WinUI не нужно знать или заботиться о слое «CrossXYZ-UI», который использует WinUI, но эта теория плохо работает на практике в реальном мире, поэтому я говорю, что WinUI должен учитывать и помогают слою «CrossXYZ-UI», но я не имею в виду ужасную идею создания зависимостей от «CrossXYZ-UI» внутри WinUI, и я не имею в виду специальные частные хуки внутри WinUI, которые используются только «CrossXYZ-UI». ". 2 слоя по-прежнему должны храниться отдельно в чистоте. Я просто говорю, что когда принимаются решения по дизайну API для WinUI, эти решения должны быть выполнены с учетом их влияния на отдельный слой "CrossXYZ-UI" и с учетом того, как WinUI может облегчить жизнь " CrossXYZ-UI», не только с учетом приложений, которые напрямую используют WinUI.

Я не знаю, пытается ли Xamarin уже работать в описанном выше двухуровневом режиме, но если это так, то я полагаю, что в настоящее время он исключает ту часть идеи, в которой WinUI поддерживает/помогает отдельному кросс-платформенному уровню. Трудно доверять Xamarin, когда Microsoft недостаточно доверяла Xamarin, чтобы использовать его для Microsoft Teams и различных других приложений Microsoft.

В прошлом я публиковал кроссплатформенное программное обеспечение, которое успешно функционировало и имело хорошую производительность, но в итоге я отменил кроссплатформенную работу по нетехническим причинам. Например, клиенты, использующие версию программного обеспечения для Linux, настаивали на том, чтобы цена программного обеспечения составляла 0 долларов. Таким образом, стоимость производства и поддержки версии Linux намного превышала 0 долларов дохода от «клиентов», использующих Linux, поэтому она была явно неустойчивой.

Как разработчик приложения, только потому, что вы _теоретически_ можете_ создать кросс-платформенное приложение, это не всегда означает, что вы _должны_. Интересно, что в современных кроссплатформенных дискуссиях я замечаю, что люди больше упоминают Android, а не Linux. Одной из главных причин такого сдвига, вероятно, является вышеупомянутая проблема с нулевым долларом.

Платформа Re Uno:

Даже если Uno имеет хороший надежный технический дизайн и реализацию, существует риск и опасения, что Uno может исчезнуть в течение нескольких лет из-за аналогичной проблемы с нулевым долларом или недостаточного дохода, что в конечном итоге вызывает выгорание и отмену проекта или стагнацию. Или просто самый важный разработчик Uno однажды внезапно обретает новое хобби/интерес/одержимость и теряет интерес к Uno, или новую работу/работодателя, и у него больше нет времени работать над Uno. Как сказал @mdtauk :

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

Я также согласен с другим комментарием @mdtauk :

Проблема с этим аргументом в том, что за последнее десятилетие Microsoft отказалась от платформ,

Да, Microsoft потеряла некоторую степень репутации/надежности/надежности из-за отмены платформ. Я думаю, что Microsoft нужно быть осторожным, чтобы избежать дальнейшей потери репутации и надежности из-за дальнейших отмен. Новая версия существующей платформы лучше, чем новая платформа.

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

Если вы, ребята, находите этот двухуровневый подход таким привлекательным, вы можете прямо сейчас продолжить и использовать Xamarin или Uno. Вам не нужно ждать таких фреймворков, они уже есть и очень хорошо работают. Но вы потеряете все преимущества и улучшения WinUI, как только перейдете на Android или iOS. Нет больше NavigationView, нет AppBars, больше нет SemanticZoom и т.д. и т.п. Все, что сделано в этом репозитории, все улучшения недоступны кроссплатформенно, потому что кроссплатформенность означает наименьший общий знаменатель. Вы можете использовать их только в том случае, если вы специально нацелены на платформу Windows. Таким образом, вам придется снова реализовать все классные вещи WinUI вручную, используя собственные элементы управления Android или iOS.

Если вам это нравится, просто используйте Xamarin или Uno. Нет необходимости в третьей структуре, подобной этой. Но для меня это звучит не очень хорошо. Мне нужен один фреймворк с отличным набором элементов управления, который можно использовать напрямую для всех платформ с полной функциональностью на каждой платформе. Я не хочу повторно реализовывать навигацию моего приложения и прочее на каждой платформе отдельно, имея сложные и дублирующие определения пользовательского интерфейса. Для меня это звучит как ужасная идея. Если бы WinUI был кроссплатформенным, используя подход рендеринга, я мог бы напрямую использовать все его функции и каждое улучшение здесь на любой платформе. И если бы я хотел, чтобы мои элементы управления больше походили на iOS для этой цели, я мог бы просто применить iOS ResourceDictionary. Проблема решена без необходимости возиться с собственными элементами управления и дублировать реализации пользовательского интерфейса.

Аргумент о том, что релизы будут отложены, потому что «рендерер для другой платформы не был обновлен», является нереалистичным аргументом. Слой рендеринга работает с низкоуровневыми командами рисования, такими как «рисовать прямоугольник, рисовать линию, рисовать текст». Если вы добавляете новый элемент управления в WinUI, вы пишете свою логику элемента управления и предоставляете шаблон элемента управления, который использует сетку, границы, текстовые поля и тому подобное. Ни один новый элемент управления не потребует обновления средств визуализации, средства визуализации будут очень низкого уровня и с очень низкой скоростью изменений. Есть только редкие случаи, когда рендереры необходимо трогать, например, при добавлении новых кистей или эффектов. Qt использует подход рендерера и является одним из самых популярных кроссплатформенных UI-фреймворков. Этот подход, кажется, работает очень хорошо для них.

@лукасф

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

Каждый инженер и доллар, потраченные на создание кросс-платформенного WinUI, — это инженер и доллар, которые можно было бы использовать для улучшения WinUI для Windows.

Аргумент о том, что релизы будут отложены, потому что «рендерер для другой платформы не был обновлен», является нереалистичным аргументом.

Создать идеальный движок рендеринга 1:1, работающий на iOS, Android, MacOS, Linux и Windows 7/8, — непростая задача. Существует огромное количество API-интерфейсов Windows 10, на которые опираются приложения и платформа. По сути, вы создадите совершенно новую структуру приложения.

Кроме того, посмотрите на этот недавний поток Reddit: Что я должен использовать для пользовательского интерфейса в C #

Буквально ноль упоминаний о WinUI и одна полурекомендация по использованию UWP. Разработчики должны с энтузиазмом относиться к использованию WinUI в Windows задолго до того, как пытаться сделать его кроссплатформенным, учитывая все огромные инвестиции, которые потребуются.

@лукасф ,

вы можете продолжить прямо сейчас и использовать Xamarin или Uno

Я упоминал об этом в своем предыдущем посте, но мы пишем отдельные интерфейсы для каждой целевой платформы. Windows (WPF), macOS (Cocoa), iOS (UIKit).

если бы я хотел, чтобы мои элементы управления больше походили на iOS для этой цели, я мог бы просто применить iOS ResourceDictionary. Проблема решена

Пока пользователь не обновит свою ОС и не изменится внешний вид всех приложений, кроме вашего.

Слой рендеринга работает с низкоуровневыми командами рисования, такими как...

Вам нужно больше, чем рендеринг для кроссплатформенности. Управление окнами, ввод, обработка текста, рендеринг, системная интеграция (например, панель задач / Aero Peek и т. д.). Не может быть, чтобы попытка изменить фокус WinUI с Windows-только на кросс-платформенный не вызвала чрезвычайной задержки.

Что касается рендеринга, WinUI построен на Windows.UI.Composition , поэтому вам придется полностью заменить эту библиотеку более низкого уровня чем-то кроссплатформенным и, надеюсь, не понести каких-либо потерь производительности из-за вашей абстракции, а затем портировать его на другие платформы. Или полностью перепишите WinUI, чтобы он не зависел от Windows.UI.Composition . Опять же, не маленькая работа.

Просто повторюсь - я не против кроссплатформенных библиотек. Они служат определенной цели, я просто не думаю, что WinUI должен стать таковым.

@лукасф

потому что кроссплатформенность означает наименьший общий знаменатель. …... Мне нужен один фреймворк с отличным набором элементов управления, который можно использовать напрямую для всех платформ, с полной функциональностью на каждой платформе.

Вы хотите, чтобы он имел полную функциональность на каждой платформе — я тоже — звучит замечательно; мечта — но только потому, что мы с вами этого хотим, не означает, что это должно быть возможным и практичным. Желание и результат могут быть самыми разными. Желанием может быть полная функциональность, в то время как в результате получается в основном та же проблема, о которой вы упомянули, - наименьший общий знаменатель. Ваша идея заслуживает внимания, но она не застрахована от того, чтобы стать жертвой проблемы наименьшего общего знаменателя, о которой вы упомянули.

Если бы WinUI был кроссплатформенным, используя подход рендеринга, я мог бы напрямую использовать все его функции и каждое улучшение здесь на любой платформе.

Действительно ВСЕ его функции и КАЖДОЕ улучшение на КАЖДОЙ платформе? Вы уверены, что такой впечатляющей цели можно достичь, просто базируя WinUI на кросс-платформенном рендерере? Так просто решение? Я думаю, что вы делаете идею намного проще, чем она есть на самом деле, потому что на самом деле требуется гораздо больше, чем рендерер, например:

• Управление окнами плюс всплывающие окна, всплывающие окна, контекстные меню, модальные диалоги.
• Управление отображением и разрешения, а также реагирование на изменения.
• Устройства ввода (клавиатура, мышь, сенсорный экран с жестами, перо).
• Анимация.
• Шрифты и стили, получение информации и размеров, а не только рендеринг. Также обработка текста в юникоде.
• Перетащите.
• Вырезать/копировать/вставить буфер обмена, который работает с различными форматами, а не только с текстом.
• Прокрутка с хорошей производительностью, в отличие от ужасной производительности прокрутки панелей чата в MS Teams.
• Чтение/загрузка ресурсов (различных видов), хранящихся внутри пакета приложения, таких как ресурсы изображений и другие.
• Воспроизведение аудио и видео.
• Автоматизация для чтения с экрана и т. д. для доступности.
• Тема/внешний вид соответствует тому, что в настоящее время настроено в ОС.
• Извлечение различных настроек ОС, влияющих на графический интерфейс, таких как международное форматирование, настройки мыши и клавиатуры и т. д.
• Проблемы с поддержкой мобильных устройств, планшетов и настольных компьютеров.
• И многое другое плюс сотни деталей, которые легко забываются при оценке размера проекта и даты выхода.

Я по-прежнему считаю, что ваша идея заслуживает внимания, но она намного сложнее и гораздо менее ясна, чем вы ее представляете. Это также может сильно замедлить разработку и развитие WinUI.

Разве WinUI/MS не может использовать проект Blazor для отображения WinUI как «Blazor Native» приложения?

@pinox , да, мы определенно могли бы, но тогда Blazor Native не был бы кроссплатформенным, если бы они не были нацелены на Uno (что было бы моим личным предпочтением).

Кросс-платформенность — это определенно то, о чем мы думали, и мы провели довольно тщательное исследование различных архитектур кросс-платформенных фреймворков. Мы пришли к тем же выводам, что и все в этой теме, а именно, что оба решения имеют свои плюсы и минусы, и что наши клиенты справедливо разделены 😃

@lukasf Я думаю, что «наименьший общий знаменатель», который в настоящее время существует в Uno, - это проблема ограничения ресурсов, а не из-за многослойности. Я хотел бы оказаться неправым, но я думаю, что эту проблему можно решить, и в будущем она не станет еще хуже.

Существует подмножество XAML, предлагающее отрисовку элементов управления и окон пользовательского интерфейса, выглядящих естественно, или вы можете владеть средством визуализации в macOS, iOS, Android, Linux и отображать одни и те же элементы управления и шаблоны «Fluent» на всех платформах.

Помимо создания какого-то варианта реализации CoreWindow / App Window для работы с родной ОС - все, что находится внутри окна, может быть отрисовано.

В Windows это DirectX, но у Apple есть Metal, а у Linux есть OpenGL. Разработчикам придется делать какие-то операторы IF для обработки собственного файлового ввода-вывода, уведомлений и т. Д., Но Xamarin поможет с этим.

@stevenbrix -- Я вижу, вы ответили на идею @Pinox _"рендерить WinUI как собственное приложение Blazor"_, но что вы думаете об идее _other_ от Pinox? Интересно, что @Pinox также написал:

В настоящее время Electron использует Javascript, HTML + CSS. Нет причин, по которым мы не можем использовать Electron с Blazor => C#, HTML + CSS + gRPC.

@Pinox - я согласен с тем, что «Electron C#» имеет гораздо больше смысла, чем «Electron JS», но если он использует C# и Blazor , как вы предложили, то я думаю, что приложению MS Teams, вероятно, не понадобится Electron. больше, потому что Blazor полностью заменит Electron? Я могу ошибаться — я недостаточно знаю, какие функции поддерживает Electron. Хотя, если у ElectronJS в настоящее время есть какая-либо полезная функция, которой нет в Blazor, то эта отсутствующая функция потенциально может поддерживаться в следующей версии Blazor.

Итак, я думаю, вы подняли важный вопрос, упомянув Blazor. Достойным решением для приложения MS Teams может быть переход с ElectronJS на Blazor + WebAssembly. Это действительно интересно.

Если приложение MS Teams переключилось с ElectronJS на Blazor, оно может использовать или не использовать какую-либо часть WinUI. Либо соединение, либо отсутствие соединения между Blazor и WinUI можно изучить дополнительно, как вы уже начали делать. Интересный!

Silverlight, WinRT, UWP — все было заброшено. (Я знаю, что технически это не UWP, но WinUI, скорее всего, будет рассматриваться как замена).

Насколько я понимаю, UWP — это среда выполнения, тогда как WinUI — это графический интерфейс/слой виджетов и т. д. Т.е. Win UI будет работать на Win32 или .NET без UWP API.

Что меня сводит с ума, так это то, что UWP на самом деле является довольно компетентным API. Он не такой мощный, как Win32, но по сравнению с Android (например) он намного разумнее. Я думаю, что разработчики упустили тот момент, что теперь существует унифицированный API времени выполнения, который имеет согласованную объектную модель, API, не является тупым и т. д. и т. д. Кто-нибудь еще писал приложения Win32 еще в 90-х или раньше? 00 000 000 000 00 000 000 000 000 000 000 000 000 000 000 000 000 000 00 00 00 000 000 лет до того, как появился .NET? Использование собственных API-интерфейсов платформы было ужасным.

Возвращаясь к рассматриваемой проблеме, я бы очень хотел увидеть кроссплатформенность WinUI. Есть сообщения о том, что он привязан к COM и т. д. Платформа Apple Core Foundation plugin (CFPlugin), IIRC, основана на COM, поэтому, возможно, подъем и сдвиг будут такими же простыми, как написание средства визуализации для платформ Apple. Более логичным было бы скрыть различия между платформами и сохранить объекты WinUI высокого уровня.

Мне бы хотелось увидеть сплоченную межплатформенную работу Microsoft, ориентированную в первую очередь на Windows, но купившую полностью совместимую объектную модель и диалект XAML для мобильных устройств, Linux и macOS. В .NET Core уже есть фантастическая кроссплатформенная экосистема (без графического интерфейса). Добавьте компетентную среду XAML, и это не составит труда для всей клиентской разработки, особенно если визуальные эффекты могут выглядеть естественными. Например, внешний вид CommandBar -> NSToolbar на Mac, Navigation View -> NSOutlineView на Mac и т. д.

Мой 2c стоит, но я вижу большой акцент на этом.

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

С интересом слежу за этой дискуссией.

Silverlight, WinRT, UWP — все было заброшено. (Я знаю, что технически это не UWP, но WinUI, скорее всего, будет рассматриваться как замена).

Насколько я понимаю, UWP — это среда выполнения, тогда как WinUI — это графический интерфейс/слой виджетов и т. д. Т.е. Win UI будет работать на Win32 или .NET без UWP API.

Технически я думаю, что WinRT (Windows RunTime) — это среда выполнения, а UWP (универсальная платформа Windows) построена поверх этой среды выполнения. А UWP поддерживает использование XAML в качестве единой платформы пользовательского интерфейса.

WinUI будет частью XAML UWP, но расширен для использования с кодом Win32, с взаимодействием через XAML Islands с платформами WPF и WinForms.

Что меня сводит с ума, так это то, что UWP на самом деле является довольно компетентным API. Он не такой мощный, как Win32, но по сравнению с Android (например) он намного разумнее. Я думаю, что разработчики упустили тот момент, что теперь существует унифицированный API времени выполнения, который имеет согласованную объектную модель, API, не является тупым и т. д. и т. д. Кто-нибудь еще писал приложения Win32 еще в 90-х или раньше? 00 000 000 000 00 000 000 000 000 000 000 000 000 000 000 000 000 000 00 00 00 000 000 лет до того, как появился .NET? Использование собственных API-интерфейсов платформы было ужасным.

UWP создан с использованием современного подхода к времени автономной работы, безопасности, идентификации, проверке магазина — всему, что разработчики ожидают от таких платформ, как macOS, iOS и Android. Именно благодаря этим неотъемлемым качествам он может работать со многими форм-факторами и типами устройств.

Возвращаясь к рассматриваемой проблеме, я бы очень хотел увидеть кроссплатформенность WinUI. Есть сообщения о том, что он привязан к COM и т. д. Платформа Apple Core Foundation plugin (CFPlugin), IIRC, основана на COM, поэтому, возможно, подъем и сдвиг будут такими же простыми, как написание средства визуализации для платформ Apple. Более логичным было бы скрыть различия между платформами и сохранить объекты WinUI высокого уровня.

Если учесть поддержку .NET Core, которая уже поддерживается кросс-платформенно, уровень пользовательского интерфейса — это та часть, которой не хватает. Первоначально WinUI полностью ориентирован на Windows, но, надеюсь, со временем Microsoft сможет реорганизовать его таким образом, чтобы платформы могли заменять свой собственный рендеринг, что позволило бы запускать идентичный пользовательский интерфейс на нескольких платформах.

Мне бы хотелось увидеть сплоченную межплатформенную работу Microsoft, ориентированную в первую очередь на Windows, но купившую полностью совместимую объектную модель и диалект XAML для мобильных устройств, Linux и macOS. В .NET Core уже есть фантастическая кроссплатформенная экосистема (без графического интерфейса). Добавьте компетентную среду XAML, и это не составит труда для всей клиентской разработки, особенно если визуальные эффекты могут выглядеть естественными. Например, внешний вид CommandBar -> NSToolbar на Mac, Navigation View -> NSOutlineView на Mac и т. д.

Как только вы начнете смотреть на это таким образом, когда вы переводите Windows на собственные элементы управления и концепции платформы, вы в конечном итоге получите Xamarin Forms. Вы ориентируетесь на подход с наименьшим общим знаменателем, а не позволяете Identitcal UI работать везде.

Мой 2c стоит, но я вижу большой акцент на этом.

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

С интересом слежу за этой дискуссией.

Я думаю, что одна часть этой истории, которую еще предстоит подробно описать, — это возможность компилировать приложения UWP и запускать их на Android, что решит проблему приложений, работающих на Surface Duo.

Был проект Astoria... Android на Windows Bridge, который мог прийти в Windows, чтобы приложения Android могли поступать в Microsoft Store. Как только у Microsoft появится собственная кодовая база Android, это облегчит понимание перспективы.

Я вижу, вы ответили на идею @Pinox «отобразить WinUI как собственное приложение Blazor», но что вы думаете о другой идее Pinox? Интересно, что @Pinox также написал:

В настоящее время Electron использует Javascript, HTML + CSS. Нет причин, по которым мы не можем использовать Electron с Blazor => C#, HTML + CSS + gRPC.

Я согласен с тем, что «Электрон С#» будет иметь гораздо больше смысла, чем «Электрон JS», но если он использует С# и Blazor, как вы предложили, то я думаю, что приложению MS Teams, вероятно, больше не понадобится Electron, потому что Blazor полностью заменить Электрон? Я могу ошибаться — я недостаточно знаю, какие функции поддерживает Electron. Хотя, если у ElectronJS в настоящее время есть какая-либо полезная функция, которой нет в Blazor, то эта отсутствующая функция потенциально может поддерживаться в следующей версии Blazor.

@verelpode , насколько я понимаю, Электрон всегда должен быть на виду. Если бы Teams гипотетически перешли на Blazor, им по-прежнему требовалось бы отдельное клиентское приложение, как сегодня, и Electron для них наиболее целесообразен. Теоретически, и кто-то может поправить меня, если я ошибаюсь, но переход на Blazor + WebAssembly значительно улучшит производительность их приложений при работе в Electron. Хотя я готов поспорить, что их проблемы с производительностью в большей степени связаны с архитектурными проблемами, чем с чем-либо еще, VS Code — это приложение Electron, и я очень впечатлен его производительностью.

Имейте в виду, что WebAssembly также может работать вне WebBrowser...
Я рассматриваю Blazor как путь от ASP.Net, эксперимент, переносящий .NET в WebBrowser, но наиболее полным путем будет XAML на .NET Core, Xamarin, UWP/WinUI и UNO; Полный XAML для WinUI/Windows 10 и часть его XAML также могут работать в Интернете.

@verelpode @stevenbrix Насколько я понимаю, Blazor работает в Electron по проводам. Итак, напрямую с ядра .net на Electron с использованием gRPC. Поэтому канал gRPC связывается с электроном, а не с JS-рендерером, как я предполагаю. Пожалуйста, поправьте меня, если я ошибаюсь. WASM не задействован.

Было бы очень интересно увидеть улучшения скорости, используя gRPC непосредственно с Electron. На мой взгляд, это может быть массивным, если его оптимизировать.

В клипе Стива Сандерсона на YouTube он упоминает об использовании WASM без использования (53:13 мин видео)
https://www.youtube.com/watch?v=uW-Kk7Qpv5U

Не могу вспомнить, где я читал часть gRPC. В любом случае, поэтому я исследую сообщество, возможно ли что-то вроде Silverlight-эквивалента WinUI с использованием gRPC с Electron? Никакого WASM, так сказать на проводе.

@verelpode @stevenbrix Насколько я понимаю, Blazor работает в Electron по проводам. Итак, напрямую с ядра .net на Electron с использованием gRPC. Поэтому канал gRPC связывается с электроном, а не с JS-рендерером, как я предполагаю. Пожалуйста, поправьте меня, если я ошибаюсь. WASM не задействован.

Было бы очень интересно увидеть улучшения скорости, используя gRPC непосредственно с Electron. На мой взгляд, это может быть массивно.

В клипе Стива Сандерсона на YouTube он упоминает отсутствие WASM (53:13 мин) в видео.
https://www.youtube.com/watch?v=uW-Kk7Qpv5U

Спасибо @Pinox! Похоже, мне есть что посмотреть! То, что вы описываете, звучит для меня как Blazor на стороне сервера, я думал/говорил о стороне клиента, которая работает в браузере и напрямую манипулирует DOM. Я больше не буду говорить, пока не посмотрю это видео, потому что я могу засунуть ногу себе в рот, говоря такие вещи 😄

@stevenbrix , возможно, вы правы, но электронное приложение работает в автономном режиме, поэтому я предполагаю, что это не рендеринг на стороне сервера.

Я предполагаю, что если средство визуализации JS использует gRPC для связи с Electron, то вы можете использовать движок blazor razor, чтобы сделать то же самое.

gRPC — это новая функция в .net core 3.0. Blazor поддерживает .net core 3.
Поэтому gRPC в .net core 3 открывает возможность заменить существующие технологии JS на c# с помощью «общей ссылки» (gRPC). Умный ход МС ;))

но электронное приложение работает в автономном режиме, поэтому я предполагаю, что это не рендеринг на стороне сервера.

@Pinox - да, это меня немного озадачило. Я предполагаю, что он использует https://github.com/ElectronNET/Electron.NET , но это чисто умозрительно.

Если приложение MS Teams переключилось с ElectronJS на Blazor, то оно может использовать или не использовать какую-либо часть WinUI. Либо соединение, либо отсутствие соединения между Blazor и WinUI можно изучить дополнительно, как вы уже начали делать. Интересный! >

@verelpode, что делает это изображение очень захватывающим, так это «досягаемость» Blazor. Как специалист по приложениям, я могу сказать, что мой ограниченный опыт работы с Blazor до сих пор => вау, это кажется чрезвычайно производительным, почти как приложение. Глядя на изображение, дорожная карта почти наверняка будет включать WinUI в качестве родной платформы. (хотя в настоящее время не зафиксировано)

Если они могут заставить флаттер работать на стороне Blazor Native, что мешает команде Blazor подключить платформу React Native для доступа ко всем этим нативным платформам. Blazor может очень легко стать связующим звеном для разработчиков C# во всем.

Для меня краткосрочная цель состоит в том, чтобы сесть в автобус с пользовательским интерфейсом HTML, чтобы дополнить мой существующий WinUI.
Между WinUI/Xamarin и Blazor почти ничего не могу сделать. Одна кодовая база, 3 UI-фреймворка. Будет очень интересно увидеть, к чему это приведет, потому что варианты кажутся бесконечными.

Для меня конечной целью всегда является сверхпроизводительное ядро ​​.net (C#) => Blazor ??? => собственный пользовательский интерфейс - это будет предельная инженерная работа.

Я должен сказать, что это очень вдохновляющая дискуссия! Множество разных мнений и аргументов, множество фактов, о которых я даже не знал («Blazor + Native UI?? Вау»).

Как уже упоминал @stevenbrix , в сообществе, похоже, существует раскол между теми, кто хотел бы запускать один и тот же пользовательский интерфейс на разных платформах (подход рендерера), и теми, кто хотел бы рендерить на каждой платформе, используя собственные элементы управления. Оба подхода имеют свои преимущества и недостатки. Я согласен с @stevenbrix в том, что при наличии достаточного количества рабочей силы проблема «наименьшего общего знаменателя» может быть преодолена (например, элемент управления WinUI, изначально недоступный на платформе X, может быть реализован внутри Uno с помощью набора собственных элементов управления более низкого уровня с этой платформы X, или с частичным пользовательским рендерингом). Тогда мы могли бы иметь почти полный набор элементов управления WinUI, но при этом получить собственный рендеринг. К сожалению, ресурсы Uno сейчас кажутся довольно ограниченными, учитывая большое количество открытых вопросов на их github.

Здесь очевидно, что в сообществе существует высокий спрос на привлекательную, высокопроизводительную кросс-платформенную структуру. И ни один из доступных в настоящее время фреймворков на самом деле не удовлетворяет ни одну из двух сторон (разделенного) сообщества. Будет очень интересно посмотреть, есть ли у Microsoft планы по улучшению ситуации.

Я бы сказал, что с появлением Surface Duo и Neo на горизонте Microsoft должна придумать правильную историю о том, как разрабатывать кроссплатформенные приложения, которые работают как на Surface Duo, так и на Surface Neo. Возможно, Microsoft следует купить Uno и должным образом профинансировать их, чтобы они могли исправить все эти открытые проблемы и добавить больше поддержки контроля. Или разработайте слой рендеринга Android для WinUI. С устройствами, запланированными на праздник 2020 года, все должно начать двигаться довольно скоро.

@лукасф

при достаточном количестве рабочей силы проблема «наименьшего общего знаменателя» может быть преодолена

Достаточно рабочей силы... Я согласен со всем в вашем сообщении, но я также хотел бы подчеркнуть существенный недостаток, который упомянул @kmgallahan :

Каждый инженер и доллар, потраченные на создание кросс-платформенного WinUI, — это инженер и доллар, которые можно было бы использовать для улучшения WinUI для Windows.

Я разделился, потому что, с одной стороны, кроссплатформенность была бы отличной (если она действительно хорошо работает), но, с другой стороны, я бы не хотел кроссплатформенности, если она вызывает большие задержки в исправлении различных проблем в WinUI. в Windows или если это слишком сильно тормозит работу WinUI и блокирует улучшения и новые функции.

Что, если тема кроссплатформенности означает, что мы все вынуждены выбирать между одним из следующих исходов?

1. Отличная версия WinUI, работающая только в Windows; или
2. Среднего качества, ненадежный и/или медленный WinUI, который работает на любой платформе и страдает от мучительно медленного темпа разработки, когда многие нерешенные проблемы остаются нерешенными в течение 5–10 лет.

Это большая проблема, которую необходимо предотвратить. В азарте кроссплатформенности очень легко нечаянно перестать обращать внимание на профилактику этой большой проблемы.

Что, если тема кроссплатформенности означает, что мы все вынуждены выбирать между одним из следующих исходов?

1. Отличная версия WinUI, работающая только в Windows; или

2. Среднего качества, ненадежный и/или медленный WinUI, который работает на любой платформе и страдает от мучительно медленного темпа разработки, когда многие нерешенные проблемы остаются нерешенными в течение 5–10 лет.

@verelpode Во-первых, вы здесь многое преувеличиваете. Во-вторых, у Microsoft есть огромные ресурсы. Не должно быть проблемой финансирование как собственных улучшений WinUI, так и кроссплатформенного решения, если Microsoft действительно заинтересована в создании кроссплатформенной среды. На самом деле они делают это прямо сейчас: они разрабатывают и улучшают WinUI, и в то же время они разрабатывают и улучшают Xamarin. У них одновременно много проектов. Так что, если Microsoft действительно стремится предоставить как отличную среду пользовательского интерфейса Windows (что они, безусловно, так и делают), так и предоставить кросс-платформенную структуру (что будет иметь большой смысл с появлением Surface Neo и Duo на горизонте), то у нас нет выбирать. Оба могут быть реализованы без компромиссов. (И, как правило, это не то, что мы можем выбирать. Microsoft примет их решения, и мы увидим, каков будет результат.)

Таким образом, финансирование кросс-платформенного фреймворка вовсе не означает, что разработка и стабильность WinUI должны пострадать. Если была выбрана стратегия Uno, Uno полностью независима от WinUI, потому что находится сверху. WinUI можно развивать дальше, и Uno пытается использовать новые элементы управления и концепции WinUI (вероятно, медленнее). Кроме того, если был выбран подход рендерера, это не означает, что он задержит WinUI в Windows. Возможно, выпущена новая версия WinUI, но еще нет рендерера для Android. Затем кроссплатформенная разработка будет использовать более старую версию WinUI, пока средство визуализации Android не будет обновлено до WinUI vLatest. Разработчики Windows могли использовать WinUI vLatest с самого начала. Если есть ресурсы, то и то, и другое можно развивать одинаковыми темпами.

@лукасф

Microsoft располагает огромными ресурсами.

Верно, верно, но есть и другая сторона, которая также верна: многие менеджеры проектов на горьком опыте усвоили, что вложение большего количества денег, персонала и ресурсов в проект не обязательно приводит к успеху.

Microsoft располагает огромными ресурсами.

Верно, верно, но есть и другая сторона, которая также верна: многие менеджеры проектов на горьком опыте усвоили, что вложение большего количества денег, персонала и ресурсов в проект не обязательно приводит к успеху.

Тогда проблема может заключаться в менеджерах проектов и организационной структуре;)

Возможно, Microsoft следует купить Uno и должным образом профинансировать их, чтобы они могли исправить все эти открытые проблемы и добавить больше поддержки контроля.

Я знаю, что nventive ухаживала за Microsoft в течение последних нескольких месяцев (приобретение Microsoft, вероятно, является их стратегией ухода). На Uno Conference также было большое участие Microsoft. Даже Xamarin теперь использует Uno для поддержки Интернета.

Я знаю, что мы можем бесконечно обсуждать варианты (1) собственный рендеринг или (2) другую реализацию/уровень пользовательского интерфейса, но, глядя на то, что доступно сейчас и что нам нужно для Surface Duo, Uno на самом деле является единственным решением, которое имеет смысл. Как сказал @lukasf , Microsoft должна задействовать свои ресурсы и посмотреть, как далеко они смогут продвинуться за год. Если он будет успешным (полноценным, стабильным), я не думаю, что разработчики действительно будут сильно заботиться о том, как это реализовано за кулисами. Если станет очевидным, что правильным подходом является нативная визуализация WinUI для каждой платформы, это может стать предметом обсуждения в течение нескольких лет в будущем. Прямо сейчас лучше начать с платформы Uno, на 25% полной, чем вообще ничего.

@stevenbrix здесь :

@lukasf Я думаю, что «наименьший общий знаменатель», который в настоящее время существует в Uno, - это проблема ограничения ресурсов, а не из-за многослойности. Я хотел бы оказаться неправым, но я думаю, что эту проблему можно решить, и в будущем она не станет еще хуже.

Вы ошибаетесь.
Uno не следует мантре «наименьшего общего знаменателя» Xamarin, а наоборот, он скорее пытается убедиться, что все элементы управления XAML (и даже Windows Community Toolkit!) работают на всех платформах.

Uno не следует мантре «наименьшего общего знаменателя» Xamarin, а наоборот, он скорее пытается убедиться, что все элементы управления XAML (и даже Windows Community Toolkit!) работают на всех платформах.

@weitzhandler , ты совершенно прав! Я полагаю, что однажды их архитектура позволит полностью сравняться с набором элементов управления WinUI, что может быть невозможно с Xamarin.Forms. Если я правильно понимаю, этот набор элементов управления еще не создан, о чем мы с @lukasf говорили . Я могу ошибаться, я не играл достаточно, чтобы знать, я просто доверяю тому, что слышал от всех остальных :)

Подход @weitzhandler Uno к повторной реализации реальных API-интерфейсов UWP/WinUI намного лучше, чем изобретение Xamarin нового диалекта XAML. Но если вы запустите галерею элементов управления Uno Xaml, вы обнаружите, что некоторые области пусты. Их набор элементов управления, безусловно, лучше, чем Xamarin.Forms, но это еще далеко не полный UWP/WinUI. Я думаю, что Uno нужно больше работать над поверхностью API, а также больше работать над тем, чтобы доступные элементы управления были действительно стабильными и полнофункциональными.

Я мог видеть Uno как жизнеспособный вариант. Но для этого нужен реальный прогресс, и здесь Microsoft может вступить в игру.

В другом отношении я полностью согласен с тем, что @lukasf сказал здесь :

Отличные приложения имеют свой внешний вид. Им не нужны стандартные элементы управления платформой. Посмотрите на Spotify, Netflix

Я также думаю, что в идеале решение состоит в том, чтобы дизайн WinUI + Fluent отображался одинаково на всех платформах и, возможно, предоставлял темы с собственным внешним видом для тех, кому нужен стандартный дизайн для применения на конкретных платформах.
Я считаю, что веб должен быть таким же, как рабочий стол, поэтому в любом случае кандидатами на это являются только Droid и iOS.

Кроссплатформенные элементы управления фактически не зависят от кроссплатформенных фреймворков.

Гипотеза: в будущем элементы управления .Net не будут ограничиваться конкретными платформами.

Существуют кроссплатформенные фреймворки пользовательского интерфейса .Net (Xamarin.Forms, Avalonia). Также будет FutureXplatDotNetUI, о котором все мечтают и никто не может точно определить.

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

В любом случае ваш элемент управления можно установить в любой проект пользовательского интерфейса .Net.

Следствие: для FutureXplatDotNetUI потребуется только минимальный набор элементов управления.

Потребуется определить класс представления и инфраструктуру макета, но определенные представления или группы представлений можно добавить, установив стандартные пакеты пользовательского интерфейса .Net из nuget.

(Этот пост является комментарием к кроссплатформенному пользовательскому интерфейсу .Net и, следовательно, не имеет отношения к WinUI.)

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

@reli-msft
У меня такое ощущение, что команда WinUI уже перестала ожидать, что люди будут писать новые нативные приложения для Windows, а WinUI предназначен для обновления существующих приложений.

От человека, который работает в Microsoft, это немного странно.

У меня такое ощущение, что команда WinUI уже перестала ожидать, что люди будут писать новые нативные приложения для Windows, а WinUI предназначен для обновления существующих приложений.

От человека, который работает в Microsoft, это немного странно.

@weitzhandler
Я должен использовать более точное слово, которое я использовал ... Это не «сдаться», а «меньше заботиться». Во всяком случае, это просто мнение человека, не входящего в команду WinUI.
Но модернизация существующих приложений может быть более важной _на данный момент_, и это может быть причиной того, что WinUI решил поддерживать Win32.

Вы говорили о том, что думает команда WinUI.

Как общий MS, к сожалению, это действительно имеет смысл.
Я бы хотел, чтобы Microsoft подарила WinUI любовь к React или Electron или любой другой технологии HTML, CSS и JS (прочитайте мой комментарий выше ).

@charlesroddie

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

Вы можете совместно использовать некоторый код между элементами управления WinUI (на основе C#) и WPF, но это все равно будет сложно из-за разных пространств имен и разных API. Но совершенно невозможно совместно использовать элементы управления XAML с платформами Android или iOS.

Кроме того, я действительно не уверен, является ли .NET подходящей технологией для создания стека пользовательского интерфейса. Microsoft попробовала это с WPF, а затем, наконец, сдалась и переключилась на C++. Прерывания GC во время компоновки и рендеринга просто не производят наилучшего впечатления на конечных пользователей во времена, когда анимация становится все более и более важной. Возможно, это уже не так, если доступен Compositor, который заботится о плавной анимации, полностью независимой от потока пользовательского интерфейса. Тогда стеком управления может быть C#, и только часть рендеринга и анимации самого низкого уровня будет нативным кодом. Но тогда производительность была основной причиной полного отказа от C# в следующих средах пользовательского интерфейса XAML (Silverlight и UWP/WinUI).

@lukasf Ни один элемент управления не может работать в нескольких средах

Это неправда. Я указал два способа, которыми элементы управления могут работать в нескольких фреймворках. Первый подход заключается в написании кода для конкретной платформы. Затем вам нужно знать, какие фреймворки вы поддерживаете, чтобы связать код, специфичный для платформы, с каждым фреймворком; Вы можете сделать это прямо сейчас, но строительство лесов может быть проще в будущем. Второй подход (платформенно-независимый рендеринг) очень прост и реализуется прямо сейчас. Например, CSharpMath.SkiaSharp можно использовать на всех платформах пользовательского интерфейса .Net.

@charlesroddie Хорошо, может быть, я неправильно понял твой пост. Но тогда управление на самом деле не зависит от фреймворка. Его можно установить только в тех приложениях, платформа которых явно поддерживается элементом управления. А рендеринг — это лишь малая часть управления. Логика управления, привязка данных и обработка ввода должны быть реализованы для каждой отдельной поддерживаемой платформы, в каждом таком элементе управления, даже если вы используете независимый от платформы модуль визуализации. Мне это кажется не очень эффективным, если только поддерживаемые фреймворки не очень похожи. Как я уже говорил, можно использовать некоторый код между WPF, Silverlight и UWP. Но дальше становится очень сложно, и я сомневаюсь, что когда-нибудь увижу такой контроль.

Кроссплатформенный фреймворк обычно позволяет вам написать всю логику управления, данные и обработку ввода (а иногда даже рендеринг) только один раз для одного API, а затем он автоматически сопоставит это с каждым фреймворком. Таким образом, когда структура есть, реализация контроля становится намного эффективнее.

Его можно установить только в тех приложениях, платформа которых явно поддерживается элементом управления.

Это правда, но поддержка большего количества платформ может быть упрощена.

Логика управления, привязка данных и обработка ввода должны быть реализованы для каждой отдельной поддерживаемой платформы.

Привязку данных не нужно реализовывать с помощью инфраструктуры пользовательского интерфейса. Это заблуждение, подпитываемое преобладающими популярными, но неполноценными подходами .Net. Элементы управления должны указывать только конструкторы и свойства. Им не нужно указывать какой-либо конкретный способ привязки данных, потому что после указания свойств gettable/settable потребители могут использовать любую структуру подхода для перемещения данных, которые они хотят. (И почти любой подход/фреймворк лучше, чем привязка данных WPF/UWP/Xamarin.)

Логика управления естественным образом реализована в .Net независимым от платформы способом, так что она идеально подходит для любого предложенного мной подхода.

Обработка ввода действительно выигрывает от «кросс-платформенной среды», но это может быть очень маленькая структура управления, на которую можно ссылаться как в платформенно-зависимых, так и в кросс-платформенных проектах, с очень маленьким API, который просто определяет мышь/касание и ввод с клавиатуры. Проект управления SkiaSharp.Extended движется в этом направлении.

Если вы хотите, чтобы привязка данных работала в WPF или WinUI, вам необходимо объявить DependencyProperties. Я сильно сомневаюсь, что кто-то будет использовать элемент управления XAML, который не работает с привязкой данных. Привязка данных лежит в основе этих фреймворков и требует, чтобы DependencyProperties работали, нравится вам это или нет. Если вы их не добавите, вы не сможете использовать свой элемент управления ни в одной из текущих платформ платформы Windows.

Под «логикой управления» я подразумеваю больше взаимодействие с другими элементами управления, например определение или создание подэлементов управления для вашего элемента управления верхнего уровня, обработку данных и состояния между этими элементами управления, компоновку, синхронизацию с подэлементами управления. Это все специфичная для фреймворка работа. Это в сочетании с кодом привязки данных (если это требуется целевой платформой) и обработкой ввода, вероятно, составляет> 90% управляющего кода. Общая часть между разными реализациями фреймворка для одного такого элемента управления, вероятно, настолько мала, что мне просто не имеет смысла работать таким образом.

Я не говорю, что это невозможно сделать. Но это будет очень сложно, так как фреймворки очень разные. Я имею в виду, что такой элемент управления можно написать прямо сейчас, но я его никогда не видел. И лично я не верю, что это станет хоть сколько-нибудь популярным подходом.

вы не можете использовать свой элемент управления ни в одной из текущих платформ платформы Windows

Это не правда. Элемент управления, который не реализует DependencyProperties, можно использовать в WPF/WinUI. Это один из недостатков традиционной привязки данных .Net: она поощряет добавление ложных DependencyProperties к элементам управления, которые уже определяют устанавливаемые свойства. Огромное дублирование кода. (Кстати, межплатформенный элемент управления не будет «элементом управления XAML», и вы не должны быть обмануты неправильным использованием «XAML» в маркетинговом языке WinUI. Xaml — это необязательный язык разметки, который можно использовать с несколькими Платформы пользовательского интерфейса .Net.)

вспомогательные элементы управления для вашего элемента управления верхнего уровня

Да, для элемента управления необходимо указать подчиненные элементы управления, поэтому для того, чтобы элементы управления более высокого уровня были доступны на разных платформах, элементы более низкого уровня также будут доступны. Если элементы управления более низкого уровня доступны для разных платформ, то их легко интегрировать. Вы представляете себе, как писать элементы управления более высокого уровня перед элементами нижнего уровня, что не является эффективным подходом.

Хорошая новость заключается в том, что Microsoft уже решила убить .net native.

@robloo Я устрою вечеринку, чтобы отпраздновать это, когда это произойдет.

Даже если Uno имеет хороший надежный технический дизайн и реализацию, существует риск и опасения, что Uno может исчезнуть в течение нескольких лет из-за аналогичной проблемы с нулевым долларом или недостаточного дохода, что в конечном итоге вызывает выгорание и отмену проекта или стагнацию. Или просто самый важный разработчик Uno однажды внезапно обретает новое хобби/интерес/одержимость и теряет интерес к Uno, или новую работу/работодателя, и у него больше нет времени работать над Uno.

@verelpode
Я разделяю ту же озабоченность, вероятно, больше, чем большинство других. Я использую гораздо меньше пакетов с открытым исходным кодом, не поддерживаемых крупными компаниями (например, Oracle, Google, Microsoft), чем в среднем. Я считаю, что для этого должны быть соблюдены оба следующих условия:

1. Nventive закрывает свой бизнес. Nventive полагается на Uno в своем основном бизнесе.
2. Основные люди, стоящие за Uno, теряют интерес к этому замечательному проекту.

Что касается № 1, я слышал, что Nventive расширяет свое нынешнее здание и переезжает в более крупный объект, поэтому часть расширенной Uno Conf 2020 (от 2 до 3 дней) будет проходить в другом здании. Я не экономист, поэтому не могу предсказать, будет ли серьезная рецессия, которая заставит многие компании уйти из бизнеса. По крайней мере, сейчас я не вижу экономического спада в ближайшем будущем (уровень безработицы в нашем районе уже давно ниже 2%).

Что касается № 2, я редко вижу ту страсть, которую основные ребята из Uno питают к своему проекту. Для них это почти как благородное дело, а не просто программный продукт. Ну не передумает только дурак, так что я бы не сказал, что вероятность их потери интереса равна нулю, но, вероятно, недалеко от нуля. Честно говоря, это главная причина, по которой я наслаждаюсь и придерживаюсь Uno прямо сейчас. Как и у любой другой платформы, у Uno есть много проблем (кстати, отсутствие некоторых полезных функций для меня не проблема), но они быстро решают критические проблемы. Я думаю, что у них полдюжины или больше релизов каждый день. Одно из моих приложений не удалось опубликовать из-за известного бага платформы, и буквально больше полугода потребовалось крупной компании (😉) на его исправление (тикет я заархивировал).

Основываясь на моем обширном опыте работы со Sliverlight, Windows Phone 7/7.1/8/8.1 SDK, Windows 8/8.1/10 (WinRT, UWP…) (моим основным телефоном был Windows Phone, лучшая мобильная платформа в истории человечества, до в последнюю минуту перед тем, как у меня не было другого выбора, кроме как перейти на Android в этом году), я больше уверен в долговечности платформы Uno, чем в аналогичных вещах от Microsoft. Да, Uno основан на всех технологиях Microsoft, но они позаботятся о миграции, когда Microsoft изменит что-то под капотом.

Мне было интересно, является ли причина, по которой Мигель поддерживает Уно и выступил с основным докладом на Uno Conf, в том, что он видит Уно, как своего ребенка Моно в первые дни, а Nventive, как его Ximian.

Я готовлюсь к худшему сценарию — смерти Уно. Поскольку во всех проектах Uno используются две мои любимые технологии — C# и Xaml, я могу легко перенести их на любую новую платформу, основанную на них. По крайней мере, я могу сказать, что код C# очень хорошо устаревает. Большая часть кода в моей основной служебной библиотеке, используемой всеми проектами, старше десяти лет. Они по-прежнему отлично работают, и я подозреваю, что так и будет в ближайшие десятилетия.

@stevenbrix @weitzhandler @Pinox

Интересное обсуждение, также заметил, что здесь упоминается Blazor Native.

Была новая конференция NDC от Стива с Blazor, которую было бы интересно рассмотреть, видео выше с использованием Blazor + Native использовало Flutter в качестве средства визуализации. Но в новом видео NDC Conf Стив теперь использует Xamarin.Forms для визуализации мобильного пользовательского интерфейса с XAML-подобной разметкой. Я вижу, что Blazor Native является наиболее практичным решением для x-платформы, которое может работать прямо сейчас с WinUI, поскольку оно будет поддерживать React Native в том же духе, что и Blazor Native. Таким образом, .Net теперь может ориентироваться (веб, мобильный, Win Desktop).

ОБНОВИТЬ:
Недавно была выпущена новая версия MS Teams, в которой сокращается время, необходимое для просмотра самого последнего сообщения чата. В предыдущем сообщении я упомянул, что это заняло около 27 секунд, но, к счастью, новая версия быстрее показывает самое последнее сообщение чата.

Спасибо сотрудникам Microsoft, которые работали над этим улучшением. :улыбка:

Моя точка зрения:

Microsoft: может разработать минимальный Webview2 (аналогичный Carlo) , который может отключить почти все функции и сократить только привязку событий к пользовательскому интерфейсу HTML... возможно, все остальные функции разрабатываются на C#/собственном/выходящем за рамки сообщества (как кросс-платформенный Нативная бэкэнд-библиотека).
Я знал, насколько сложна сторона HTML/CSS, но я хотел бы использовать эти знания пользовательского интерфейса и привязку кода C# один к одному за кодом событий и т. д.

Microsoft: можно отключить одну оперативную память объемом 8/32 ГБ для тех, у кого было 4x 8 ГБ/4x 32 ГБ... Экономия энергии.

Для этого мы избавляемся от десятка приложений, разработанных с помощью Electron... которые зависят от целей Microsoft и Билла Гейтса.

Хотя лучшая цель состоит в том, чтобы все начали разрабатывать приложение и получить поддержку от какой-либо стандартной графической среды CSS3... возможно, как QT/GTK... но очень плохо, что GTK не является авторским левом и возможен, как QML с эквивалентностью .net.

ОБНОВИТЬ:
Отмените то, что я сказал в своем предыдущем сообщении о том, что проблема исправлена ​​☹️ Это не исправлено. Это странно: Пару недель казалось, что проблема ушла, но недавно проблема вернулась! Команды MS снова доставляют мне трудности и задержки, когда я просто пытаюсь просмотреть самое последнее сообщение чата.

Глючность MS Teams неудивительна, если учесть, что она написана на JavaScript. _Конечно_, приложение, написанное на JavaScript, содержит ошибки — чего ожидать иного? MS Teams использует ElectronJS, который использует JavaScript, несмотря на тот факт, что общеизвестно, что JavaScript никогда не задумывался как настоящий язык программирования, а просто надстройка для случайных сценариев для веб-браузеров.

JavaScript даже не включает проверку типов во время компиляции — настолько это плохо. Отсюда потребность в TypeScript, чтобы попытаться исправить эту _основную_ проблему в JavaScript. На самом деле, это очень серьезная проблема, если вы думаете о JavaScript как о языке программирования — JavaScript ужасен как язык программирования — но, как я уже сказал, он задумывался как обычный язык сценариев, а не язык программирования, поэтому вы можете простите JavaScript за то, что он не включает основы языка программирования, потому что программирование приложений не было целью JavaScript.

Что на самом деле не простительно, так это непонятное решение использовать случайный язык сценариев, как если бы это был язык программирования. Я был очень удивлен, увидев, что Microsoft выбрала непрофессиональный язык для такого важного приложения, как Teams. Я не думал, что кто-то может произнести имя «JavaScript», одновременно забыв, что «JavaScript» имеет в своем названии «Script», потому что это действительно язык сценариев, а не язык программирования. Каким-то образом существование слова «Script» в «JavaScript» было полностью стерто.

Члены команды WinUI усердно работали над многими улучшениями WinUI. Решение Microsoft использовать случайный язык сценариев вместо WinUI не имеет смысла.

Существует множество очень хорошо написанных и высокопроизводительных веб-приложений на JavaScript. Конечно, вы могли бы добиться еще большей производительности с другими технологиями. Но причина, по которой Teams у вас работает медленно, наверняка не в том, что он основан на JavaScript. Это вызвано плохой реализацией либо на стороне сервера, либо на стороне клиента (вероятно, проблемы с асинхронностью/поточностью). Наверняка можно было бы написать Teams на JavaScript с гораздо большей производительностью.

Не поймите меня неправильно, я вовсе не фанат JavaScript. На самом деле я думаю, что это ужасный язык. Просто скажу, что проблемы, которые вы видите, не вызваны тем, что Teams использует технологию JavaScript. Можно даже запустить движок Unreal в JavaScript с хорошей (не на высшем уровне) производительностью.

WinUI — это только среда рабочего стола Windows. Так что разработать на его основе приложение x-platform Teams не удалось, да и сегодня это невозможно. Но, возможно, проблемы с Teams помогут Microsoft задуматься о том, чтобы сделать WinUI кроссплатформенным. С настоящей x-платформой WinUI и .NET Core было бы намного проще разрабатывать отзывчивые приложения, которые хорошо масштабируются.

WinUI — это только среда рабочего стола Windows. Так что разработать на его основе приложение x-platform Teams не удалось, да и сегодня это невозможно. Но, возможно, проблемы с Teams помогут Microsoft задуматься о том, чтобы сделать WinUI кроссплатформенным. С настоящей x-платформой WinUI и .NET Core было бы намного проще разрабатывать отзывчивые приложения, которые хорошо масштабируются.

Используя Uno, WinUI является кроссплатформенным. Посмотрите на калькулятор UNO в магазине Google Play. Это портированная версия калькулятора Windows 10.

Кто-то просил сравнить UWP и Electron, вот парочка:

https://twitter.com/emiliano84/status/1198177284533956608

https://twitter.com/emiliano84/status/1198179206548602881

новое приложение XBOX это смешно, может легко занять 1,5 ГБ ОЗУ даром

было бы неплохо, если бы кто-нибудь мог снять видео, чтобы показать, насколько они медленнее по сравнению с UWP.

Я думал, что большинство участников этого обсуждения WinUI и X-платформы читали об этой истории, но на всякий случай некоторые пропустили, вот WinUI на Windows 7 — да, это возможно с Uno Platform . Когда приложение основано на Uno, оно нацелено на Windows, Интернет, iOS и Android.

@лукасф

Наверняка можно было бы написать Teams на JavaScript с гораздо большей производительностью.

Да _возможно_, а также _можно_ написать MS Teams в PowerShell с приемлемой производительностью (мне нравится PowerShell), а также _возможно_ для SpaceX перебазироваться в Россию и еще успевать запускать спутники, но это все равно будет некомпетентным управлением решение о переносе SpaceX в Россию или о написании приложения MS Teams на языке сценариев, таком как PowerShell или JavaScript. Если бы SpaceX переехала в Россию, то да, SpaceX все еще могла бы работать, это возможно, но, честно говоря, мы должны были бы сказать, что Илон Маск не был бы действительно эффективным менеджером и не знал бы, что он делает.

Я не уверен на 100%, что во всем виноват Электрон. Говорят, что Visual Studio Code также основан на Electron, но его производительность довольно высока. Приложения Electron — это в основном веб-приложения, и существуют тысячи причин плохой работы веб-приложения.

WinUI мало что может сделать, чтобы «завоевать расположение Teams». Это не технология, это продукт. Teams похожа на стартап, который встал на путь быстрого роста. Он должен работать на нескольких платформах с одинаковым набором функций, и они должны достичь этого как можно быстрее. Это единственная причина, по которой следует выбирать веб-технологии. На мобильных устройствах они могут использовать React Native, потому что это единственный способ подключиться к оборудованию с помощью JavaScript, но на настольных компьютерах им необходимо поддерживать паритет функций и удобство сопровождения кода с веб-приложением, версией для Mac и версией для Linux. Им приходится использовать платформу, ориентированную на win32, потому что они не могут ждать, пока модель приложения UWP добавит необходимые функции. Возможность совместного использования рабочего стола с возможностью выбора рабочего стола или конкретного приложения для совместного использования является одной из его ключевых функций. Именно так разрабатываются стартап-продукты. Slack использовали jquery для взлома роста, когда они только начинали, и в итоге получили действительно плохой код, но как только у них появилось время на рефакторинг, они быстро переписали все с помощью React, и теперь Slack работает намного быстрее, чем раньше. WinUI и Electron не относятся к одной категории, и по этой причине он не заменит Electron для приложений, которые действительно в нем нуждаются, независимо от того, какую функцию он добавляет.