Plongée en profondeur sur Blazor – Visual Studio Magazine

Questions et réponses

Q&A : Plongée en profondeur sur Blazor

Le projet “le plus en vogue” dans l’espace de développement Web centré sur Microsoft est Blazor, qui offre à la fois un composant côté serveur et un composant côté client basé sur la technologie révolutionnaire WebAssembly, se combinant pour fournir une expérience basée sur C # au lieu de JavaScript.

Le framework gratuit et open source a évolué de son orientation Web pour cibler d’autres domaines, y compris le mobile et même le bureau.

Officiellement, Microsoft dit :

Les applications Blazor sont composées de composants d’interface utilisateur Web réutilisables implémentés à l’aide de C#, HTML et CSS. Le code client et serveur est écrit en C #, ce qui vous permet de partager du code et des bibliothèques.

Blazor est une fonctionnalité d’ASP.NET, le framework de développement Web populaire qui étend la plate-forme de développement .NET avec des outils et des bibliothèques pour créer des applications Web.

Avec sa popularité croissante dans le camp de développement Microsoft, il n’est pas surprenant qu’il fasse l’objet d’une présentation approfondie des fonctionnalités lors du prochain Visual Studio Live ! conférence prévue du 13 au 17 juin 2022 à Austin, Texas.

Diriger la plongée profonde est Rockford Lhotka, un architecte de systèmes open source et distribués bien connu, auteur et conférencier. Nous avons rencontré “Rocky” pour une courte séance de questions-réponses afin d’en savoir plus sur sa présentation qui enseignera aux participants :

• Comment Blazor, WebAssembly et .NET se combinent pour activer cette plate-forme d’application
• Comment créer des applications Blazor et Blazor WebAssembly côté serveur
• Comment utiliser les fonctionnalités de l’infrastructure d’interface utilisateur Blazor telles que les composants d’interface utilisateur, la liaison de données, le routage et l’autorisation

Magazine VisualStudio : Depuis ses racines en tant que projet pour animaux de compagnie de Steve Sanderson, Blazor est devenu extrêmement populaire. En plus de permettre aux codeurs C # de participer à l’action de développement Web au lieu de s’appuyer principalement sur le JavaScript traditionnel, qu’est-ce que Blazor propose d’autre pour expliquer cette popularité ?
Hotka : Blazor fournit un certain nombre de fonctionnalités puissantes en plus de permettre aux développeurs C # d’utiliser le langage de leur choix pour le développement Web.

Blazor prend en charge l’exécution de votre code sur le serveur ou sur le client via WebAssembly, et vous pouvez choisir quels utilisateurs ou appareils obtiennent l’une ou l’autre expérience. Par exemple, vous pouvez diriger les utilisateurs avec des appareils plus anciens et moins puissants pour utiliser Blazor côté serveur, et les utilisateurs avec des appareils modernes pour utiliser Blazor WebAssembly.

Blazor comprend également un puissant modèle de composants d’interface utilisateur, basé sur les enseignements des précédents frameworks d’interface utilisateur tels que MVC, Web Forms, Windows Forms, WPF et Xamarin. Le modèle de composant d’interface utilisateur Blazor facilite la création de composants d’interface utilisateur hautement maintenables et réutilisables entourant un seul widget d’interface utilisateur ou des sections entières de fonctionnalités d’application. Couplé aux capacités de liaison de données simples mais extrêmement puissantes prises en charge par Blazor, le résultat est un modèle d’interface utilisateur conçu pour créer des applications au niveau de l’entreprise jusqu’à une simple page Web.

ASP.NET Core MVC dépend également moins de JavaScript que d’autres frameworks alternatifs. Blazor offre-t-il des avantages par rapport à ASP.NET Core MVC, ou s’agit-il d’outils spécifiques pour différents types de travaux ?
ASP.NET Core MVC est un framework Web côté serveur, dont les racines remontent à l’époque qui a précédé ce que nous considérons maintenant comme le Web moderne. Pour certains scénarios d’application, un modèle basé sur un serveur qui pousse HTML, CSS et JavaScript vers le navigateur est toujours très valable. Cela est particulièrement vrai pour les scénarios où l’affichage des données est important et l’interaction de l’utilisateur est d’importance secondaire.

Pour les applications où l’interaction de l’utilisateur est très importante, la plupart des gens préfèrent les frameworks d’interface utilisateur comme Angular, React ou Blazor. Tous ces outils offrent la possibilité de créer des expériences utilisateur riches, bien qu’aucun ne soit aussi efficace pour l’affichage des données brutes que quelque chose comme MVC.

L’avantage de Blazor dans ce cas est que vous pouvez mélanger les fonctionnalités ASP.NET MVC ou Razor Pages avec vos fonctionnalités Blazor dans la même application et en utilisant le même IDE et le même langage de programmation.

