Sélectionner une page


nouvelles

Lander de Microsoft sur Blazor Desktop: « Je ne verrai plus de modèle d’application Grand Unified à l’avenir »

Avec tous les discours sur l’unification de l’écosystème diversifié des outils de développement centrés sur Microsoft – en utilisant un cadre pour les applications de toutes sortes sur toutes les plates-formes – Blazor Desktop n’est pas la réponse.

C’est le Ambassade par Richard Lander, responsable de programme pour l’équipe .NET, dans des commentaires récents aux développeurs qui ont posé des questions sur la version récente de .NET 6 Preview 1, un framework de parapluie unifié pour tout ce qui concerne .NET.

L’aperçu Présentation de Blazor DesktopEncore dans les premiers stades d’un projet de référence Blazor – qui est utilisé pour le développement Web C # au lieu de JavaScript – vers le développement de bureau.

Une attraction puissante et attrayante de Blazor Desktop est la capacité d’améliorer les performances et la productivité de C # /. NET avec la familiarité du rendu des interfaces utilisateur HTML / CSS. selon à l’homme qui a inventé Blazor, Steve Sanderson. Il a dirigé les efforts pour remplacer la fonctionnalité de rendu de Blazor, qui utilise WebAssembly côté client pour le développement Web, pour d’autres objectifs tels que l’expérience. Fixations Blazor Mobile Projet. Il a également créé quelque chose appelé WebWindow, décrite comme une bibliothèque de vues Web multiplateforme pour .NET Core qui est similaire à Electron, mais qui ne regroupe pas Node.js ou Chromium avec moins d’API.


Une application de bureau Blazor
[Click on image for larger view.] Une application de bureau Blazor (Source: Microsoft).

Le .NET 6 Preview 1 a introduit l’idée de Blazor Desktop et complètera les efforts d’unification .NET commencés avec .NET 5 et incorporera la technologie Xamarin en tant qu’offre nouvellement développée appelée .NET Multi-Platform App UI (MAUI) in record le mélange. «Nous étendons également les capacités de Blazor avec un nouveau type d’application client hybride qui combine des interfaces utilisateur Web et natives et peut être utilisé pour des scénarios de bureau et mobiles», a déclaré Lander.

Cela a suscité un grand intérêt dans la communauté des développeurs et alimenté la discussion sur un cadre très attendu à un modèle pour tout qui peut être utilisé pour le cloud, le mobile, le bureau et d’autres applications sous Windows, macOS et Linux.

Après avoir constaté une confusion potentielle à propos de Blazor Desktop, Lander a ajouté une mise à jour à son message, dont une partie se lit maintenant:

Mise à jour: je fournirai plus de contexte en fonction de plusieurs questions que j’ai reçues. Blazor est un modèle de programmation d’application. C’est très personnalisable et peut être fait de différentes manières (en fonction de vos besoins). Le bureau Blazor sera construit de la même manière que Electron. Il y aura un contrôle WebView qui restitue le contenu d’un serveur Web Blazor intégré pouvant servir Blazor ainsi que d’autres contenus Web (JavaScript, CSS, …). Le bureau Blazor n’utilise pas de Blazor, du moins dans sa configuration standard WebAssembly. En bref, il n’y a aucune raison technique évidente ou raison pour laquelle l’expérience utilisateur utilise WebAssembly pour une application de bureau. Certaines personnes ont trouvé que Blazor WebAssembly était trop lent. D’une part, c’est vrai. Cependant, les gens doivent se rendre compte que nous y travaillons Performances de Blazor WebAssembly.

Le bureau Blazor offre un large éventail de choix lors de la création de votre application. À une extrémité du spectre des applications, vous pouvez utiliser Blazor et les technologies Web pour tous les aspects de l’expérience de l’application cliente, à l’exception du conteneur d’application natif le plus externe (comme la barre de titre). À l’autre bout du spectre, vous pouvez utiliser le bureau Blazor pour des fonctions ciblées dans une application autrement native (comme WPF), telles que: B. une page de profil utilisateur que vous avez déjà implémentée pour votre site Web basé sur Blazor. Toutes les décisions intermédiaires sont également possibles. Nous construisons d’abord Blazor Desktop pour les applications .NET, mais il n’y a aucune raison technique que vous ne puissiez pas l’utiliser dans une application de bureau qui fonctionne avec une autre pile d’applications telle que. B. Swift a été créé.

Le bureau Blazor est basé sur l’interface utilisateur de l’application multiplateforme .NET. Il est basé sur cette pile d’interface utilisateur pour un conteneur d’application natif et des contrôles natifs (au cas où vous voudriez les utiliser). Nous construisons Blazor de manière à ce que les performances de démarrage et de débit soient comparables à celles des autres solutions de bureau. Pour les développeurs qui aiment Blazor et les technologies Web, nous pensons que Blazor est un excellent choix pour créer des applications de bureau.

Mais ce n’est pas la réponse à un message de la communauté des développeurs demandant à Microsoft de « Créer un modèle de développement d’application client .NET omniprésent.  »

