Microsoft-ui-xaml: Discussion : WinUI vs ElectronJS et multiplateforme (améliorer WinUI pour éliminer les raisons d'utiliser ElectronJS au lieu de WinUI)

Il en va de même avec la nouvelle application Xbox Beta. Il utilise un 400 Mo qui vient d'être ouvert en tant que magasin glorifié. Le Microsoft Store n'utilise que 117 Mo lorsqu'il est actif.

Jusqu'à ce que Microsoft développe un cadre d'interface utilisateur multiplateforme, qui permette une seule interface utilisateur et une conception de contrôle sur toutes les plateformes, ElectronJS et ses semblables continueront d'être utilisés.

Exemple de la vitesse étonnante d'ElectronJS/Teams :
Tout d'abord, à titre de comparaison, j'ai chronométré le temps qu'il faut pour ouvrir Microsoft Outlook et afficher le message le plus récent dans la boîte de réception (une boîte de réception contenant un très grand nombre de messages). Cela n'a pris que quelques secondes - en fait, c'était si rapide que je n'ai pas pu arrêter le chronomètre assez vite pour obtenir une mesure précise.
Ensuite, j'ai chronométré le temps qu'il faut pour ouvrir Microsoft Teams et afficher le message le plus récent dans le chat avec un collègue : 27 secondes ! Ce temps peut être plus ou moins en fonction du nombre de messages et d'images existant dans le volet de discussion.

( MISE À JOUR 9-NOV-2019 : _Une nouvelle version de Teams a été publiée et elle améliore le temps nécessaire pour afficher le message de discussion le plus récent. L'exemple susmentionné de 27 secondes décrit désormais la version précédente de Teams. Merci au personnel de Microsoft membres qui ont travaillé sur cette amélioration._ )

La semaine dernière, j'ai cliqué sur l'icône d'aide dans Teams, puis j'ai cliqué sur « Donner des commentaires » et j'ai tapé un message. C'était étonnamment lent : à chaque fois que j'appuyais sur une touche du clavier, il fallait plusieurs secondes pour que chaque caractère apparaisse ! (Cependant, lorsque j'ai testé à nouveau "Donner des commentaires" aujourd'hui, il a pris beaucoup moins de retard que la semaine dernière, il est donc apparemment difficile de reproduire ce problème particulier.)

Si Teams était écrit à l'aide de WinUI, il n'aurait pas ces problèmes de vitesse et divers autres bogues inhabituels. Par exemple, les applications WinUI utilisent le formatage date/heure qui est configuré dans les paramètres Windows, tandis que Teams utilise toujours le formatage date/heure aux États-Unis sur 12 heures lorsque Teams est défini sur la langue anglaise et ignore les paramètres Windows - ce n'est pas ainsi que Windows les applications sont censées fonctionner. Ensuite, j'ai testé le changement de langue de Teams aujourd'hui et il a dit _"Il y a eu un problème, Teams est en train de récupérer"_. Et puis plusieurs images dans les messages du volet de discussion n'ont pas pu se charger.

De même, si Teams était écrit à l'aide de WinUI, cela ne créerait pas 5 processus Teams.

@mdtauk

Jusqu'à ce que Microsoft développe un cadre d'interface utilisateur multiplateforme, qui permette une seule interface utilisateur et une conception de contrôle sur toutes les plateformes, ElectronJS et ses semblables continueront d'être utilisés.

Bien que je sois généralement d'accord, il doit y avoir plus que cela dans cette histoire, car par exemple Microsoft OneNote est disponible pour Windows, Android et Mac, mais il n'utilise pas ElectronJS (AFAIK) et ne souffre pas de performances terribles comme Équipes.

@mdtauk

Jusqu'à ce que Microsoft développe un cadre d'interface utilisateur multiplateforme, qui permette une seule interface utilisateur et une conception de contrôle sur toutes les plateformes, ElectronJS et ses semblables continueront d'être utilisés.

Bien que je sois généralement d'accord, il doit y avoir plus que cela dans cette histoire, car par exemple Microsoft OneNote est disponible pour Windows, Android et Mac, mais il n'utilise pas ElectronJS (AFAIK) et ne souffre pas de performances terribles comme Équipes.

Microsoft dispose des ressources nécessaires pour créer des applications pour chaque plate-forme, en partageant le code autant que possible, mais sans utiliser d'interface utilisateur partagée

J'aimerais entendre tous les arguments contre l'utilisation de la plate-forme Uno qui cible plusieurs plates-formes (Windows, iOS, Android, Web) produisant des packages d'applications hautes performances à l'aide de l'API UWP maintenant, WinUI plus tard. Il utilise tout Microsoft - VS, C#, Xaml, Xamarin, mono, .Net...
Le fait de venir directement de Microsoft n'est-il pas la principale raison pour laquelle certains l'évitent ?

J'aimerais entendre tous les arguments contre l'utilisation de la plate-forme Uno qui cible plusieurs plates-formes (Windows, iOS, Android, Web) produisant des packages d'applications hautes performances à l'aide de l'API UWP maintenant, WinUI plus tard. Il utilise tout Microsoft - VS, C#, Xaml, Xamarin, mono, .Net...
Le fait de venir directement de Microsoft n'est-il pas la principale raison pour laquelle certains l'évitent ?

Cela aurait été un meilleur argument il y a quelques années, mais de nombreuses entreprises cherchant à investir dans la création d'une application ou d'un système doivent savoir que la plate-forme pour laquelle elles développent a le support et la longévité d'une grande entreprise dotée de vastes ressources comme Microsoft.

Le problème avec cet argument est que la dernière décennie a montré que Microsoft a abandonné les plates-formes et les bases d'utilisateurs, et Windows a été déplacé vers une priorité héritée ou décroissante au sein de Microsoft.

Vous ne pouvez donc pas reprocher aux nouveaux développeurs de s'orienter vers des plates-formes Web, s'ils souhaitent exécuter des services connectés - ou se concentrer sur des plates-formes en cours de développement et qui semblent bénéficier d'un solide soutien à l'avenir.

Dans le même temps, il existe quelques grandes entreprises comme Adobe, avec des applications héritées - il sera donc presque impossible de déplacer des plates-formes avec celles-ci. Il existe également des amateurs et des entreprises avec des logiciels personnalisés.

Microsoft s'en sort bien avec la prise en charge de .NET et Win32. Et WinUI peut être l'occasion d'autoriser Win32 et .NET - mais avec une interface utilisateur moderne.

Silverlight, WinRT, UWP - ont tous été abandonnés. (Je sais que UWP n'est pas techniquement, mais WinUI sera très probablement considéré comme un remplacement).

Zune, Windows Media Center, Windows Phone 7, Windows Phone 8, Windows 8 - ont laissé tomber les passionnés et ceux qu'ils ont essayé d'évangéliser.

La façon dont Microsoft positionne WinUI et garantit également que l'avenir de Windows est sécurisé sera _absolument essentiel_

WinUI for Desktop semble prometteur, mais je pense qu'au moins un sous-ensemble de son XAML doit pouvoir s'exécuter sur le Web ; WinUI sur le Web, comme un nouveau Silverlight mais fonctionnant sur .NET 5 et WebAssembly.

Silverlight, WinRT, UWP - ont tous été abandonnés. (Je sais que UWP n'est pas techniquement, mais WinUI sera très probablement considéré comme un remplacement).

Zune, Windows Media Center, Windows Phone 7, Windows Phone 8, Windows 8 - ont laissé tomber les passionnés et ceux qu'ils ont essayé d'évangéliser.

D'accord.
Je n'arrive pas à croire certains de mes Silverlight (les applications web0 sont toujours utilisées quotidiennement par certains utilisateurs.
Suivre Microsoft a été de plus en plus difficile. Les personnes derrière Uno Platform la développent et la maintiennent pour soutenir leur activité d'application de pain et de beurre. Il est open-source avec de nombreux contributeurs. J'ai l'impression de superposer un très bon bus avec des chauffeurs de premier ordre sachant bien comment naviguer dans le labyrinthe ou le désordre de Microsoft.

Mes 2 cents : le seul espoir d'UWP et de WinUI, c'est s'ils le rendent rapidement multiplateforme, inclus sur le Web, avant qu'il n'en reste plus rien.
Uno Platform est un moyen rapide, facile et probablement aussi le plus sûr d'y parvenir.
Comme @zipswich l' a mentionné, Uno a toujours été Microsoft ; dans les directives de codage, l'outillage, la sélection de la langue et le rendu, et est prêt pour la conception Fluent.
C'est 100 fois plus axé sur Microsoft que Xamarin, par exemple. Sans parler de React ou Electron, et de toutes les technologies HTML & CSS ou JS laides, MS est tellement obsédé par la flatterie et la tricherie.

Et laissez-moi être dur, C# n'est qu'un langage serveur avec l'absence de framework d'interface utilisateur .NET Standard.
Plus cela reste ainsi, Dart ou d'autres technologies deviendront des langages de serveur et prendront complètement le relais.
Vous voyez que les gens sont prêts à utiliser des langages désagréables (JS), comme un sacrifice pour pouvoir utiliser une base de code monolingue, à la fois client et serveur. C# peut disparaître tout comme XAML, ou il peut gagner avec XAML si un sauvetage d'urgence est effectué.

Je ne crois pas que Uno sera l'avenir. Il est très similaire à Xamarin.Forms, étant un framework Xaml simplifié avec de nombreuses fonctionnalités manquantes et de nombreux éléments supplémentaires compliqués ajoutés pour lui permettre de s'intégrer d'une manière ou d'une autre dans toutes les plates-formes, avec quelques hacks et solutions de contournement. Bien sûr, vous pouvez l'utiliser, mais vous êtes très limité dans les contrôles que vous avez et les API que vous pouvez utiliser. Le principal problème est qu'il essaie de réaliser l'interface utilisateur Xaml avec les contrôles natifs de chaque plate-forme. Ceci est toujours problématique et ne vous laisse qu'un petit sous-ensemble de fonctionnalités qui fonctionnent sur toutes les plateformes.

L'avenir serait d'utiliser la vraie WinUI et de fournir un véritable moteur de rendu pour chaque plateforme, implémenté dans le moteur 3D natif de la plateforme. Cela nous procurerait l'ensemble complet de fonctionnalités, toutes les qualités de WinUI, fonctionnant avec des performances natives, multiplateformes.

En fait, Microsoft avait déjà quelque chose comme ça qui fonctionnait très bien : l'interface utilisateur UWP était principalement basée sur le code Silverlight, et Microsoft avait des plugins Silverlight pour toutes les principales plates-formes, ce qui signifie qu'ils ont déjà des moteurs de rendu de base pour toutes ces plates-formes. Ils ne sont pas à jour, car UWP a maintenant beaucoup d'ajouts par rapport à Silverlight. Mais c'est une base sur laquelle on peut s'appuyer.

Microsoft a certainement les ressources pour y parvenir. C'est ce que les gens veulent, et c'est ce qu'ils devraient faire.

C# peut s'estomper tout comme XAML >

Je ne suis absolument pas d'accord avec cette déclaration concernant C#. C# est beaucoup plus gros que XAML. Si vous suivez Blazor, vous saurez que cela ne peut pas être vrai. Je vois Blazor comme un changeur de jeu pour moi en utilisant principalement UWP / Xamarin et pour les développeurs C# en général ciblant spécifiquement les utilisateurs professionnels.

Ce serait bien d'avoir WinUI x-platform mais je pense que le chemin le plus simple vers le web / x-platform est Blazor, surtout maintenant que Blazor prend également en charge les classes partielles, ce qui signifie que je peux prendre la plupart de mon code existant tel quel et commencer à l'utiliser dans Blasard. Quelques problèmes pourraient être des alternatives à Sqlite , Shared Projects et ReactiveUI. Je devrais pouvoir utiliser mon architecture MVVM existante et la porter assez facilement sur Blazor.

La pierre d'achoppement la plus importante pour moi est le manque de prise en charge de .net core 3 dans UWP. Je pense qu'il est essentiel pour MS d'aligner Blazor + UWP dans l'expérience du développeur. Je sais que l'équipe UWP y travaille.

De plus, j'aimerais voir les pages Blazor dans les applications UWP / WInUI. Le modèle d'interface utilisateur hybride fonctionnerait parfaitement pour moi dans les applications UWP afin que je puisse utiliser les meilleurs actifs d'interface utilisateur disponibles. (html5 contre XAML) et également ne pas reproduire mon effort d'interface utilisateur entre UWP et Blazor où cela a du sens.

Actuellement, Electron utilise Javascript, HTML + CSS. Aucune raison pour laquelle nous ne pouvons pas utiliser Electron avec Blazor => C# , HTML + CSS + gRPC

mais vous êtes très limité dans les contrôles que vous avez et les API que vous pouvez utiliser.

@lucasf Avez-vous essayé Uno ? Saviez-vous que Uno permet d'utiliser n'importe quelle API native via Xamarin au cas où il n'y aurait pas d'API UWP appropriée. Je n'utilise que quelques API natives dans mes applications basées sur Uno, même pour mon application de streaming vidéo en temps réel qui utilise un codec matériel et nécessite une faible latence.

mais vous êtes très limité dans les contrôles que vous avez et les API que vous pouvez utiliser.

@lukasf Avez-vous essayé Uno ? Saviez-vous que Uno permet d'utiliser n'importe quelle API native via Xamarin au cas où il n'y aurait pas d'API UWP appropriée. Je n'utilise que quelques API natives dans mes applications basées sur Uno, même pour mon application de streaming vidéo en temps réel qui utilise un codec matériel et nécessite une faible latence.

@zipswich L'ensemble de contrôles Xaml standard dans Uno est assez petit, loin de ce que UWP ou WinUI3 complet a à offrir. Pour réaliser des interfaces utilisateur correctes/complexes, vous devez généralement intégrer des contrôles et du code d'interface utilisateur natifs spécifiques à la plate-forme. Ainsi, au final, vous vous retrouverez avec un mélange de plusieurs plates-formes d'interface utilisateur (Uno Xaml, Android natif, iOS natif, peut-être Windows ou WebAssembly natif). Ce n'est pas ce que j'appelle une grande expérience de développeur.

Si nous avions des moteurs de rendu natifs de la plate-forme x pour WinUI, nous n'avions qu'une seule interface utilisateur avec l'ensemble complet des fonctionnalités de WinUI, sans aucun élément spécifique à la plate-forme. Et WinUI rendrait directement sur le GPU avec des performances complètes, comme vous vous y attendriez. Pas besoin d'ajouter des commandes Android supplémentaires ou des commandes iOS supplémentaires. Voici à quoi devrait ressembler le développement de la plate-forme x.

Que manque-t-il à WinUI (et comment peut-il être amélioré) pour convaincre les responsables de programmes Microsoft pour Microsoft Teams de passer d'ElectronJS à WinUI/UWP ?

Grande question. Un grand nombre d'utilisateurs seront très heureux s'ils le faisaient.

Un facteur important est le manque de mesures de performance comparant les cadres. Une page qui compare les applications équivalentes réalisées dans UWP et Electron et compare la vitesse et l'utilisation de la mémoire serait suffisante. Cela pourrait s'étendre à d'autres cadres. À partir de ces coûts pour les utilisateurs, les effets sur l'utilisation et les avantages de la consolidation du code peuvent être mis en balance avec les coûts financiers.

Le manque actuel de cette recherche aide les cadres inefficaces à devenir populaires.

Pour parler honnêtement : je doute que MS ait l'intention de rendre "WinUI" ( Windows UI) multiplateforme. En plus de cela, le fait qu'il soit désormais open source signifie généralement que Microsoft ne le considère plus comme une technologie critique/stratégique. Ils essaient plutôt d'exploiter les ressources de la communauté pour réduire les effectifs internes tout en les maintenant en vie. Ne vous méprenez pas, je suis heureux que WinUI soit maintenant open source et j'apprécie tout le temps que les développeurs de Microsoft consacrent à la plate-forme pour l'amener à WinUI 3.0 - c'est une excellente étape pour consolider la plate-forme de présentation Windows à la fois native et applications gérées. Je ne pense tout simplement pas que Microsoft voit Windows comme l'avenir et je ne pense pas qu'ils soient intéressés à l'utiliser sur plusieurs plates-formes (bien sûr, c'est leur erreur si c'est vrai).

Un véritable cadre de développement multiplateforme qui n'oblige pas les développeurs à utiliser une technologie inférieure à la normale est ce dont le monde a besoin. On dirait que la plupart des gens ici sont d'accord. Cela signifie en grande partie :

• Une bibliothèque de contrôles et un balisage (XAML) qui peuvent être rendus comme les conceptions natives de la plate-forme (nous n'aurions besoin que des styles de contrôle pour iOS, Android, etc.)
• Doit être écrit en code managé comme l'était WPF. Uniquement les couches de base en C++, les contrôles ne doivent jamais être autre chose que C#.
• Le rendu doit être fait avec Metal/Vulcan/DirectX (pas au dessus des contrôles existants comme Uno)
• L'entrée doit être ré-implémentée d'une manière plate-forme X
• L'accessibilité est un gros problème qui est malheureusement beaucoup plus facile à résoudre en utilisant l'approche d'Uno

Si c'est ce que nous voulons, je pense que WinUI ne le fera pas. Le fait et la manière dont il est implémenté de manière native (une couche COM/.net entre les deux) signifie qu'il serait très difficile de prendre cette plate-forme croisée. Au lieu de cela, nous avons UNO et Avalonia. Avalonia est la vraie lumière au bout du tunnel mais ils n'ont pas de ressources. Ce qui est plus ou moins possible maintenant, c'est d'utiliser la technologie de rendu Avalonia comme backend à WPF (la partie gérée). Cela nous donnerait un véritable cadre d'interface utilisateur multiplateforme en peu de temps. Le problème est que WPF est conçu pour le bureau et UWP a beaucoup travaillé pour rendre WPF/Silverlight compatible avec les appareils de la taille d'un téléphone et les entrées tactiles/interactives modernes.

Honnêtement, je pense qu'à ce stade, nous serions mieux si nous jetions tous de l'argent et des contributions de code à Avalonia. Nous demandons depuis trop longtemps à Microsoft une interface utilisateur multiplateforme et ils se contentent de passer eux-mêmes aux technologies Web. Microsoft est même en train de convertir des applications UWP comme XBox en technologies Electron et Web. Les applications ne se vendent pas non plus dans le Microsoft Store.

L'ironie est que Microsoft a eu tellement de succès dans le passé parce qu'il a donné aux développeurs les outils dont ils avaient besoin pour créer de superbes applications. Cela attire les utilisateurs et vous avez une boucle de rétroaction très constructive. À un moment donné, cela a été oublié. Désormais, les développeurs ont recours à des technologies médiocres (HTML/CSS n'a jamais été conçu à l'origine pour les applications... c'était pour le balisage de documents !) dépassent de loin les sacrifices en termes de fonctionnalité, d'intégration système et de performances à ce jour et à cette heure.

L'ironie est que Microsoft a eu tellement de succès dans le passé parce qu'il a donné aux développeurs les outils dont ils avaient besoin pour créer de superbes applications. Cela attire les utilisateurs et vous avez une boucle de rétroaction très constructive. À un moment donné, cela a été oublié. Désormais, les développeurs ont recours à des technologies de qualité inférieure (HTML/CSS n'a jamais été conçu à l'origine pour les applications... c'était pour le balisage des documents !)

Bien dit. Outre BASIC, j'ai commencé à utiliser les IDE Microsoft de Quick C, puis VC++... Microsoft avait l'habitude d'évoluer, d'innover de manière stable, cohérente, quelque peu prévisible. Nous avons essayé de le suivre, et il semble suivre la tendance de ceux qui sont censés nous suivre. J'avais l'habitude de dire aux stagiaires des universités de recherche de premier plan d'utiliser les technologies Microsoft pour les applications d'entreprise sur lesquelles ils devaient travailler. Il n'y avait aucune résistance, et ils ont rapidement récupéré les trucs de Microsoft. Je me demandais si Microsoft avait regardé à quoi ressemblaient les enfants de nos jours, alors suivez-les.

Les applications ne se vendent pas non plus dans le Microsoft Store.

Vrai malheureusement. Cependant, je blâme le pire magasin d'applications (pour les utilisateurs et les éditeurs), pas les technologies de développement. Le ratio de téléchargements quotidiens de la version UWP vs Android d'une application : 1:20 . Ils coûtent à peu près le même effort de développement. Ce n'est pas une exagération. Je viens de jeter un œil aux données de téléchargement d'hier. Si je travaillais pour un compteur de haricots, je serais licencié immédiatement pour avoir consacré tant d'efforts à la version UWP qui génère si peu de retour.

Vrai malheureusement. Cependant, je blâme le pire magasin d'applications (pour les utilisateurs et les éditeurs), pas les technologies de développement.

@zipswich , oui, vous avez un bon point. Je supposais simplement que Microsoft voit en interne les chiffres des ventes et suppose (correctement) que l'écosystème est en train de mourir. Cela les convainc ensuite que les types de technologies de développement sous-jacentes dont nous parlons sont obsolètes, ils commencent donc à investir et à aller dans d'autres directions. En réalité, la plupart des développeurs d'applications Microsoft peuvent voir le besoin évident d'un cadre multiplateforme qui n'est pas écrit en oubliant les 20 dernières années d'avancement technologique de l'interface utilisateur (WPF a vraiment changé la donne lorsqu'il est apparu).

Nous n'avons pas seulement besoin de plusieurs plates-formes : nous avons besoin de quelque chose qui soit fait avec des langages et un balisage puissants/évolutifs et qui ait une portée significative (destiné aux applications, un bon catalogue de contrôle) dès le début. Je pense que nous ne pouvons plus compter sur Microsoft pour cela. Ils ont clairement indiqué qu'ils voyaient des bénéfices plus élevés en dépensant leur temps/ressources dans d'autres domaines.

Je serais immédiatement licencié pour avoir consacré tant d'efforts à la version UWP qui génère si peu de retour.

Je vous entends, j'ai également fait cette déclaration sur la base de ma propre application dans le Microsoft Store.

@robloo Vous avez de bons points là-bas, mais je ne vous suis pas vraiment. Voici quelques réflexions :

• Microsoft a également investi beaucoup d'efforts et de ressources dans d'autres frameworks open source, tels que .NET Core, ASP.Net Core, EF Core. De toute évidence, ils voient l'avenir dans le développement open source et multiplateforme (au moins pour les applications serveur). Ils placent également des ressources dans la compilation AOT, de sorte que .NET Core peut également être compilé sur iOS et Android (où JIT n'est pas autorisé). Je ne peux donc pas vous suivre en disant que WinUI est mort maintenant, simplement parce qu'ils le rendent open source. Je veux dire, cela pourrait être vrai, mais si votre seul argument est "parce qu'ils le rendent open source", alors ce n'est pas très convaincant.

• Qt est un framework d'interface utilisateur multiplateforme, implémenté en C/C++ natif. Il possède des moteurs de rendu OpenGL/Direct3D à accélération matérielle, il a donc la même apparence et offre d'excellentes performances sur toutes les plates-formes. Aucun code spécifique à la plate-forme n'est nécessaire, tous les contrôles s'exécutent sur toutes les plates-formes, y compris iOS et Android. Alors pourquoi ne serait-il pas techniquement possible d'exécuter WinUI sur iOS et Android, si Qt peut faire exactement cela ? WinUI est implémenté dans WinRT, qui est en C++ natif, tout comme Qt. En interne, il n'utilise que quelques technologies COM (interface IUnknown plus le système d'usine COM). Il ne devrait pas être trop difficile de supprimer cela ou de ré-implémenter ce qui est nécessaire pour d'autres plates-formes. Je ne pense pas qu'un code COM soit directement utilisé dans le code WinUI.

• Silverlight utilisait la même technologie et était disponible sur la plate-forme X.

• Windows est toujours le système d'exploitation de bureau numéro 1, très utilisé, non seulement à la maison mais aussi (surtout) par les entreprises. Combiné aux licences Office, il génère beaucoup de revenus solides pour Microsoft. Ils perdraient ces revenus s'ils laissaient mourir toutes les principales plates-formes de développement d'interface utilisateur. WinForms et WPF sont déjà morts, donc WinUI est la seule plate-forme d'interface utilisateur active sur Windows. Je ne crois pas qu'ils veuillent se débarrasser du système complet Windows/Office/Entreprise, donc je ne pense pas qu'ils veuillent se débarrasser de WinUI.

• Rendre WinUI open source est idéal pour les développeurs, pas seulement pour Microsoft.

• Il se peut que UWP va mourir. De nombreux développeurs s'en éloignent à cause de toutes les limitations stupides. Le Windows Store n'est pas réussi à distance. Windows Phone est mort, ce qui était la principale raison pour laquelle même tout l'UWP a été lancé.

• Apporter WinUI aux applications de bureau avec WinUI 3.0 et le rendre open source, pourrait en fait être l'étape pour le sauver, pas le tuer !

Je supposais simplement que Microsoft voit en interne les chiffres des ventes et suppose (correctement) que l'écosystème est en train de mourir. Cela les convainc ensuite que les types de technologies de développement sous-jacentes dont nous parlons sont obsolètes, ils commencent donc à investir et à aller dans d'autres directions.

@robloo Cela ne doit pas être le cas. J'ai toujours dit que c'était le pire magasin d'applications qui avait tué Windows Phone, la meilleure plate-forme mobile.

Ils peuvent faire d'une pierre deux coups : externaliser le magasin à un tiers compétent et mettre fin au cauchemar .Net Native. Cela réduira leur coût et (je crois) double, quadruple... Les téléchargements d'applications Windows sont rapides. Plus de 90% de mes problèmes d'application UWP sont uniquement liés au cauchemar .Net Native.

@lukasf Je pense que vous avez mal interprété beaucoup de ce que je disais.

Je ne peux pas vous suivre en disant que WinUI est mort maintenant, simplement parce qu'ils le rendent open source.

Je ne dirais jamais que WinUI est mort. J'ai dit que Microsoft ne le considère probablement plus comme un produit critique/stratégique à long terme. Ils constatent des bénéfices plus élevés dans d'autres domaines (services et cloud) et s'assurent donc de passer leur temps là où les bénéfices sont plus élevés pour les actionnaires. Cela signifie que je pense qu'ils ne développeront pas de manière significative WinUI pour le rendre multiplateforme et le maintenir en vie , ce que je me suis assuré de dire au lieu de "mort". (Je ne suis pas quelqu'un sur UWP/WinUI, c'est le train mort). Je pense également très fortement que Microsoft fait une grande chose avec WinUI 3.0, ce que j'ai déclaré. Cela permet à tous les Windows, natifs et gérés de win32, de se consolider avec un seul cadre d'interface utilisateur.

Alors pourquoi ne serait-il pas techniquement possible d'exécuter WinUI sur iOS et Android

Tout est techniquement possible. Je disais que ce serait extrêmement difficile car il a été conçu et mis en œuvre uniquement pour Windows. J'ai également donné l'exemple de la façon dont il communique avec le code managé, ce qui, à mon avis, serait très difficile à utiliser sur plusieurs plates-formes. Ce serait bien pour nous tous si je me trompais ici.

Silverlight utilisait la même technologie et était disponible sur la plate-forme X.

Et Silverlight est mort non pas parce que ce n'était pas techniquement possible, mais parce que ce n'était plus une bonne analyse de rentabilisation, ce qui est vraiment mon point le plus critique. Notez qu'il est également mort aux mêmes technologies HTML/CSS/JS qui prennent désormais en charge le développement de bureau et mobile.

Ils perdraient ces revenus s'ils laissaient mourir toutes les principales plates-formes de développement d'interface utilisateur.

Cela pourrait probablement être discuté de différentes manières, mais cela devient probablement totalement hors de portée du sujet assez rapidement (ce que je sais que je fais déjà). En fin de compte, bien sûr, Microsoft ne laissera pas toutes les plates-formes d'interface utilisateur Windows mourir. Vous devez toujours écrire des applications pour Windows... Je n'ai jamais dit le contraire.

Rendre WinUI open source est idéal pour les développeurs, pas seulement pour Microsoft.

J'ai dit "Je suis heureux que WinUI soit open source maintenant et j'apprécie tout le temps que les développeurs de Microsoft consacrent à la plate-forme pour l'amener à WinUI 3.0". des raisons que je n'ai pas abordées. À titre d'exemple, même la plate-forme Uno ayant désormais accès à la source est excellente, comme ils l'ont déclaré à UnoConf.

Il se peut que UWP va mourir.

Attends, tu es de quel côté ? haha. Mais sérieusement, je considère que WinUI/UWP est essentiellement la même chose et UWP n'aura qu'une évolution mineure vers WinUI sans aucun problème majeur pour les développeurs.

Apporter WinUI aux applications de bureau avec WinUI 3.0 et le rendre open source, pourrait en fait être l'étape pour le sauver, pas le tuer !

Je suis d'accord avec toi et je n'ai jamais eu l'intention de dire le contraire. Je regardais cependant quelques tendances plus larges et je parlais également de les utiliser sur plusieurs plates-formes.

@zipswich

Ils peuvent faire d'une pierre deux coups : externaliser le magasin à un tiers compétent et mettre fin au cauchemar .Net Native. Cela réduira leur coût et (je crois) double, quadruple.

La bonne nouvelle est que Microsoft a déjà décidé de tuer le natif .net. Techniquement, il y avait un certain nombre de restrictions ridicules qui ne suivaient pas les spécifications .net avec lesquelles il semble que vous soyez plus que familier. Je pense que c'était quelque chose qui a été fait rapidement / sale pour résoudre les problèmes de démarrage et de performances sur Windows Phone et ils n'ont jamais pris la peine de revenir en arrière et de réparer les choses depuis la mort de Windows Phone.

À présent, Microsoft développe une compilation AOT complète et hautes performances en utilisant les technologies Mono et LLVM. Cela devrait sortir d'ici l'année prochaine, je pense, et est également utile pour Blazor côté client avec l'assemblage Web. Miquel de Icaza a fait une bonne présentation à ce sujet plus tôt cette année à UnoConf : https://www.youtube.com/watch?v=tYk2us6W6Gg (il est le premier présentateur).

@robloo D'accord, peut-être que je me suis trompé sur certains points.

Alors pourquoi ne serait-il pas techniquement possible d'exécuter WinUI sur iOS et Android

Tout est techniquement possible. Je disais que ce serait extrêmement difficile car il a été conçu et mis en œuvre uniquement pour Windows. J'ai également donné l'exemple de la façon dont il communique avec le code managé, ce qui, à mon avis, serait très difficile à utiliser sur plusieurs plates-formes. Ce serait bien pour nous tous si je me trompais ici.

Silverlight utilisait la même technologie et était disponible sur la plate-forme X.

Et Silverlight est mort non pas parce que ce n'était pas techniquement possible, mais parce que ce n'était plus une bonne analyse de rentabilisation, ce qui est vraiment mon point le plus critique. Notez qu'il est également mort aux mêmes technologies HTML/CSS/JS qui prennent désormais en charge le développement de bureau et mobile.

Mon point ici est le suivant : Silverlight fonctionnait déjà sur plusieurs plates-formes. Il peut être utilisé avec du code managé. La couche d'interface utilisateur UWP Xaml de Windows 8 était essentiellement Silverlight, avec juste un nouvel espace de noms et quelques métadonnées ajoutées. À présent, il a évolué, mais au début, il ne s'agissait clairement que de Silverlight Xaml avec un nouvel espace de noms. Ainsi, s'ils pouvaient exécuter Silverlight sur plusieurs plates-formes à l'époque, ils peuvent également exécuter WinUI sur plusieurs plates-formes. Et je ne pense pas que ce sera "extrêmement difficile" mais je dirais plutôt que ce serait plutôt facile pour une grande entreprise comme Microsoft. Ils disposaient déjà d'une couche de rendu multiplateforme pour Silverlight Xaml. Il ne devrait pas être trop difficile de le mettre à jour afin qu'il puisse exécuter la dernière version de WinUI.

Il se peut que UWP va mourir.

Attends, tu es de quel côté ? haha. Mais sérieusement, je considère que WinUI/UWP est essentiellement la même chose et UWP n'aura qu'une évolution mineure vers WinUI sans aucun problème majeur pour les développeurs.

WinUI n'est qu'une couche d'interface utilisateur Xaml, tandis qu'UWP est un cadre d'application complet et une couche d'API système, liée au Windows Store et avec de nombreuses limitations par rapport aux applications de bureau classiques. Ce sont donc deux choses très différentes. Je ne sais vraiment pas si Microsoft voit un avenir dans UWP et le Windows Store. Ne pas corriger les limitations sévères de l'UWP et ne pas vraiment travailler sur les problèmes du Windows Store ne me rend pas très optimiste. Mais ils ont certainement besoin d'une sorte de cadre d'interface utilisateur, et ce sera WinUI, peu importe s'il est utilisé à partir d'UWP ou d'applications de bureau. Et s'ils veulent vraiment que cela réussisse, ils doivent le rendre multiplateforme. Sinon, les gens partiront vers d'autres frameworks, puis ils pourraient à un moment donné quitter complètement la plate-forme Windows également. Rendre WinUI multiplateforme serait un moyen de faire en sorte que les développeurs s'en tiennent à Windows.

Mon point ici est le suivant : Silverlight fonctionnait déjà sur plusieurs plates-formes. Il peut être utilisé avec du code managé. La couche d'interface utilisateur UWP Xaml de Windows 8 était essentiellement Silverlight, avec juste un nouvel espace de noms et quelques métadonnées ajoutées. À présent, il a évolué, mais au début, il ne s'agissait clairement que de Silverlight Xaml avec un nouvel espace de noms. Ainsi, s'ils pouvaient exécuter Silverlight sur plusieurs plates-formes à l'époque, ils peuvent également exécuter WinUI sur plusieurs plates-formes. Et je ne pense pas que ce sera "extrêmement difficile" mais je dirais plutôt que ce serait plutôt facile pour une grande entreprise comme Microsoft. Ils disposaient déjà d'une couche de rendu multiplateforme pour Silverlight Xaml. Il ne devrait pas être trop difficile de le mettre à jour afin qu'il puisse exécuter la dernière version de WinUI.

Je ne savais pas que l'historique de la base Silverlight utilisée pour UWP/Win8 à l'époque, si c'est le cas, cela me rend plus optimiste quant à la faisabilité de cela. Merci pour la correction!

WinUI n'est qu'une couche d'interface utilisateur Xaml, tandis qu'UWP est un cadre d'application complet et une couche d'API système, liée au Windows Store et avec de nombreuses limitations par rapport aux applications de bureau classiques. Ce sont donc deux choses très différentes.

Oui, vous avez raison et j'aurais dû choisir ma formulation plus soigneusement. L'UWP dans le modèle et l'emballage de l'application continuera certainement d'exister pour le moment. Cependant, la couche d'interface utilisateur basculera vers WinUI, ce que j'essayais de communiquer. Je pense qu'il y aura plus de changements dans les années à venir avec le remplacement du natif .net, mais les emballages/modèles d'applications/API introduits avec UWP existeront toujours sous une forme ou une autre. Je suis tout à fait d'accord pour dire que Microsoft ne voit peut-être pas d'avenir ici. Heureusement, tant que XAML et C# sont toujours là, la migration vers un nouveau modèle d'application ou l'empaquetage/la distribution est généralement relativement rapide. Si seulement Avalonia était fini...

Et s'ils veulent vraiment que cela réussisse, ils doivent le rendre multiplateforme. Sinon, les gens partiront vers d'autres frameworks, puis ils pourraient à un moment donné quitter complètement la plate-forme Windows également. Rendre WinUI multiplateforme serait un moyen de faire en sorte que les développeurs s'en tiennent à Windows.

Je suis également d'accord avec vous à 100% et j'ai dit la même chose à plusieurs endroits. J'en suis venu à la conclusion que, pour un certain nombre de raisons, cela n'arrivera pas.

Je ne peux pas être assez en désaccord avec les commentateurs disant :

WinUI 3.0 doit être multiplateforme !

1) Nous avons besoin d'un cadre d'interface utilisateur maintenant, pas dans N ans, lorsque le projet théorique multiplateforme sera stable.
2) Nous avons besoin d'un cadre d'interface utilisateur aussi proche que possible du système d'exploitation. Avec le multiplateforme, il y a toujours un compromis. Soit le plus petit dénominateur commun pour la fonctionnalité, soit un rendu de contrôle incohérent en raison d'un rendu personnalisé.

La solution, dans mon esprit, est d'avoir un autre framework qui s'appuie sur WinUI 3.0 (si vous voulez maintenir Fluent et avez peu de travail dans le rendu, les tests d'impact, etc.), ou à partir de zéro avec WinUI Composition si vous voulez des performances maximales et que cela ne vous dérange pas de faire tout le rendu et les tests vous-même (au prix potentiel de ne pas être cohérent).

Je me souviens avoir vu ces lignes il y a quelques jours :
"Le système d'exploitation n'est plus la couche la plus importante pour nous... Ce qui est le plus important pour nous, c'est le modèle d'application et l'expérience."
Il est donc évident que WinUI devrait être la meilleure expérience GUI, et je pense que ce sera, comme le meilleur de WPF, UWP et Windows 10,

Mais il est évident que le Web et son ancien javaScript+HTML sont utilisés partout, et que leurs frameworks et piles Web sont massivement utilisés, non pas parce qu'ils sont meilleurs, mais parce qu'ils sont facilement disponibles sur le navigateur Web du téléphone et le navigateur Web du bureau. Vous pouvez créer un fichier HTML dans le Bloc-notes, mettre une balise Script avec une alerte('Hello World'); et vous avez une application.

Je vois donc qu'il est possible et même nécessaire de le remplacer par .NET+XAML en utilisant WebAssembly. Nous avons besoin que .NET soit aussi omniprésent que javaScript l'est aujourd'hui.

Silverlight était une lumière d'espoir... et maintenant avec WebAssembly, je vois qu'il est possible à Silverlight de revenir.

Je serais content de ça :
WinUI étant l'interface graphique complète du système d'exploitation et au moins un sous-ensemble de son XAML pouvant s'exécuter sur le navigateur Web.

Je considère donc l'équipe UNO comme très importante et j'espère qu'elle rejoindra Microsoft dans un avenir proche pour unir ses forces sur ce merveilleux effort qu'est le WinUI.

@MarkIngramUK Ouissss

Faites de WinUI le meilleur choix d'interface utilisateur pour tous ceux qui envisagent un développement Windows natif. Finir:

• Validation des entrées et contrôle natif de la grille de données
• Les autres ~170 propositions de fonctionnalités ici
• Les autres ~300 billets ouverts
• Migration .NET Native > .NET Core (pour .NET Core 3+5, .NET Standard 2.1+ et C# 8...)
• Nouveau compilateur AOT
• Obtenez des directives de conception fluides plus cohérentes et publiées
• Affiner le système style/thème
• Diminuez les caractéristiques de composition gênantes (inclinaison, utilisation intensive de l'acrylique, révélation) et concentrez-vous davantage sur le système de profondeur + d'ombre et les animations (qui apportent de la clarté et guident les utilisateurs)

Ce sont les éléments qui rendront WinUI plus attrayant pour les personnes qui l'envisageront par rapport à Electron à l'avenir.

La cerise sur le gâteau serait alors :

• Outil(s) pour vous aider à synchroniser votre style CSS <-> XAML
• Instructions pour séparer la logique de l'application des vues pour une réutilisation maximale du code .NET sur d'autres plates-formes
• Un outil pour générer une traduction approximative unique des contrôles HTML > XAML pour permettre aux développeurs de démarrer avec leurs applications WinUI natives (plutôt que de supposer que la plupart des développeurs vont commencer avec des applications XAML et un désir de se diriger vers 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 était multiplateforme, complet et rendu exactement de la même manière sur toutes les plateformes. Qt est multiplateforme, complet et rend exactement le même sur toutes les plateformes. Vous n'obtenez un rendu incohérent et des contrôles de plus petit dénominateur commun que si vous essayez de réaliser vos contrôles en les traduisant en interne en contrôles natifs d'une plate-forme différente (ce que Xamarin et Uno essaient de faire). Si vous faites l'abstraction non pas au niveau du contrôle mais au niveau le plus bas (la couche de rendu GPU), vous pouvez obtenir une sortie identique à 100 % sur toutes les plates-formes avec l'ensemble de contrôle complet. L'ensemble de contrôle est déjà là, c'est WinUI 3.0, et c'est un excellent même maintenant. La seule chose qui manque, ce sont les implémentations de couche de rendu pour les autres plates-formes (et elles pourraient être partiellement extraites d'anciennes sources Silverlight).

J'aimerais vraiment faire du développement d'applications multiplateformes. Mais ni Xamarin ni Uno ne me semblent attrayants et je n'aime pas vraiment JS/HTML et tout ce qui est basé dessus. Malheureusement, développer exclusivement pour Windows Store est un mauvais choix si vous avez l'intention de gagner de l'argent avec. Au moins, j'ai eu des expériences assez mauvaises avec ça, et puis après que Microsoft a tué l'écosystème Windows Phone, j'y ai plus ou moins mis fin (malgré quelques petits projets "juste pour le plaisir"). Je recommencerais instantanément à travailler sur de nouvelles applications si WinUI devenait multiplateforme.

Tous les frameworks multiplateformes actuels ont des limitations plus ou moins sévères et/ou une mauvaise expérience de développement. Si Microsoft pouvait rendre WinUI multiplateforme, cela pourrait vraiment être une technologie révolutionnaire. Xamarin est déjà assez réussi, malgré tous ses bords, ses coins et ses limites. Imaginez à quel point WinUI pourrait être couronné de succès s'il s'exécutait sur toutes les plates-formes avec un ensemble complet de fonctionnalités et l'expérience de développement Visual Studio de premier ordre.

@lukasf , voici mon propos :

Silverlight était multiplateforme, complet et rendu exactement de la même manière sur toutes les plateformes.

Je ne veux pas le même rendu sur toutes les plateformes. Je veux que chaque application soit cohérente avec les autres applications sur la plate-forme cible. C'est pourquoi les contrôles natifs ont besoin d'être enveloppés - mais cela conduit alors au plus petit dénominateur commun.

@MarkIngramUK Je le vois comme ceci : des applications simples s'en tiennent aux commandes d'interface utilisateur d'une plate-forme. Les excellentes applications ont leur propre look+feeling. Ils n'ont pas besoin de contrôles de plate-forme de stock. Regardez Spotify, Netflix ou d'autres applications géniales et réussies disponibles pour plusieurs plates-formes. Vous ne pouvez pas dire la plate-forme qu'ils utilisent, simplement en regardant leurs commandes.

Je voudrais que mes applications multiplateformes aient exactement la même apparence sur toutes les plateformes.

@MarkIngramUK Heureux que vous touchiez à la réalité au-delà de la théorie. Voici la réalité pour moi : j'ai un tas d'applications qui ont évolué à partir de SL/WP > WinRT > UWP et qui devaient cibler plusieurs plates-formes hier. J'ai regardé dans Phonegap/Cordova et j'ai passé beaucoup de temps à explorer Xamarin très sérieusement, et j'ai finalement abandonné. Je suis tombé amoureux d'Uno pour de nombreuses raisons dès que j'ai commencé à l'utiliser. Pour le moment, je ne connais aucune autre technologie de plate-forme X pratique et prometteuse compatible avec C# et Xaml que je puisse utiliser dès maintenant . Lorsque WinUI évoluera vers une API de plate-forme X 1, 2 ou 3 ans plus tard, les meilleurs employés d'Uno migreront Uno d'UWP vers WinUI, et toutes mes applications basées sur Uno pourront migrer en conséquence et rapidement. Je n'ai rien à craindre maintenant.
En aucun cas, je suis contre les discussions théoriques intrigantes ici. J'adore entendre toutes sortes d'idées.

WinUI / MS ne peut-il pas tirer parti du projet Blazor pour rendre WinUI en tant qu'application "Blazor Native" ?

Je sais que Steve Sanderson a présenté Blutter où Flutter de Google peut être rendu à l'aide de Blazor (et c'est une interface utilisateur basée sur XML). Il semble que l'équipe Blazor dispose d'une technologie intéressante du côté du rendu de l'interface utilisateur pour tirer parti de différents frameworks d'interface utilisateur. Si Blazor peut gérer Flutter, il devrait pouvoir gérer un équivalent de type WinUI / Sillverlight.

Le potentiel est un écosystème MS moins fragmenté et beaucoup plus puissant, commençant par le Web et se terminant par des applications natives x-platform utilisant un .net 5 unifié.

@lukasf :

@MarkIngramUK Je le vois comme ceci : des applications simples s'en tiennent aux commandes d'interface utilisateur d'une plate-forme. Les excellentes applications ont leur propre look+feeling. Ils n'ont pas besoin de contrôles de plate-forme de stock. Regardez Spotify, Netflix ou d'autres applications géniales et réussies disponibles pour plusieurs plates-formes. Vous ne pouvez pas dire la plate-forme qu'ils utilisent, simplement en regardant leurs commandes.

Je voudrais que mes applications multiplateformes aient exactement la même apparence sur toutes les plateformes.

Nous combinons les deux approches pour nos applications (https://affinity.serif.com). Nos clients peuvent être assez vocaux si nous n'adoptons pas les normes de plate-forme communes, par exemple l'ordre des boutons dans les boîtes de dialogue (Windows est normalement OK puis Annuler, tandis que macOS est Annuler puis OK), boutons avec des coins arrondis, états de survol, cases à cocher vs commutateurs, disposition de commandes, etc. Alors oui, en apparence, nos applications se ressemblent sur les plates-formes Windows et macOS, mais nous avons des différences subtiles (rendu et interaction avec l'interface utilisateur). Nous tirons également pleinement parti de notre plate-forme hôte en utilisant leurs API natives, et nous ne sommes donc jamais soumis à des problèmes de plus petit dénominateur commun.

Je pense toujours que la discussion ci-dessus est trompeuse, WinUI est le cadre d'interface utilisateur de niveau le plus bas fourni par Microsoft. Si vous voulez une bibliothèque multiplateforme, construisez dessus. C'est l'équivalent de dire : "Win32 devrait être multiplateforme !". Non, Win32 devrait être le meilleur framework pour la plate-forme Windows. C'est le même argument ici, WinUI devrait être le meilleur framework pour la plate-forme Windows 10.

@MarkIngramUK a écrit :

WinUI est le framework d'interface utilisateur de niveau le plus bas fourni par Microsoft. Si vous voulez une bibliothèque multiplateforme, construisez dessus.

Cela me semble une solution pratique qui pourrait vraiment réussir, selon les détails (bien que pas nécessairement la seule solution). Deux couches:

1. Microsoft WinUI : pas multiplateforme.
2. Microsoft CrossXYZ-UI : multiplateforme. Son implémentation interne pour Windows serait écrite à l'aide de WinUI.

Une telle solution à 2 couches aiderait à atténuer le problème que j'ai mentionné dans mon message d'origine :

Les nouvelles versions potentielles de WinUI pourraient être considérablement retardées en raison de la quantité de travail accrue/de la difficulté à maintenir la prise en charge de plusieurs systèmes d'exploitation différents. Par exemple, « Nous aurions déjà pu publier cette nouvelle version de WinUI il y a des mois, à l'exception du problème que nous avons terminé de la déboguer uniquement pour Windows et pas encore pour Android, ni MacOS ni Apple iOS. »

D'après mon expérience du développement multiplateforme dans le passé, je noterais que cette solution à 2 couches aurait plus de succès si divers changements/ajouts étaient implémentés dans WinUI dans le but de prendre en charge et d'assister la multiplateforme séparée "CrossXYZ -UI" couche. Sinon, si WinUI ne fait rien pour aider la couche multiplateforme, d'après mon expérience, cela signifie généralement que la couche multiplateforme est souvent obligée de sauter à travers des cerceaux déformés qui rendent la programmation et la fiabilité difficiles et retardées.

Selon la théorie des couches, WinUI n'a pas besoin de connaître ou de se soucier d'une couche "CrossXYZ-UI" qui utilise WinUI, mais cette théorie fonctionne mal dans la pratique dans le monde réel, donc je dis que WinUI devrait prendre en compte et assister la couche "CrossXYZ-UI", mais je ne parle pas de l'horrible idée de créer des dépendances sur "CrossXYZ-UI" dans WinUI, et je ne parle pas de crochets privés spéciaux dans WinUI qui ne sont utilisés que par "CrossXYZ-UI ". Les 2 couches doivent toujours être maintenues séparées de manière propre. Je dis simplement que lorsque des décisions de conception d'API sont prises pour WinUI, ces décisions devraient être prises en tenant compte de leur impact sur la couche distincte "CrossXYZ-UI", et en tenant compte de la façon dont WinUI peut rendre la vie plus facile pour le " CrossXYZ-UI", non seulement en tenant compte des applications qui utilisent directement WinUI.

Je ne sais pas si Xamarin tente déjà de fonctionner de la manière à 2 couches décrite ci-dessus, mais si c'est le cas, j'imagine que cela exclut actuellement la partie de l'idée où WinUI prend en charge/assiste la couche multiplateforme séparée. Il est difficile de faire confiance à Xamarin lorsque Microsoft ne faisait pas suffisamment confiance à Xamarin pour l'utiliser pour Microsoft Teams et diverses autres applications Microsoft.

Dans le passé, j'ai publié un logiciel multiplateforme qui fonctionnait avec succès et avec de bonnes performances, mais j'ai fini par annuler le travail multiplateforme pour des raisons non techniques. Par exemple, les clients utilisant la version Linux du logiciel ont insisté pour que le prix du logiciel soit de 0 $. Ainsi, le coût de production et de maintenance de la version Linux dépassait de loin les 0 $ de revenus des « clients » utilisant Linux, il était donc manifestement insoutenable.

En tant que développeur d'applications, ce n'est pas parce que vous _pouvez_ théoriquement produire une application multiplateforme, que vous _devriez_. Fait intéressant, je remarque aujourd'hui dans les discussions multiplateformes que les gens mentionnent Android mais plus Linux. L'une des principales raisons de ce changement est probablement le problème de 0 $ susmentionné.

Plateforme Re Uno :

Même si Uno dispose d'une conception et d'une mise en œuvre techniques solides et fiables, le risque et l'inquiétude sont qu'Uno disparaisse dans quelques années en raison d'un problème similaire à 0 $ ou d'un revenu insuffisant qui finira par déclencher un épuisement professionnel et l'annulation ou la stagnation du projet. Ou tout simplement le développeur le plus important d'Uno un jour, obtenant soudainement un nouveau passe-temps/intérêt/obsession et perdant tout intérêt pour Uno, ou un nouvel emploi/employeur et plus de temps pour travailler sur Uno. Comme l'a dit @mdtauk :

de nombreuses entreprises qui cherchent à investir dans la création d'une application ou d'un système doivent savoir que la plate-forme pour laquelle elles développent a le support et la longévité d'une grande entreprise avec de vastes ressources comme Microsoft.

Je suis également d'accord avec l'autre commentaire de @mdtauk :

Le problème avec cet argument est que la dernière décennie a montré que Microsoft abandonnait les plates-formes,

Oui, Microsoft a perdu un certain degré de réputation/d'honorabilité/de fiabilité en raison de l'annulation de plates-formes. Je pense que Microsoft doit faire attention à éviter toute nouvelle perte de réputation et de fiabilité via de nouvelles annulations. Une nouvelle version d'une plate-forme existante est meilleure qu'une nouvelle plate-forme.

Même si une nouvelle version majeure d'une plate-forme existante doit introduire des changements de rupture, c'est toujours mieux (ou moins mauvais) qu'une nouvelle plate-forme avec une perte de réputation/d'honorabilité/de fiabilité qui l'accompagne. Pour les développeurs d'applications, le coût du passage à une nouvelle plate-forme est très élevé et parfois totalement inabordable. Par conséquent, chaque fois que Microsoft annule une plate-forme, c'est une très mauvaise nouvelle et endommage la relation/le partenariat entre le développeur d'applications et Microsoft.

Si vous trouvez cette approche à deux couches si attrayante, vous pouvez continuer tout de suite et utiliser Xamarin ou Uno. Vous n'avez pas à attendre de tels frameworks, ils sont déjà là et ils fonctionnent très bien. Mais vous perdrez tous les avantages et améliorations de WinUI dès que vous ciblerez Android ou iOS. Plus de NavigationView, plus d'AppBars, plus de SemanticZoom, etc. Tout ce qui est fait dans ce référentiel, toutes les améliorations ne sont pas disponibles sur plusieurs plates-formes, car plusieurs plates-formes signifient alors le plus petit dénominateur commun. Vous ne pouvez les utiliser que si vous ciblez spécifiquement la plate-forme Windows. Vous devrez donc ré-implémenter manuellement toutes les fonctionnalités intéressantes de WinUI, à l'aide des commandes natives Android ou iOS.

Si cela vous convient, utilisez simplement Xamarin ou Uno. Il n'y a pas besoin d'un troisième cadre comme celui-ci. Mais pour moi, cela ne sonne pas bien du tout. Je veux un framework avec un excellent ensemble de contrôles, qui puisse être utilisé pour cibler directement toutes les plates-formes, avec toutes les fonctionnalités sur chaque plate-forme. Je ne veux pas réimplémenter la navigation et les éléments de mon application sur chaque plate-forme séparément, avec des définitions d'interface utilisateur compliquées et en double. Pour moi, cela ressemble à une idée horrible. Si WinUI était multiplateforme en utilisant une approche de rendu, je pourrais utiliser directement toutes ses fonctionnalités et toutes les améliorations ici sur chaque plate-forme. Et si je voulais que mes contrôles ressemblent davantage à iOS sur cette cible, je pourrais simplement appliquer un ResourceDictionary iOS. Problème résolu, sans avoir à jouer avec les contrôles natifs et les implémentations d'interface utilisateur en double.

L'argument selon lequel les versions seraient retardées parce qu'un "rendeur pour une autre plate-forme n'a pas été mis à jour" est un argument irréaliste. Une couche de rendu fonctionne sur des commandes de dessin de bas niveau telles que "dessiner un rectangle, dessiner une ligne, dessiner du texte". Si vous ajoutez un nouveau contrôle à WinUI, vous écrivez votre logique de contrôle et vous fournissez un modèle de contrôle, qui utilise la grille, les bordures, les zones de texte et des trucs comme ça. Aucun nouveau contrôle ne nécessitera de mises à jour des moteurs de rendu, les moteurs de rendu seront de très bas niveau et avec un très faible taux de changements. Il n'y a que de rares cas où les moteurs de rendu auraient besoin d'être touchés, par exemple lors de l'ajout de nouveaux pinceaux ou effets. Qt utilise l'approche du moteur de rendu et c'est l'un des frameworks d'interface utilisateur multiplateformes les plus populaires. L'approche semble très bien fonctionner pour eux.

@lukasf

Je veux un framework avec un excellent ensemble de contrôles, qui puisse être utilisé pour cibler directement toutes les plates-formes, avec toutes les fonctionnalités sur chaque plate-forme.

Chaque ingénieur et dollar dépensé pour faire de WinUI cross-plat est un ingénieur et un dollar qui auraient pu être utilisés pour améliorer WinUI sur Windows.

L'argument selon lequel les versions seraient retardées parce qu'un "rendeur pour une autre plate-forme n'a pas été mis à jour" est un argument irréaliste.

Créer un moteur de rendu 1:1 parfait qui fonctionne sur iOS, Android, MacOS, Linux et Windows 7/8 n'est pas seulement une tâche simple. Il existe un nombre considérable d'API Windows 10 sur lesquelles les applications et le framework s'appuient. Vous créeriez essentiellement un tout nouveau framework d'application.

Aussi, regardez ce fil Reddit récent: Que dois-je utiliser pour l'interface utilisateur en C#

Littéralement aucune mention de WinUI et une seule demi-recommandation pour utiliser UWP. Les développeurs doivent être enthousiastes à l'idée d'utiliser WinUI sur Windows bien avant d'essayer de le rendre multiplateforme, compte tenu de tous les investissements énormes que cela nécessiterait.

@lukasf ,

vous pouvez continuer tout de suite et utiliser Xamarin ou Uno

J'y ai fait allusion dans mon article précédent, mais nous écrivons des frontaux distincts pour chaque plate-forme que nous ciblons. Windows (WPF), macOS (Cacao), iOS (UIKit).

si je voulais que mes contrôles ressemblent davantage à iOS sur cette cible, je pourrais simplement appliquer un ResourceDictionary iOS. Problème résolu

Jusqu'à ce que l'utilisateur mette à jour son système d'exploitation et que toutes les applications changent d'apparence, à l'exception de la vôtre.

Une couche de rendu fonctionne sur des commandes de dessin de bas niveau telles que ...

Vous avez besoin de plus que du rendu pour le multiplateforme. Gestion des fenêtres, saisie, gestion de texte, rendu, intégration système (par exemple barre des tâches / Aero Peek, etc.). Il n'y a aucun moyen que tenter de changer le focus de WinUI de Windows uniquement à multiplateforme ne causerait pas un retard extrême.

En termes de rendu, WinUI est construit sur Windows.UI.Composition , vous devrez donc remplacer complètement cette bibliothèque de niveau inférieur par quelque chose de multiplateforme et, espérons-le, ne pas encourir de pénalités de performances de votre abstraction, puis porter vers d'autres plateformes. Ou, réécrivez complètement WinUI pour ne pas dépendre de Windows.UI.Composition . Encore une fois, pas de petit travail.

Juste pour réitérer - je ne suis pas contre les bibliothèques multiplateformes. Ils servent un objectif, je ne pense tout simplement pas que WinUI devrait en devenir un.

@lukasf

car multiplateforme signifie alors le plus petit dénominateur commun. …... Je veux un framework avec un grand ensemble de contrôles, qui peut être utilisé pour cibler toutes les plates-formes directement, avec toutes les fonctionnalités sur chaque plate-forme.

Vous le voulez avec toutes les fonctionnalités sur chaque plate-forme -- moi aussi -- ça a l'air merveilleux ; un rêve - mais ce n'est pas parce que vous et moi le voulons que cela doit être possible et pratique. Le souhait et le résultat pourraient être très différents. Le souhait pourrait être une fonctionnalité complète alors que le résultat finit par être principalement le même problème que vous l'avez mentionné - le plus petit dénominateur commun. Votre idée a du mérite, mais elle n'est pas à l'abri du problème du plus petit dénominateur commun que vous avez mentionné.

Si WinUI était multiplateforme en utilisant une approche de rendu, je pourrais utiliser directement toutes ses fonctionnalités et toutes les améliorations ici sur chaque plate-forme.

Vraiment TOUTES ses fonctionnalités et CHAQUE amélioration sur CHAQUE plateforme ? Êtes-vous sûr qu'un objectif aussi impressionnant peut être atteint simplement en basant WinUI sur un moteur de rendu multiplateforme ? La solution est-elle si simple ? Je pense que vous rendez l'idée beaucoup plus facile qu'elle ne l'est en réalité, car en réalité beaucoup plus que le moteur de rendu est nécessaire, comme :

• Gestion des fenêtres plus flyouts, popups, menus contextuels, boîtes de dialogue modales.
• Afficher la gestion et les résolutions et répondre aux changements.
• Périphériques de saisie (clavier, souris, écran tactile avec gestes, stylet).
• Animation.
• Polices et styles, obtenir des informations et des mesures, pas seulement le rendu. Également le traitement de texte Unicode.
• Glisser déposer.
• Couper/copier/coller du presse-papiers qui fonctionne avec différents formats, pas seulement du texte.
• Défilement avec de bonnes performances, contrairement aux performances de défilement épouvantables des volets de discussion dans MS Teams.
• Lecture/chargement de ressources (de divers types) stockées dans le package d'application, telles que des ressources d'image et autres.
• Lecture audio et vidéo.
• Automatisation des lecteurs d'écran, etc. pour l'accessibilité.
• Thème/apparence cohérent avec tout ce qui est actuellement configuré dans le système d'exploitation.
• Récupération de divers paramètres du système d'exploitation qui affectent l'interface graphique, tels que le formatage international, les paramètres de la souris et du clavier, etc.
• Problèmes liés à la prise en charge des appareils mobiles, des tablettes et des ordinateurs de bureau.
• Et diverses autres choses ainsi que des centaines de détails qui sont facilement oubliés lors de l'estimation de la taille du projet et de la date de sortie.

Je pense toujours que votre idée a du mérite mais c'est beaucoup plus difficile et beaucoup moins clair que vous ne le laissiez paraître. Cela pourrait également ralentir considérablement le développement et la progression de WinUI.

WinUI / MS ne peut-il pas tirer parti du projet Blazor pour rendre WinUI en tant qu'application "Blazor Native" ?

@pinox , oui, nous le pourrions certainement, mais Blazor Native ne serait pas multiplateforme, à moins qu'il ne cible Uno (ce qui serait ma préférence personnelle).

Le multiplate-forme est certainement quelque chose auquel nous avons pensé, et nous avons fait des enquêtes assez approfondies sur différentes architectures de framework multi-plateforme. Nous sommes arrivés aux mêmes conclusions que tout le monde sur ce fil, à savoir que les deux solutions ont des avantages et des inconvénients et que nos clients sont assez divisés 😃

@lukasf Je pense que le "plus petit dénominateur commun" qui existe actuellement dans Uno est un problème de limitation des ressources, et non pas dû à la superposition. J'aimerais avoir tort, mais je pense que ce problème pourrait être résolu et ne pas empirer à l'avenir.

Il existe un sous-ensemble de XAML pour offrir le rendu des contrôles d'interface utilisateur et des fenêtres d'apparence native - ou vous pouvez posséder le moteur de rendu sur macOS, iOS, Android, Linux - et rendre les mêmes contrôles et modèles "Fluent" sur toutes les plateformes.

En plus de créer une sorte de variante de l'implémentation CoreWindow / App Window pour fonctionner avec le système d'exploitation natif, tout ce qui se trouve à l' intérieur de la fenêtre pourrait être rendu.

Sous Windows, c'est DirectX, mais Apple a Metal et Linux a OpenGL. Les développeurs devraient faire une sorte d'instructions IF pour gérer les E/S de fichiers natifs, les notifications, etc. - mais Xamarin aiderait avec cela

@stevenbrix -- Je vois que vous avez répondu à l'idée de @Pinox _"rendre WinUI comme une application native Blazor",_ mais que pensez-vous de l'_autre_ idée de Pinox ? Fait intéressant, @Pinox a également écrit :

Actuellement, Electron utilise Javascript, HTML + CSS. Aucune raison pour laquelle nous ne pouvons pas utiliser Electron avec Blazor => C# , HTML + CSS + gRPC.

@Pinox -- Je suis d'accord pour dire que "Electron C#" semble avoir beaucoup plus de sens que "Electron JS", mais s'il utilise C# et Blazor comme vous l'avez suggéré, alors je pense que l'application MS Teams n'aurait probablement pas besoin d'Electron plus parce que Blazor remplacerait complètement Electron? Je peux me tromper - je ne connais pas assez les fonctionnalités prises en charge par Electron. Bien que, si ElectronJS possède actuellement une fonctionnalité utile qui manque à Blazor, cette fonctionnalité manquante pourrait être prise en charge dans la prochaine version de Blazor, potentiellement.

Donc je suppose que vous avez soulevé un point important en mentionnant Blazor. Une solution décente pour l'application MS Teams pourrait être de passer d'ElectronJS à Blazor + WebAssembly. C'est vraiment intéressant.

Si l'application MS Teams est passée d'ElectronJS à Blazor, elle peut ou non utiliser une partie de WinUI. Une connexion ou une non-connexion entre Blazor et WinUI pourrait être explorée plus avant, comme vous avez déjà commencé à le faire. Intéressant!

Silverlight, WinRT, UWP - ont tous été abandonnés. (Je sais que UWP n'est pas techniquement, mais WinUI sera très probablement considéré comme un remplacement).

D'après ce que je comprends, UWP est l'environnement d'exécution, tandis que WinUI est la couche GUI / widget / etc. C'est-à-dire que Win UI s'exécutera sur Win32 ou .NET, sans l'API UWP.

Ce qui me rend dingue, c'est que UWP est en fait une API assez compétente. Ce n'est pas aussi puissant que Win32, mais comparé à Android (par exemple), c'est tellement plus sain. Je pense que les développeurs n'ont pas compris qu'il existe maintenant une API d'exécution unifiée, qui a un modèle d'objet cohérent, une API, n'est pas obtus, etc., etc. 00s avant l'arrivée de .NET ? L'utilisation des API de la plate-forme native était terrible.

Pour en revenir au problème, j'aimerais absolument voir WinUI multiplateforme. Il y a des articles sur le fait qu'il soit lié à COM, etc. Le framework du plug-in Core Foundation (CFPlugin) d'Apple est, IIRC, basé sur COM, donc peut-être qu'un lift and shift serait aussi simple que d'écrire un moteur de rendu pour les plates-formes Apple. La chose la plus logique serait de masquer les différences de plate-forme et de conserver les objets WinUI de haut niveau.

J'aimerais voir un effort cohésif et multiplateforme de Microsoft, qui cible principalement Windows, mais qui a acheté un modèle objet et un dialecte XAML entièrement compatibles avec les mobiles, Linux et macOS. Il existe déjà un fantastique écosystème multiplateforme (moins une interface graphique) dans .NET Core. Fixez-vous sur un framework XAML compétent et ce serait une évidence pour tout développement côté client, en particulier si les visuels pouvaient sembler natifs. Par exemple CommandBar -> apparence NSToolbar sur Mac, Navigation View -> NSOutlineView sur un Mac, etc.

Ma valeur de 2c, mais je vois une grande concentration sur cela.

J'ai également bon espoir (bien que je ne retienne pas mon souffle) que Microsoft réintégrera le marché avec un téléphone basé sur Windows. Être un environnement multiplateforme convaincant aiderait massivement cet objectif.

Je vais suivre cette discussion avec intérêt.

Silverlight, WinRT, UWP - ont tous été abandonnés. (Je sais que UWP n'est pas techniquement, mais WinUI sera très probablement considéré comme un remplacement).

D'après ce que je comprends, UWP est l'environnement d'exécution, tandis que WinUI est la couche GUI / widget / etc. C'est-à-dire que Win UI s'exécutera sur Win32 ou .NET, sans l'API UWP.

Techniquement, je pense que WinRT (Windows RunTime) est le runtime, et UWP (Universal Windows Platform) est construit sur ce runtime. Et UWP prend en charge l'utilisation de XAML en tant que framework d'interface utilisateur unique.

WinUI sera la partie XAML d'UWP, mais étendue pour permettre son utilisation avec du code Win32, avec une interopérabilité via les îles XAML avec les frameworks WPF et WinForms.

Ce qui me rend dingue, c'est que UWP est en fait une API assez compétente. Ce n'est pas aussi puissant que Win32, mais comparé à Android (par exemple), c'est tellement plus sain. Je pense que les développeurs n'ont pas compris qu'il existe maintenant une API d'exécution unifiée, qui a un modèle d'objet cohérent, une API, n'est pas obtus, etc., etc. 00s avant l'arrivée de .NET ? L'utilisation des API de la plate-forme native était terrible.

UWP est construit avec une approche moderne de la durée de vie de la batterie, de la sécurité, de l'identité, de la validation des magasins - tout ce que les développeurs attendent de plates-formes telles que macOS, iOS et Android. C'est en raison de ces qualités inhérentes qu'il peut fonctionner sur de nombreux facteurs de forme et types d'appareils.

Pour en revenir au problème, j'aimerais absolument voir WinUI multiplateforme. Il y a des articles sur le fait qu'il soit lié à COM, etc. Le framework du plug-in Core Foundation (CFPlugin) d'Apple est, IIRC, basé sur COM, donc peut-être qu'un lift and shift serait aussi simple que d'écrire un moteur de rendu pour les plates-formes Apple. La chose la plus logique serait de masquer les différences de plate-forme et de conserver les objets WinUI de haut niveau.

Lorsque vous tenez compte de la prise en charge de .NET Core, qui est déjà prise en charge sur plusieurs plates-formes, la couche d'interface utilisateur est la partie manquante. Au départ, WinUI est entièrement axé sur Windows, mais j'espère qu'avec le temps, Microsoft pourra le refactoriser de manière à ce que les plates-formes puissent substituer leur propre rendu, ce qui permettrait à une interface utilisateur identique de s'exécuter sur plusieurs plates-formes.

J'aimerais voir un effort cohésif et multiplateforme de Microsoft, qui cible principalement Windows, mais qui a acheté un modèle objet et un dialecte XAML entièrement compatibles avec les mobiles, Linux et macOS. Il existe déjà un fantastique écosystème multiplateforme (moins une interface graphique) dans .NET Core. Fixez-vous sur un framework XAML compétent et ce serait une évidence pour tout développement côté client, en particulier si les visuels pouvaient sembler natifs. Par exemple CommandBar -> apparence NSToolbar sur Mac, Navigation View -> NSOutlineView sur un Mac, etc.

Dès que vous commencez à le regarder de cette manière, où vous traduisez Windows en contrôles et concepts natifs de la plate-forme, vous vous retrouvez avec Xamarin Forms. Vous ciblez une approche du plus petit dénominateur commun, plutôt que de permettre à une interface utilisateur identique de s'exécuter partout.

Ma valeur de 2c, mais je vois une grande concentration sur cela.

J'ai également bon espoir (bien que je ne retienne pas mon souffle) que Microsoft réintégrera le marché avec un téléphone basé sur Windows. Être un environnement multiplateforme convaincant aiderait massivement cet objectif.

Je vais suivre cette discussion avec intérêt.

Je pense qu'une partie de cette histoire, qui n'a pas encore été détaillée, consiste à permettre aux applications UWP de se compiler et de s'exécuter sur Android, ce qui résoudrait le problème des applications s'exécutant sur le Surface Duo.

Il y a eu le projet Astoria... L'Android sur Windows Bridge, qui pourrait venir sur Windows pour permettre aux applications Android de venir sur le Microsoft Store. Une fois que Microsoft a sa propre base de code Android, cela rend le prospect plus facile à concevoir.

Je vois que vous avez répondu à l'idée de @Pinox « rendre WinUI en tant qu'application native Blazor », mais que pensez-vous de l'autre idée de Pinox ? Fait intéressant, @Pinox a également écrit :

Actuellement, Electron utilise Javascript, HTML + CSS. Aucune raison pour laquelle nous ne pouvons pas utiliser Electron avec Blazor => C# , HTML + CSS + gRPC.

Je conviens que "Electron C#" semblerait avoir beaucoup plus de sens que "Electron JS", mais s'il utilise C# et Blazor comme vous l'avez suggéré, alors je pense que l'application MS Teams n'aurait probablement plus besoin d'Electron parce que Blazor le ferait remplacer complètement Electron? Je peux me tromper - je ne connais pas assez les fonctionnalités prises en charge par Electron. Bien que, si ElectronJS possède actuellement une fonctionnalité utile qui manque à Blazor, cette fonctionnalité manquante pourrait être prise en charge dans la prochaine version de Blazor, potentiellement.

@verelpode si je comprends bien, Electron devra toujours être dans l'image. Si les équipes devaient hypothétiquement passer à Blazor, elles voudraient toujours une application cliente autonome comme elles le font aujourd'hui, et Electron a le plus de sens pour elles. En théorie, et quelqu'un peut me corriger si je me trompe, mais le passage à Blazor + WebAssembly améliorerait considérablement les performances de leur application lors de l'exécution dans Electron. Bien que je parie que leurs problèmes de performances sont dus à des problèmes architecturaux plus qu'à toute autre chose, VS Code est une application Electron et je suis très impressionné par ses performances.

Gardez à l'esprit que WebAssembly peut également s'exécuter en dehors du navigateur Web...
Je vois Blazor comme un moyen de ceux venant d'ASP.Net, une expérience apportant le .NET au navigateur Web, mais le chemin le plus complet serait XAML sur .NET Core, Xamarin, UWP/WinUI et UNO ; Le XAML complet sur WinUI /Windows 10 et une partie de son XAML pouvant également s'exécuter sur le Web.

@verelpode @stevenbrix Je crois comprendre que Blazor fonctionne sur le fil dans Electron. Donc directement du noyau .net à Electron avec l'utilisation de gRPC. Par conséquent, le canal gRPC communique avec l'électron et non plus le moteur de rendu JS, je suppose. Veuillez me corriger si je me trompe. Il n'y a pas de WASM impliqué.

Il serait vraiment intéressant de voir les améliorations de vitesse en utilisant gRPC directement avec Electron. Dans mon esprit, cela peut être énorme s'il est optimisé.

Dans le clip youtube de Steve Sanderson, il mentionne l'utilisation de l'absence de WASM (53:13 min dans la vidéo)
https://www.youtube.com/watch?v=uW-Kk7Qpv5U

Je ne me souviens plus où j'ai lu la partie gRPC. Quoi qu'il en soit, pour moi, sonder la communauté si quelque chose comme un équivalent Silverlight de WinUI utilisant gRPC avec Electron est possible ? Pas de WASM, sur le fil pour ainsi dire.

@verelpode @stevenbrix Je crois comprendre que Blazor fonctionne sur le fil dans Electron. Donc directement du noyau .net à Electron avec l'utilisation de gRPC. Par conséquent, le canal gRPC communique avec l'électron et non plus le moteur de rendu JS, je suppose. Veuillez me corriger si je me trompe. Il n'y a pas de WASM impliqué.

Il serait vraiment intéressant de voir les améliorations de vitesse en utilisant gRPC directement avec Electron. Dans mon esprit, cela peut être énorme.

Dans le clip youtube de Steve Sanderson, il mentionne l'utilisation de l'absence de WASM (53:13 min) dans la vidéo.
https://www.youtube.com/watch?v=uW-Kk7Qpv5U

Merci @Pinox ! On dirait que j'ai un peu de surveillance à faire ! Ce que vous décrivez ressemble à Blazor côté serveur pour moi, je pensais/parlais du côté client qui s'exécute dans le navigateur et manipule directement le DOM. Je n'en dirai pas plus avant d'avoir regardé cette vidéo, car je pourrais me mettre le pied dans la bouche en disant de telles choses 😄

@stevenbrix, vous avez peut-être raison, mais l'application électronique s'exécute hors ligne pour moi, en supposant qu'il ne s'agit pas d'un rendu côté serveur.

Je suppose que si le moteur de rendu JS utilisait gRPC pour parler à Electron, vous pourriez utiliser le moteur de rasoir blazor pour faire de même.

gRPC est une nouvelle fonctionnalité de .net core 3.0. Blazor prend en charge .net core 3.
Par conséquent, gRPC dans .net core 3 ouvre la possibilité de remplacer les technologies JS existantes par c# en utilisant le "lien commun" (gRPC). Mouvement intelligent MS ;))

mais l'application électronique s'exécute hors ligne pour moi en supposant qu'il ne s'agit pas d'un rendu côté serveur.

@Pinox - oui, cela me laisse un peu perplexe. Je suppose qu'il utilise https://github.com/ElectronNET/Electron.NET , mais c'est purement spéculatif

Si l'application MS Teams est passée d'ElectronJS à Blazor, elle peut ou non utiliser une partie de WinUI. Une connexion ou une non-connexion entre Blazor et WinUI pourrait être explorée plus avant, comme vous avez déjà commencé à le faire. Intéressant! >

@verelpode, ce qui rend cette image très excitante, c'est la "portée" de Blazor. En tant que gars de l'application, je peux dire que mon expérience limitée avec Blazor jusqu'à présent est => wow, cela semble extrêmement performant, presque comme une application. En regardant l'image, la feuille de route inclura presque certainement WinUI en tant que plate-forme native. (bien que non engagé actuellement)

S'ils peuvent faire fonctionner le flutter du côté Blazor Native, ce qui empêche l'équipe Blazor de se connecter à la plate-forme React Native pour atteindre toutes ces plates-formes natives. Blazor peut très facilement devenir le ciment des développeurs C# dans tout.

Pour moi, l'objectif à court terme est de monter dans le bus avec une interface utilisateur HTML pour compléter mon WinUI existant.
Entre WinUI / Xamarin et Blazor, il n'y a presque rien que je ne puisse faire. Une base de code, 3 frameworks d'interface utilisateur. Cela va être extrêmement excitant de voir où cela va, car les options semblent infinies.

Pour moi, le nec plus ultra est toujours un core .net super performant (C#) => Blazor ??? => UI natives - ce sera l'effort d'ingénierie ultime.

Je dois dire que c'est une discussion très inspirante! Beaucoup de points de vue et d'arguments différents, beaucoup de faits que je ne connaissais même pas ("Blazor + Native UI ?? Wow").

Comme @stevenbrix déjà mentionné, il semble y avoir une scission dans la communauté entre ceux qui souhaitent exécuter exactement la même interface utilisateur sur différents frameworks (approche de rendu) et ceux qui souhaitent effectuer un rendu sur chaque plate-forme à l'aide des contrôles natifs. Les deux approches ont leurs avantages et leurs inconvénients. Je suis d'accord avec @stevenbrix qu'avec suffisamment de main-d'œuvre, le problème du "plus petit dénominateur commun" pourrait être surmonté (par exemple, un contrôle WinUI non disponible nativement sur la plate-forme X pourrait être réalisé en interne dans Uno par un tas de contrôles natifs de niveau inférieur de cette plate-forme X, ou avec rendu personnalisé partiel). Nous pourrions alors disposer de la quasi-totalité du jeu de contrôles WinUI, tout en obtenant un rendu natif. Malheureusement, les ressources d'Uno semblent être plutôt limitées en ce moment, étant donné le grand nombre de problèmes ouverts sur leur github.

Ce qui est évident ici, c'est qu'il existe une forte demande au sein de la communauté pour un framework multiplateforme convaincant, hautes performances. Et aucun des frameworks actuellement disponibles ne satisfait vraiment l'un des deux côtés de la communauté (divisée). Il sera très intéressant de voir si Microsoft a des plans pour améliorer la situation.

Je dirais qu'avec Surface Duo et Neo à l'horizon, Microsoft doit proposer une histoire appropriée sur la façon de développer des applications multiplateformes qui s'exécutent à la fois sur Surface Duo et Surface Neo. Peut-être que Microsoft devrait acheter Uno et les financer correctement, afin qu'ils puissent résoudre tous ces problèmes ouverts et ajouter plus de support de contrôle. Ou développez une couche de rendu Android pour WinUI. Avec les appareils prévus pour les vacances 2020, les choses doivent commencer à bouger très bientôt.

@lukasf

avec suffisamment de main-d'œuvre, le problème du "plus petit dénominateur commun" pourrait être surmonté

Assez de main-d'œuvre... Je suis d'accord avec tout dans votre message, mais je voudrais aussi souligner l'inconvénient important que @kmgalahan a mentionné :

Chaque ingénieur et dollar dépensé pour faire de WinUI cross-plat est un ingénieur et un dollar qui auraient pu être utilisés pour améliorer WinUI sur Windows.

Je suis partagé car d'un côté, le multiplateforme serait génial (si ça marche vraiment bien), mais d'un autre côté, je ne voudrais pas du multiplateforme si cela cause de gros retards dans la résolution de divers problèmes dans WinUI sous Windows, ou si cela ralentit trop la progression de WinUI et entrave les améliorations et les nouvelles fonctionnalités.

Et si le sujet multiplateforme signifiait que nous étions tous obligés de choisir entre l'un des résultats suivants ?

1. Une excellente version de WinUI qui ne fonctionne que sous Windows ; ou
2. WinUI de qualité moyenne, peu fiable et/ou lent qui s'exécute sur toutes les plates-formes, et qui souffre d'un rythme de développement extrêmement lent avec de nombreux problèmes en suspens qui ne sont pas résolus pendant 5 à 10 ans.

C'est un gros problème qu'il faudrait éviter. Dans l'excitation du multiplateforme, il est très facile d'arrêter accidentellement de prêter attention à la prévention de ce gros problème.

Et si le sujet multiplateforme signifiait que nous étions tous obligés de choisir entre l'un des résultats suivants ?

1. Une excellente version de WinUI qui ne fonctionne que sous Windows ; ou

2. WinUI de qualité moyenne, peu fiable et/ou lent qui s'exécute sur toutes les plates-formes, et qui souffre d'un rythme de développement extrêmement lent avec de nombreux problèmes en suspens qui ne sont pas résolus pendant 5 à 10 ans.

@verelpode Tout d'abord, vous exagérez beaucoup ici. Deuxièmement : Microsoft dispose de vastes ressources. Cela ne devrait pas être un problème du tout de financer à la fois des améliorations natives de WinUI et une solution multiplateforme, si Microsoft est vraiment intéressé par la fourniture d'un framework multiplateforme. En fait, ils le font en ce moment : ils développent et améliorent WinUI, et en même temps, ils développent et améliorent Xamarin. Ils ont beaucoup de projets en cours en même temps. Donc, si Microsoft s'engage vraiment à fournir à la fois un excellent framework d'interface utilisateur Windows (ce qu'ils sont certainement) et un framework multiplateforme (ce qui aurait beaucoup de sens avec Surface Neo et Duo à l'horizon), alors nous n'avons pas choisir. Les deux peuvent être réalisés sans compromis. (Et généralement, ce n'est pas comme si c'était quelque chose que nous pouvions choisir. Microsoft prendra ses décisions et nous verrons quel est le résultat.)

Ainsi, le financement d'un framework multiplateforme ne signifie pas du tout que le développement et la stabilité de WinUI devraient en souffrir. Si la stratégie Uno a été choisie, Uno est complètement indépendant de WinUI, car il se trouve au-dessus. WinUI peut encore évoluer et Uno essaie de récupérer de nouveaux contrôles et concepts WinUI (probablement à un rythme plus lent). De plus, si une approche de rendu a été choisie, cela ne signifie pas qu'elle retardera WinUI sous Windows. Il se peut qu'une nouvelle version de WinUI soit publiée, mais il n'y a pas encore de moteur de rendu Android. Ensuite, le développement multiplateforme utiliserait l'ancienne version de WinUI, jusqu'à ce que le moteur de rendu Android soit mis à jour vers WinUI vLatest. Les développeurs Windows peuvent utiliser WinUI vLatest dès le début. Si les ressources sont là, les deux peuvent être développés au même rythme.

@lukasf

Microsoft dispose de vastes ressources.

C'est vrai, c'est vrai, mais il existe un autre aspect qui est également vrai : de nombreux chefs de projet ont appris à leurs dépens qu'investir plus d'argent, de personnel et de ressources dans un projet n'est pas nécessairement synonyme de succès.

Microsoft dispose de vastes ressources.

C'est vrai, c'est vrai, mais il existe un autre aspect qui est également vrai : de nombreux chefs de projet ont appris à leurs dépens qu'investir plus d'argent, de personnel et de ressources dans un projet n'est pas nécessairement synonyme de succès.

Ensuite, le problème peut être ces chefs de projet et la structure organisationnelle ;)

Peut-être que Microsoft devrait acheter Uno et les financer correctement, afin qu'ils puissent résoudre tous ces problèmes ouverts et ajouter plus de support de contrôle.

Je sais que nventive courtise Microsoft depuis plusieurs mois (une acquisition de Microsoft est probablement leur stratégie de sortie). Lors de la conférence Uno, il y avait également une large participation de Microsoft. Même Xamarin utilise maintenant Uno pour prendre en charge le Web.

Je sais que nous pouvons débattre des options (1) des rendus natifs ou (2) d'une autre implémentation/couche d'interface utilisateur sans fin, mais en regardant ce qui est disponible maintenant et ce dont nous avons besoin pour surface Duo, Uno est en fait la seule solution qui a du sens. Comme @lukasf l' a dit, Microsoft devrait y consacrer ses ressources et voir jusqu'où ils peuvent aller en un an. S'il réussit (fonctionnalité complète, stable), je ne pense pas que les développeurs se soucieront vraiment de la façon dont il est mis en œuvre dans les coulisses. S'il devient évident que la bonne approche est WinUI rendue nativement pour chaque plate-forme, cela peut faire l'objet d'une discussion pendant quelques années. Pour le moment, il vaut mieux commencer avec une plate-forme Uno complète à 25% que rien du tout.

@stevenbrix ici :

@lukasf Je pense que le "plus petit dénominateur commun" qui existe actuellement dans Uno est un problème de limitation des ressources, et non pas dû à la superposition. J'aimerais avoir tort, mais je pense que ce problème pourrait être résolu et ne pas empirer à l'avenir.

Vous vous trompez.
Uno ne suit pas ce mantra du « plus petit dénominateur commun » de Xamarin, mais au contraire, il essaie plutôt de s'assurer que tous les contrôles XAML (et même Windows Community Toolkit !), fonctionnent sur toutes les plateformes.

Uno ne suit pas ce mantra du « plus petit dénominateur commun » de Xamarin, mais au contraire, il essaie plutôt de s'assurer que tous les contrôles XAML (et même Windows Community Toolkit !), fonctionnent sur toutes les plateformes.

@weitzhandler tu as tout à fait raison ! Je pense que leur architecture se prêtera un jour à une parité complète avec le jeu de contrôles WinUI, ce qui n'est peut-être pas possible avec Xamarin.Forms. Si je comprends bien, cet ensemble de contrôles n'a tout simplement pas encore été construit, c'est ce à quoi @lukasf et moi faisions référence. Je peux me tromper cependant, je n'ai pas assez joué pour le savoir, je fais juste confiance à ce que j'ai entendu de tout le monde :)

L'approche de @weitzhandler Uno consistant à réimplémenter les véritables API UWP/WinUI est bien meilleure que l'invention par Xamarin d'un nouveau dialecte XAML. Mais si vous exécutez la galerie de contrôles Uno Xaml, vous trouverez pas mal de zones vides. Leur jeu de contrôles est certainement meilleur que Xamarin.Forms, mais il ne s'agit pas encore d'un UWP/WinUI complet. Je pense qu'Uno a besoin de plus de travail sur la surface de l'API, ainsi que de plus de travail pour que les commandes disponibles soient vraiment stables et complètes.

Je pouvais voir Uno comme une option viable. Mais il faut de réels progrès, c'est là que Microsoft pourrait entrer en jeu.

Dans un autre point, je suis tout à fait d'accord avec ce que @lukasf a dit ici :

Les excellentes applications ont leur propre look+feeling. Ils n'ont pas besoin de contrôles de plate-forme de stock. Regardez Spotify, Netflix

Je pense également qu'idéalement, la solution consiste à faire en sorte que la conception WinUI + Fluent soit la même sur toutes les plates-formes, et peut-être fournir des thèmes d'apparence et de convivialité natifs pour ceux qui ont besoin de la conception de stock, à appliquer sur les plates-formes spécifiques.
Je pense que le Web devrait être le même que le bureau, donc seuls Droid et iOS sont candidats pour cela de toute façon.

Les contrôles multiplateformes sont en fait indépendants des frameworks multiplateformes.

Hypothèse : à l'avenir, les contrôles .Net ne seront pas limités à des plateformes particulières.

Il existe des frameworks multiplateformes .Net UI (Xamarin.Forms, Avalonia). Il y aura aussi FutureXplatDotNetUI dont tout le monde rêve et que personne ne peut vraiment définir.

Lorsque vous créez un contrôle, vous pouvez lui faire utiliser des fonctionnalités spécifiques à la plate-forme. Par exemple, un lecteur vidéo utilisant des lecteurs natifs sur chaque plate-forme. Ou vous pouvez le faire d'une manière indépendante de la plate-forme, par exemple en utilisant SkiaSharp.

Dans tous les cas, votre contrôle peut être installé dans n'importe quel projet d'interface utilisateur .Net.

Corollaire : FutureXplatDotNetUI n'aura besoin que d'un ensemble minimal de contrôles

Il devra définir une classe View et une infrastructure de mise en page, mais des vues ou des groupes de vues spécifiques peuvent être ajoutés en installant des packages d'interface utilisateur .Net standard à partir de nuget.

(Ce message est un commentaire sur l'interface utilisateur .Net multiplateforme et n'est donc pas lié à WinUI.)

J'ai l'impression que la priorité actuelle de l'équipe WinUI n'est pas pour les "nouvelles applications Windows natives". Au lieu de cela, ils se concentrent davantage sur la modernisation des applications existantes et font de WinUI le support sous-jacent d'un cadre d'interface utilisateur de niveau supérieur...

@reli-msft
J'ai l'impression que l'équipe WinUI a déjà renoncé à s'attendre à ce que les gens écrivent de nouvelles applications Windows natives, et WinUI est conçu pour mettre à niveau les applications existantes

Venant d'une personne qui travaille chez Microsoft, c'est un peu bizarre.

J'ai l'impression que l'équipe WinUI a déjà renoncé à s'attendre à ce que les gens écrivent de nouvelles applications Windows natives, et WinUI est conçu pour mettre à niveau les applications existantes

Venant d'une personne qui travaille chez Microsoft, c'est un peu bizarre.

@weitzhandler
Je devrais utiliser un mot plus précis... Ce n'est pas "abandonner" mais "se moquer de". Quoi qu'il en soit, ce n'est qu'une impression de quelqu'un en dehors de l'équipe WinUI.
Mais, la modernisation des applications existantes peut être plus importante _pour l'instant_, et c'est peut-être la raison pour laquelle WinUI a décidé de prendre en charge Win32.

Vous parliez de ce que pense l'équipe WinUI.

En tant que MS général, malheureusement, cela a du sens.
J'aurais aimé que Microsoft ait donné à WinUI l'amour que React ou Electron ou toute autre technologie HTML CSS et JS obtient (lisez mon commentaire ci- dessus ).

@charlesroddie

Vous avez toujours besoin d'un cadre pour développer vos contrôles. Vous avez besoin de classes de base à hériter, d'interfaces à implémenter. Vous avez besoin de classes pour accéder aux arbres de contrôle, aux modèles, etc. Vous ne pouvez donc vraiment pas séparer les contrôles des frameworks. Aucun contrôle ne peut fonctionner dans plusieurs frameworks, à moins que ces frameworks n'utilisent exactement les mêmes concepts, classes et espaces de noms.

Vous pouvez partager du code entre les contrôles WinUI (basés sur C#) et WPF, mais ce serait toujours difficile en raison des différents espaces de noms et des différentes API. Mais il est tout simplement impossible de partager des contrôles XAML avec des frameworks Android ou iOS.

En plus de cela, je ne suis vraiment pas sûr que .NET soit la bonne technologie pour créer une pile d'interface utilisateur. Microsoft l'a essayé avec WPF, puis a finalement abandonné et est passé à C++. Avoir des pauses GC pendant la mise en page et le rendu ne fait tout simplement pas la meilleure impression pour les utilisateurs finaux, à une époque où les animations deviennent de plus en plus importantes. Peut-être que ce n'est plus vrai si un compositeur est disponible, qui prend en charge des animations fluides complètement indépendamment du fil d'interface utilisateur. Ensuite, la pile de contrôle pourrait être C# et seule la partie de rendu et d'animation de niveau le plus bas serait du code natif. Mais à l'époque, les performances étaient la principale raison pour laquelle C# a été complètement abandonné dans les frameworks d'interface utilisateur XAML suivants (Silverlight et UWP/WinUI).

@lukasf Aucun contrôle ne peut fonctionner dans plusieurs frameworks

Ce n'est pas vrai. J'ai donné deux façons dont les contrôles peuvent fonctionner dans plusieurs frameworks. La première approche consiste à écrire du code spécifique à la plate-forme. Ensuite, vous devez connaître les frameworks que vous prenez en charge pour connecter votre code spécifique à la plate-forme à chaque framework ; vous pouvez le faire dès maintenant, mais l'échafaudage peut être rendu plus facile à l'avenir. La deuxième approche (rendu indépendant de la plate-forme) est très simple et se fait en ce moment. Par exemple, CSharpMath.SkiaSharp peut être utilisé sur toutes les plates-formes d'interface utilisateur .Net.

@charlesroddie D'accord, peut-être que je me suis trompé dans votre message. Mais alors le contrôle n'est pas vraiment indépendant du framework. Il ne peut être installé que dans les applications dont le cadre est explicitement pris en charge par le contrôle. Et le rendu n'est qu'une petite partie d'un contrôle. La logique de contrôle, la liaison de données et la gestion des entrées doivent être implémentées pour chaque framework pris en charge, dans chacun de ces contrôles, même si vous utilisez un moteur de rendu indépendant de la plate-forme. Cela ne me semble pas très efficace, à moins que les frameworks pris en charge ne soient très similaires. Comme je l'ai dit, il est possible de partager du code entre WPF, Silverlight et UWP. Mais au-delà, ça devient vraiment difficile, et je doute que je verrai un jour un tel contrôle.

Un framework multiplateforme vous permet généralement d'écrire toute la logique de contrôle, la gestion des données et des entrées (et parfois même le rendu) une seule fois pour une API, puis il mappera automatiquement cela sur chaque framework. Ainsi, une fois le cadre en place, la mise en œuvre du contrôle est beaucoup plus efficace.

Il ne peut être installé que dans les applications dont le cadre est explicitement pris en charge par le contrôle.

C'est vrai, mais la prise en charge de plus de plates-formes est/peut être facilitée.

La logique de contrôle, la liaison de données et la gestion des entrées doivent être implémentées pour chaque framework pris en charge.

La liaison de données n'a pas besoin d'être implémentée par un cadre d'interface utilisateur. Il s'agit d'une idée fausse favorisée par les approches .Net populaires mais inférieures qui prévalent. Les contrôles doivent uniquement spécifier des constructeurs et des propriétés. Ils n'ont pas besoin de spécifier une manière particulière de lier les données car une fois que les propriétés gettable/settable sont spécifiées, les consommateurs peuvent utiliser n'importe quel framework d'approche pour déplacer les données qu'ils souhaitent. (Et presque toutes les approches/cadres sont meilleurs que la liaison de données WPF/UWP/Xamarin.)

La logique de contrôle est naturellement implémentée dans .Net d'une manière indépendante de la plate-forme, ce qui est parfaitement pris en compte dans les deux approches que j'ai données.

La gestion des entrées bénéficie d'un "cadre multiplateforme", mais il peut s'agir d'un très petit cadre de contrôle, qui peut être référencé à la fois dans des projets spécifiques à la plate-forme et multiplateformes, avec une très petite API qui définit simplement la souris/le toucher et la saisie au clavier. Le projet de contrôles SkiaSharp.Extended va dans ce sens.

Si vous souhaitez que la liaison de données fonctionne dans WPF ou WinUI, vous devez déclarer DependencyProperties. Je doute fortement que quiconque utilise un contrôle XAML qui ne fonctionne pas avec la liaison de données. La liaison de données est au cœur de ces frameworks, et cela nécessite que DependencyProperties fonctionne, si vous les aimez ou non. Si vous ne les ajoutez pas, vous ne pouvez utiliser votre contrôle dans aucun des frameworks de plate-forme Windows actuels.

Avec la "logique de contrôle", je pense davantage à l'interaction avec d'autres contrôles, comme la définition ou la création de sous-contrôles pour votre contrôle de niveau supérieur, la gestion des données et des statuts entre ces contrôles, la disposition, la synchronisation avec les sous-contrôles. Tout cela est un travail spécifique au cadre. Cela, combiné au code de liaison de données (si requis par le cadre cible) et à la gestion des entrées, représente probablement plus de 90 % du code de contrôle. La partie commune entre différentes implémentations de framework pour un tel contrôle est probablement si petite que cela n'a tout simplement pas de sens pour moi de travailler de cette façon.

Je ne dis pas que cela ne peut pas être fait. Mais ce sera très compliqué, tant les frameworks sont très différents. Je veux dire, il est possible d'écrire un tel contrôle maintenant, mais je n'en ai jamais vu. Et personnellement, je ne pense pas que cela deviendra une approche même légèrement populaire.

vous ne pouvez pas utiliser votre contrôle dans l'un des frameworks de plate-forme Windows actuels

Ce n'est pas vrai. Un contrôle qui n'implémente pas DependencyProperties peut être utilisé dans WPF/WinUI. C'est l'un des défauts de la liaison de données .Net traditionnelle : elle encourage l'ajout de DependencyProperties parasites aux contrôles qui définissent déjà des propriétés réglables. Duplication de code énorme. (Au fait, un contrôle multiplateforme ne serait pas un « contrôle XAML » et vous ne devriez pas être dupe de l'utilisation abusive de « XAML » dans le langage marketing de WinUI. Xaml est un langage de balisage facultatif qui peut être utilisé avec plusieurs Frameworks d'interface utilisateur .Net.)

sous-contrôles pour votre contrôle de niveau supérieur

Oui, un contrôle devra spécifier des sous-contrôles, donc pour que les contrôles de niveau supérieur soient disponibles sur plusieurs plates-formes, les contrôles de niveau inférieur le seront également. Si les contrôles de niveau inférieur sont disponibles sur plusieurs plates-formes, leur intégration est facile. Vous imaginez écrire des contrôles de niveau supérieur avant ceux de niveau inférieur, ce qui n'est pas une approche efficace.

La bonne nouvelle est que Microsoft a déjà décidé de tuer le natif .net.

@robloo J'aurai une fête pour le célébrer quand cela arrivera.

Même si Uno dispose d'une conception et d'une mise en œuvre techniques solides et fiables, le risque et l'inquiétude sont qu'Uno disparaisse dans quelques années en raison d'un problème similaire à 0 $ ou d'un revenu insuffisant qui finira par déclencher un épuisement professionnel et l'annulation ou la stagnation du projet. Ou tout simplement le développeur le plus important d'Uno un jour, obtenant soudainement un nouveau passe-temps/intérêt/obsession et perdant tout intérêt pour Uno, ou un nouvel emploi/employeur et plus de temps pour travailler sur Uno.

@verelpode
Je partage la même préoccupation probablement plus que la plupart des autres. J'utilise beaucoup moins de packages open source non soutenus par de grandes entreprises (par exemple Oracle, Google, Microsoft) que la moyenne. Je pense que les deux conditions suivantes doivent être remplies pour que cela se produise :

1. Nventive ferme son entreprise. Nventive s'appuie sur Uno pour son activité de pain et de beurre.
2. Les personnes principales derrière Uno perdent leur intérêt pour ce merveilleux projet.

En ce qui concerne le numéro 1, j'ai entendu dire que Nventive agrandissait son bâtiment actuel et déménageait dans une installation plus grande, de sorte que la Uno Conf 2020 élargie (2 jours à 3 jours) aura une partie dans un bâtiment différent. Je ne suis pas économiste, je ne peux donc pas prédire si une grave récession entraînera la faillite de nombreuses entreprises. Au moins, je ne vois pas d'effondrement économique dans un avenir proche en ce moment (le taux de chômage dans notre région est inférieur à 2 % depuis un certain temps).

Quant au #2, je vois rarement le type de passion que les gars de Uno primaires ont pour leur projet. C'est presque comme une noble cause, pas un simple produit logiciel pour eux. Eh bien, seul un imbécile ne change pas d'avis, donc je ne dirais pas que la probabilité de leur perte d'intérêt est nulle, mais probablement pas loin de zéro. Pour être honnête avec vous, c'est la principale raison pour laquelle j'apprécie et m'en tiens à Uno en ce moment. Comme toute autre plate-forme, Uno a de nombreux problèmes (BTW, manquer certaines fonctionnalités intéressantes n'est pas un problème pour moi.), mais ils résolvent rapidement les problèmes critiques. Je pense qu'ils ont une demi-douzaine de sorties ou plus chaque jour. Une de mes applications n'a pas pu être publiée en raison d'un bogue connu d'une plate-forme, et il a littéralement fallu plus de six mois à une grande entreprise (😉) pour la corriger (j'ai archivé le ticket).

Sur la base de ma vaste expérience avec Sliverlight, Windows Phone 7/7.1/8/8.1 SDK, Windows 8/8.1/10 (WinRT, UWP…) (Mon téléphone principal était un Windows Phone, la meilleure plate-forme mobile de l'histoire de l'humanité, jusqu'à ce que le dernière minute avant de n'avoir d'autre choix que de passer à Android cette année), j'ai plus confiance en la longévité de la plate-forme Uno que des choses similaires de Microsoft. Oui, Uno est basé sur toutes les technologies Microsoft, mais ils s'occupent de la migration lorsque Microsoft change les choses sous le capot.

Je me demandais si une raison pour laquelle Miguel approuve Uno et a prononcé le discours d'ouverture à Uno Conf est qu'il voit Uno comme son bébé Mono au début, et Nventive comme son Ximian.

Je me prépare au pire des scénarios – le décès d'Uno. Étant donné que tous les projets Uno utilisent mes deux technologies préférées - C# et Xaml, je peux facilement les migrer vers n'importe quelle plate-forme émergente basée sur eux. Au moins, je peux dire que le code C# vieillit très bien. Une grande partie du code de ma bibliothèque d'utilitaires de base partagée par tous les projets a bien plus de dix ans. Ils fonctionnent toujours parfaitement, et je pense qu'ils fonctionneront dans les décennies à venir.

@stevenbrix @weitzhandler @Pinox

Une discussion intéressante a également remarqué que Blazor Native était également mentionné ici.

Il y a eu une nouvelle conf NDC de Steve avec Blazor qui pourrait être intéressante à considérer, la vidéo ci-dessus utilisant Blazor + Native utilisait Flutter comme moteur de rendu. Mais dans une nouvelle vidéo NDC Conf , Steve utilise désormais Xamarin.Forms pour afficher l'interface utilisateur mobile avec un balisage de type XAML. Je pourrais voir Blazor Native comme la solution de plate-forme X la plus pratique qui puisse fonctionner actuellement avec WinUI car elle prendra en charge React Native de la même manière que je pouvais la voir prendre en charge Blazor Native de cette façon. Ainsi .Net peut désormais cibler (Web, Mobile, Win Desktop).

METTRE À JOUR:
Une nouvelle version de MS Teams a été publiée récemment, et elle améliore le temps nécessaire pour afficher le message de discussion le plus récent. Dans un message précédent, j'ai mentionné que cela prenait environ 27 secondes, mais heureusement, la nouvelle version affiche plus rapidement le message de discussion le plus récent.

Merci aux membres du personnel de Microsoft qui ont travaillé sur cette amélioration. :le sourire:

Ma perseption:

Microsoft : peut développer un minimum de Webview2 (similaire à Carlo) qui peut désactiver presque toutes les fonctionnalités et réduire à une seule liaison d'événement à l'interface utilisateur HTML... bibliothèque principale native).
Je savais à quel point le côté HTML/CSS était complexe, mais j'aimerais tirer parti de cette connaissance de l'interface utilisateur et de la liaison un à un sur le code C# derrière le code d'événement, etc.

Microsoft : Peut éteindre une RAM de 8/32 Go de ceux qui avaient 4x 8 Go/ 4x 32 Go... Économisant beaucoup d'énergie.

Pour ce faire, nous nous débarrassons de dizaines d'applications développées avec Electron... qui dépendent de l'objectif de Microsoft et Bill Gates.

Bien que le meilleur objectif soit que tout le monde commence à développer une application et à tirer parti d'un framework GUI standard CSS3... possible comme QT/GTK... mais dommage que GTK ne soit pas non-copyleft, et possible comme QML avec équivalence .net.

METTRE À JOUR:
Annulez ce que j'ai dit dans mon message précédent à propos du problème en cours de résolution ☹️ Ce n'est pas résolu. C'est bizarre : pendant quelques semaines, il semblait que le problème avait disparu, mais le problème est revenu récemment ! MS Teams me donne à nouveau des difficultés et des retards lorsque j'essaie simplement d'afficher le message de discussion le plus récent.

Le bug de MS Teams n'est pas surprenant si l'on considère qu'il est écrit en JavaScript. _Bien sûr_ une application écrite en JavaScript est boguée - pourquoi s'attendre à autre chose ? MS Teams utilise ElectronJS qui utilise JavaScript malgré le fait qu'il est bien connu que JavaScript n'a jamais été conçu pour être un véritable langage de programmation, il s'agit plutôt d'un simple module complémentaire de script pour les navigateurs Web.

JavaScript n'inclut même pas la vérification du type à la compilation -- c'est à quel point c'est mauvais. D'où la nécessité pour TypeScript d'essayer de corriger ce problème _majeur_ en JavaScript. En fait, c'est un très mauvais problème si vous considérez JavaScript comme un langage de programmation -- JavaScript est terrible en tant que langage de programmation -- mais comme je l'ai dit, il était censé être un langage de script occasionnel, pas un langage de programmation, donc vous pouvez pardonnez à JavaScript de ne pas avoir inclus l'essentiel d'un langage de programmation, car la programmation d'applications n'était pas le but de JavaScript.

Ce qui n'est pas vraiment pardonnable, c'est la décision incompréhensible d'utiliser un langage de script occasionnel comme s'il s'agissait d'un langage de programmation. J'ai été vraiment surpris de voir que Microsoft a choisi un langage non professionnel pour une application aussi importante que Teams. Je ne pensais pas qu'il était possible pour quiconque de prononcer le nom "JavaScript" tout en oubliant que "JavaScript" a "Script" dans son nom car il s'agit bien d'un langage de script et non d'un langage de programmation. D'une manière ou d'une autre, l'existence du mot "Script" dans "JavaScript" vient d'être complètement estompée.

Les membres de l'équipe WinUI ont travaillé dur sur de nombreuses améliorations de WinUI. La décision de Microsoft d'utiliser un langage de script occasionnel au lieu de WinUI n'a aucun sens.

Il existe de nombreuses applications Web JavaScript très bien écrites et très performantes. Bien sûr, vous pourriez obtenir des performances encore meilleures avec d'autres technologies. Mais la raison pour laquelle Teams est lent pour vous n'est sûrement pas le fait qu'il soit basé sur JavaScript. Cela est dû à une mauvaise implémentation côté serveur ou côté client (probablement des problèmes d'async/threading). Il serait sûrement possible d'écrire des équipes en JavaScript avec de bien meilleures performances.

Ne vous méprenez pas, je ne suis pas du tout un fan de JavaScript. En fait, je pense que c'est une langue horrible. Je dis simplement que les problèmes que vous voyez ne sont pas dus au fait que Teams utilise la technologie JavaScript. Il est même possible d'exécuter le moteur Unreal en JavaScript avec de bonnes performances (pas de premier ordre).

WinUI est un framework de bureau Windows uniquement. Il n'a donc pas été possible de développer l'application Teams de la plate-forme x sur cette base, et même aujourd'hui, ce n'est pas possible. Mais peut-être que les problèmes avec Teams aideront Microsoft à envisager de rendre WinUI multiplateforme. Avec une véritable plate-forme X WinUI et .NET Core, il serait beaucoup plus facile de développer des applications réactives qui s'adaptent bien.

WinUI est un framework de bureau Windows uniquement. Il n'a donc pas été possible de développer l'application Teams de la plate-forme x sur cette base, et même aujourd'hui, ce n'est pas possible. Mais peut-être que les problèmes avec Teams aideront Microsoft à envisager de rendre WinUI multiplateforme. Avec une véritable plate-forme X WinUI et .NET Core, il serait beaucoup plus facile de développer des applications réactives qui s'adaptent bien.

En utilisant Uno, WinUI est multiplateforme. Regardez la calculatrice UNO dans le Google Play Store. Il s'agit d'une version portée de la calculatrice Windows 10.

Quelqu'un demandait une comparaison UWP vs Electron, en voici quelques-uns :

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

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

la nouvelle application XBOX c'est ridicule, peut prendre facilement 1.5go de RAM pour rien

Ce serait bien si quelqu'un pouvait faire une vidéo pour montrer à quel point ils sont plus lents par rapport à UWP

Je pensais que la plupart des participants à cette discussion concernant WinUI & X-platform ont lu cette histoire, mais juste au cas où certains l'auraient manqué, voici WinUI sur Windows 7 - Oui, c'est possible avec Uno Platform . Une fois qu'une application est basée sur Uno, elle cible Windows, Web, iOS et Android.

@lukasf

Il serait sûrement possible d'écrire des équipes en JavaScript avec de bien meilleures performances.

Oui c'est _possible_, et c'est aussi _possible_ d'écrire MS Teams en PowerShell avec des performances acceptables (j'aime bien PowerShell), et c'est aussi _possible_ que SpaceX déménage en Russie et réussisse toujours à lancer des satellites, mais ce serait toujours une gestion incompétente décision de déplacer SpaceX en Russie ou d'écrire l'application MS Teams dans un langage de script tel que PowerShell ou JavaScript. Si SpaceX déménageait en Russie, alors oui SpaceX pourrait toujours fonctionner, c'est possible, mais honnêtement, nous devrions dire qu'Elon Musk ne serait pas vraiment un gestionnaire efficace et ne saurait vraiment ce qu'il faisait.

Je ne suis pas convaincu à 100% qu'Electron soit à blâmer. On dit que Visual Studio Code est également basé sur l'Electron, mais ses performances sont assez solides. Les applications Electron sont essentiellement des applications Web, et il existe des milliers de raisons derrière une application Web mal exécutée.

Il n'y a pas grand-chose que WinUI puisse faire pour "gagner des équipes". Ce n'est pas la technologie, c'est le produit. Teams est comme une start-up qui s'est lancée sur la voie d'une croissance rapide. Il doit fonctionner sur plusieurs plates-formes avec la parité des fonctionnalités, et elles doivent y parvenir le plus rapidement possible. C'est la seule raison de choisir la technologie Web. Sur mobile, ils peuvent utiliser React Native car c'est le seul moyen d'accéder au matériel avec JavaScript, mais sur Desktop, ils doivent maintenir la parité des fonctionnalités et la maintenabilité du code avec l'application Web, le mac et la version Linux. Ils doivent utiliser un framework qui cible win32 car ils ne peuvent pas attendre que le modèle d'application UWP ajoute les fonctionnalités dont il a besoin. Pouvoir partager le bureau avec la possibilité de choisir quel bureau ou quelle application spécifique partager est l'une de ses fonctionnalités clés. C'est ainsi que sont développés les produits de type startup. Slack a utilisé jquery pour pirater la croissance au début et s'est retrouvé avec un très mauvais code, mais une fois qu'ils ont eu le temps de refactoriser, ils ont rapidement tout réécrit avec react, et Slack est maintenant beaucoup plus rapide qu'avant. WinUI et Electron ne sont pas dans la même catégorie, et pour cette raison, il ne remplacera pas Electron pour les applications qui en ont vraiment besoin, quelle que soit la fonctionnalité qu'il ajoute.