Depuis sa concentration initiale sur les applications SPA, Blazor WebAssembly a été pointé vers toutes sortes d’autres cibles, du mobile au bureau même. Y a-t-il une limite à cela ? Pourquoi pas Blazor pour tout ?
WebAssembly lui-même est susceptible d’être une technologie transformatrice pour de nombreux types d’applications, car il s’exécute dans tous les navigateurs modernes et dans un nombre croissant de scénarios côté serveur et IoT, y compris des endroits comme Kubernetes. La possibilité d’écrire du code dans le langage de votre choix, tel que C #, Go, Rust ou bien d’autres – et de compiler ce code sur WebAssembly afin qu’il puisse s’exécuter dans de nombreux environnements – est extrêmement convaincante.

Blazor WebAssembly lui-même est un framework d’interface utilisateur axé sur l’exploitation de HTML et CSS, ainsi que de votre code C # (au lieu de TypeScript ou JavaScript) pour créer des applications basées sur un navigateur. Comme pour les autres technologies SPA, Blazor bénéficie grandement de l’expansion des scénarios hybrides basés sur un navigateur pour l’hébergement sur des applications mobiles et de bureau, ainsi que directement dans une expérience de navigateur.

Ce que tous ces éléments ont en commun, c’est que le bac à sable du navigateur reste en place. C’est bien, car cela signifie que les applications Blazor WebAssembly peuvent être exécutées dans votre navigateur ou en tant qu’application mobile ou de bureau avec la même sécurité et la même confiance que vous avez avec les applications écrites dans d’autres outils qui ciblent le navigateur, tels que Angular ou React.

D’un autre côté, il est souvent plus rentable de créer des applications mobiles très haute fidélité en utilisant davantage de technologies natives que les technologies basées sur un navigateur. Si vous créez une application mobile ou de bureau destinée aux consommateurs qui est un point de contact principal pour votre marque, il est évidemment essentiel que vos utilisateurs obtiennent la meilleure expérience possible, ce qui conduit la plupart des organisations à créer des applications iOS et Android natives, ou peut-être à utiliser un outil multiplateforme comme Xamarin/MAUI ou Flutter.

Les organisations combinent-elles généralement les fonctionnalités Blazor Server et Blazor WebAssembly dans leur développement, ou avez-vous trouvé l’une ou l’autre plus importante ?
D’après mes observations, de nombreuses organisations utilisent Blazor côté serveur, étant entendu que si elles ont besoin de l’évolutivité fournie par Blazor WebAssembly, elles peuvent adopter ce modèle à l’avenir. Un peu moins d’organisations créent des applications Blazor WebAssembly dès le départ, et une minorité crée leurs applications pour basculer dynamiquement entre les deux modèles au moment de l’exécution.

Qu’en est-il des performances ? Comment Blazor se compare-t-il aux frameworks alternatifs comme React et autres ?
Lorsque l’on parle des performances de Blazor, il est nécessaire de séparer Blazor côté serveur de Blazor WebAssembly.

Blazor côté serveur est extrêmement performant, avec des performances largement basées sur la vérification que votre serveur Web est suffisant pour la charge de travail. L’architecture logicielle derrière Blazor côté serveur est extrêmement similaire aux modèles éprouvés utilisés par les terminaux VT ou 3270 d’autrefois, mais avec des vitesses Internet et du matériel de serveur modernes.

Blazor WebAssembly, ou toute interface utilisateur basée sur WebAssembly, peut être plus lent que les frameworks d’interface utilisateur JavaScript tels que React. En effet, WebAssembly ne permet pas encore au code natif d’interagir directement avec le DOM HTML. L’interaction avec les éléments de l’interface utilisateur doit donc passer par un shim JavaScript. Le code de calcul pur a tendance à être plus rapide dans WebAssembly que dans JavaScript, mais les interactions de l’interface utilisateur sont plus lentes.

Vous devez tempérer cela en comprenant que, lorsqu’ils sont utilisés correctement, tous ces frameworks d’interface utilisateur SPA, y compris Blazor WebAssembly, peuvent créer des expériences utilisateur de premier ordre et très satisfaisantes à utiliser.

Quelles innovations voyez-vous venir pour Blazor et sa technologie côté client, WebAssembly ?


J’ai hâte que WebAssembly adopte le multi-threading et ait la possibilité pour le code wasm natif d’interagir directement avec le DOM HTML. Je suis également extrêmement enthousiasmé par la façon dont WebAssembly se répand au-delà du navigateur, avec le potentiel de devenir un langage d’assemblage commun pour le client, les serveurs, les appareils IoT et plus encore.

Blazor est sur le point de prendre en charge le multithreading, et avec son intégration étroite avec le framework MAUI, Blazor est susceptible de devenir une technologie majeure pour créer des applications qui s’exécutent dans les navigateurs, sur les appareils mobiles et sur les ordinateurs de bureau, toutes basées sur les mêmes C #, HTML et Base de code CSS.