Publié il y a quelques années, il dit partiellement: «Ce sondage est destiné aux développeurs qui souhaitent voir l’idée d’un modèle de développement d’application client .NET omniprésent créé par Microsoft et l’équipe de Visual Studio. Un modèle de développement .NET omniprésent. Client applications est un modèle défini dans les technologies basées sur .NET et qui peut s’exécuter dans divers environnements d’exécution – à la fois compilé en mode natif (hébergé dans le magasin) et hébergé sur le Web.  »

Ce problème aurait reçu plus de 11 000 votes avant d’être déplacé vers le nouveau site Web de la communauté des développeurs pour obtenir des commentaires, des demandes de fonctionnalités, etc. Il est toujours marqué comme « en cours de révision » avec 170 votes et 98 commentaires.

Lorsque le premier discours a été que Blazor Desktop pourrait être utilisé pour un tel effort, Lander a publié sa mise à jour et a répondu à plusieurs questions sur l’initiative mal comprise.

Les employés de Microsoft publient souvent de nouvelles informations dans des commentaires sur des publications qui ne figuraient pas dans les publications elles-mêmes. Voici quelques autres bribes de Lander dans une telle discussion, incluses dans 166 commentaires sur son post:

  • Je pense que les gens peuvent manquer la narration sur le bureau Blazor. Il s’agit d’un choix incontournable pour les applications clientes multiplateformes qui permettent l’utilisation de ressources Web. Il n’y a pas beaucoup d’options dans ce domaine et aucune n’est spécifiquement conçue pour les développeurs .NET.
  • Je n’ai pas mentionné Electron dans le post. Electron est un excellent projet et il y a plusieurs mainteneurs Electron dans la division des développeurs (tout comme l’équipe .NET). Le bureau Blazor est une alternative à Electron, et nous le construisons pour qu’il soit différent d’Electron, en particulier pour les développeurs .NET.
  • Nous pensons que Blazor Desktop sera une option convaincante, du moins pour les développeurs qui aiment Blazor et souhaitent proposer des applications de bureau à leurs utilisateurs.
  • Le message contient deux offres d’interface utilisateur multiplateforme. Le premier est le bureau Blazor et il ressemble à un électron. Vous avez capturé cela. J’ai mis à jour la description de ce modèle plus tôt dans la journée pour indiquer clairement que nous n’utiliserons pas de Wasm dans ce scénario. Nous n’avons pas pris de décision finale, mais ce n’est peut-être pas du tout mono. Nous examinons à la fois Mono et CoreCLR pour ce scénario de bureau.
  • [When asked about Sanderson’s aforementioned WebWindow post] Steve Sanderson est membre de l’équipe Blazor Desktop. Je ne peux pas parler de tous les détails, mais ma compréhension de Blazor Desktop est que c’est la production de cet article de blog qui utilise un certain nombre de compromis. Article de blog assez impressionnant, non?
  • Blazor Desktop utilise WebView2 (Chromium) sur Windows et wkwebview (Safari) sur macOS. C’est un compromis majeur entre la différenciation et l’électron.

Lorsqu’on lui a demandé si le projet Blazor Mobile Bindings devait fusionner avec MAUI, Lander a partiellement répondu: « Blazor Desktop et MAUI devraient être séparés. Blazor Desktop est hébergé via une vue Web MAUI. MAUI fournit le conteneur d’application de bureau ou mobile. MAUI permet l’utilisation de contrôles natifs (à côté de pas dans la vue Web) si nécessaire / souhaité.  »

Le même développeur a examiné la première question et a demandé si le modèle de programmation Blazor ou le modèle MAUI (Xamarin) serait utilisé pour unifier le développement natif et Web. « Si MAUI peut mapper HTML aux widgets XAML, il peut potentiellement combiner natif et Web. Est-ce correct? »

Voici la réponse de Lander pour défaire efficacement le rêve chimérique «Ubiquitous .NET Client Application Development Model» (voir le texte en gras):

Nous avons parlé de faire de Blazor un moteur de rendu MAUI natif de haut niveau et de permettre à MAUI de restituer en Blazor / HTML. Le problème est que Blazor et MAUI sont (intentionnellement) des abstractions qui fuient. Si vous avez utilisé Blazor mais que vous ne vous êtes pas appuyé sur JavaScript, le rendu MAUI est simple. D’un autre côté, le rendu dans Blazor serait simple si vous utilisiez MAUI mais ne vous reposiez pas sur des contrôles natifs. Blazor et MAUI offrent tous deux une grande partie de leurs performances car ils fournissent un excellent modèle d’interopérabilité avec le système sous-jacent. À certains égards, il est similaire à l’interaction entre TypeScript et JavaScript. Je ne vois donc pas un excellent modèle d’application unifiée à l’avenir. Le natif et le Web peuvent coexister avec bonheur, mais pas fusionner.

Alors là vous l’avez.

A propos de l’auteur

David Ramel est l’éditeur et écrivain de Converge360.



Source link

Recent Posts