Blazor pour .NET 8 : un framework qui permet aux développeurs .NET de créer des applications web interactives
Blazor pour .NET 8 : un framework révolutionnaire qui permet aux développeurs .NET de créer des applications web interactives en utilisant C# au lieu de JavaScript
.NET Blazor a été présenté comme un framework révolutionnaire qui permet aux développeurs .NET de créer des applications web interactives en utilisant C# au lieu de JavaScript. Il s'adresse principalement aux développeurs ASP.NET Core qui souhaitent créer des applications de type SPA en tirant parti de l'écosystème .NET et d'une multitude de bibliothèques et d'outils existants disponibles via NuGet. Il s'agit de la dernière initiative de Microsoft pour tenter d'attirer les développeurs frontaux. Avec la récente sortie de .NET 8, Microsoft a annoncé encore plus d'améliorations pour Blazor, notamment l'introduction d'un nouveau mode de rendu appelé "Static Server-side Rendering (SSR)".
Mais qu'est-ce que Blazor exactement et comment permet-il au langage C# de fonctionner dans le navigateur ? Plus intéressant encore, comment se compare-t-il aux frameworks SPA traditionnels basés sur JavaScript avec lesquels il vise à rivaliser ?
Blazor WASM
Blazor a fait son chemin et pour comprendre l'état actuel de Blazor, il faut regarder son évolution en commençant par le début. Lancé en 2018, Blazor a d'abord commencé comme un projet expérimental, visant à tirer parti de WebAssembly pour exécuter C# directement dans le navigateur, permettant aux développeurs de construire des SPA en utilisant .NET. Cette idée s'est concrétisée avec Blazor WebAssembly, qui a permis au runtime .NET de s'exécuter sur le client.
Blazor WebAssembly, communément abrégé en Blazor WASM, offre l'expérience la plus proche d'une SPA parmi toutes les options de Blazor. Lorsqu'un utilisateur visite pour la première fois une application Blazor WASM, le navigateur télécharge le moteur d'exécution .NET avec les assemblages de l'application (beaucoup de .dll) et tout autre contenu requis sur le navigateur de l'utilisateur. Le moteur d'exécution téléchargé est un moteur d'exécution .NET basé sur WebAssembly (essentiellement un interprète .NET) qui est exécuté dans le moteur WebAssembly du navigateur. Ce runtime est responsable de l'exécution du code C# compilé entièrement dans le navigateur.
Bien que les applications Blazor WASM soient principalement écrites en C#, elles peuvent toujours interagir avec du code JavaScript. Cela permet d'utiliser les bibliothèques JavaScript existantes et d'accéder aux API du navigateur qui ne sont pas directement exposées à WebAssembly.
Bien que Blazor WASM ait reçu de nombreux éloges au départ et qu'il ait été amélioré au fil du temps, il a également fait l'objet de critiques importantes qui tournent souvent autour des aspects suivants :
- Temps de chargement initial : L'obligation de télécharger le moteur d'exécution .NET et les assemblages d'applications lors de la première visite peut entraîner un temps de chargement initial important. Ce phénomène est encore plus évident dans le cas d'applications complexes comportant de nombreuses dépendances, en particulier sur des réseaux lents.
- Performance : Blazor WASM est à la traîne des frameworks JavaScript traditionnels en termes de performances. Le moteur d'exécution WebAssembly reste généralement plus lent que le code JavaScript optimisé pour les charges de travail à forte intensité de calcul.
- Compatibilité : Bien que WebAssembly soit largement pris en charge par les navigateurs modernes, il peut subsister des problèmes avec les navigateurs plus anciens ou certains appareils mobiles, ce qui peut limiter la portée d'une application Blazor WASM.
- Défis en matière de référencement : Outre les problèmes habituels de référencement que posent tous les frameworks SPA, les temps de chargement plus longs et les performances plus lentes de Blazor WASM peuvent avoir un impact négatif sur le classement dans les moteurs de recherche.
- Complexité de l'interopérabilité avec JavaScript : Bien que Blazor WASM permette l'interopérabilité avec JavaScript, il peut être difficile à utiliser avec des bibliothèques JavaScript complexes ou lorsqu'il est nécessaire d'avoir une interaction importante entre les fonctions C# et JavaScript. Cette complexité peut entraîner des frais de développement supplémentaires et des goulets d'étranglement potentiels au niveau des performances. Malheureusement, en raison de plusieurs limitations, le besoin d'interopérabilité avec JavaScript est très courant, ce qui compromet en quelque sorte le principe même de l'utilisation de Blazor.
Blazor Server
Pour contrer certaines de ces critiques, Blazor Server a été introduit un an après Blazor WebAssembly, permettant au code C# côté serveur de gérer les mises à jour de l'interface utilisateur via une connexion SignalR. Contrairement à Blazor WASM, l'interface utilisateur côté client est maintenue par le serveur dans une application .NET Core. Après la demande initiale, une connexion WebSocket est établie entre le client et le serveur à l'aide d'ASP.NET Core et de SignalR.
Lorsqu'un utilisateur interagit avec l'interface utilisateur, l'événement est envoyé au serveur via la connexion SignalR. Le serveur traite l'événement et toutes les mises à jour de l'interface utilisateur sont rendues sur le serveur. Le serveur calcule ensuite la différence entre l'interface actuelle et la nouvelle interface et la renvoie au client via la connexion SignalR persistante. Ce processus permet de synchroniser les interfaces utilisateur du client et du serveur. Étant donné que la logique de l'interface utilisateur s'exécute sur le serveur, la logique de rendu proprement dite ainsi que le moteur d'exécution .NET n'ont pas besoin d'être téléchargés sur le client, ce qui réduit considérablement l'empreinte de téléchargement et répond directement à l'une des principales critiques formulées à l'encontre de Blazor WASM.
Cependant, bien qu'innovant dans son approche, Blazor Server présente plusieurs inconvénients qu'il convient de prendre en compte :
- La latence : Étant donné que chaque interaction avec l'interface utilisateur est traitée sur le serveur et nécessite un aller-retour sur le réseau, toute latence peut affecter de manière significative la réactivité d'une application Blazor Server. Cela peut être particulièrement problématique pour les utilisateurs ayant de mauvaises connexions réseau ou ceux qui sont géographiquement éloignés du serveur.
- Problèmes d'évolutivité : Chaque connexion client avec une application Blazor Server maintient une connexion SignalR active (principalement via WebSockets) avec le serveur. Cela peut entraîner des problèmes d'évolutivité, car le serveur doit gérer et maintenir l'état de milliers de connexions simultanément.
- Utilisation des ressources du serveur : Les applications Blazor Server sont beaucoup plus gourmandes en ressources car le serveur maintient l'état de l'interface utilisateur. Cela peut entraîner une utilisation accrue de la mémoire et du processeur, en particulier lorsque le nombre de clients connectés augmente.
- Dépendance à l'égard de SignalR : L'ensemble du fonctionnement d'une application Blazor Server dépend de la fiabilité de la connexion SignalR. Si la connexion est interrompue, l'application ne peut pas fonctionner. Cette dépendance nécessite une infrastructure robuste et augmente potentiellement la complexité du déploiement, en particulier dans les environnements d'entreprise avec des exigences de sécurité strictes qui peuvent restreindre l'utilisation de WebSocket.
- Pas de support hors ligne : Contrairement aux applications Blazor WebAssembly, Blazor Server nécessite une connexion constante au serveur. Si la connexion du client est interrompue, l'application cesse de fonctionner et l'état actuel peut être perdu. Blazor Server n'est donc pas adapté aux environnements nécessitant des fonctionnalités hors ligne.
- Exigence du serveur ASP.NET Core : La dépendance à SignalR signifie également que les applications Blazor Server ne peuvent pas être servies à partir d'un réseau de diffusion de contenu (CDN) comme d'autres frameworks SPA JavaScript. Les déploiements sans serveur ne sont pas possibles et Blazor Server nécessite le déploiement d'un serveur ASP.NET Core à part entière.
Blazor Static SSR
Malgré la polyvalence de Blazor, les modes de rendu WASM et Server souffrent de sérieux inconvénients qui font de Blazor un choix difficile par rapport aux frameworks SPA traditionnels qui, en comparaison, ne partagent aucun des problèmes de Blazor et sont également plus simples d'un point de vue architectural.
Conscient de ces problèmes, Microsoft s'est attaqué à certaines des principales préoccupations de Blazor WASM et Server en déployant Blazor Static SSR :
Blazor Static SSR, comme le montre le diagramme ci-dessus, est une troisième option de rendu qui fonctionne de manière totalement indépendante de WASM ou SignalR, en s'appuyant sur une connexion HTTP ouverte pour transmettre les mises à jour de l'interface utilisateur au client. Cette approche, connue sous le nom de rendu de site statique, implique la génération de pages web côté serveur et la transmission du code HTML entièrement composé au client, où il est ensuite reconnecté au DOM pour fonctionner comme une application dynamique.
Lors du chargement initial d'une page, Blazor Static SSR se comporte de la même manière qu'une application traditionnelle côté serveur en fournissant une page HTML complète au navigateur de l'utilisateur. En outre, il récupère un script blazor.server.js qui établit une connexion HTTP de longue durée avec un serveur ASP.NET Core. Cette connexion est utilisée pour diffuser les mises à jour de l'interface utilisateur au client. Cette architecture est plus simple, un peu comme un site web classique avec rendu serveur, mais elle offre une expérience dynamique, de type SPA, en mettant à jour de manière sélective des parties du DOM et en éliminant ainsi le besoin de recharger complètement la page.
Les avantages par rapport à Blazor WASM et Blazor Server sont doubles :
- Réduction des temps de chargement : Les utilisateurs n'ont pas besoin de télécharger l'intégralité du runtime .NET et des fichiers d'application lorsqu'ils visitent le site web, et lorsqu'ils naviguent sur le site, les rechargements complets de la page sont évités.
- Évolutivité : Aucune connexion SignalR n'est nécessaire, ce qui réduit considérablement la charge sur le serveur et élimine une grande partie des complexités liées aux connexions WebSocket.
Néanmoins, Blazor Static SSR n'est pas un cadre SPA au sens traditionnel du terme. Il ne permet pas une interactivité riche au-delà des formulaires web et de la simple navigation. Il ne permet pas non plus les mises à jour en temps réel, car aucun code ne s'exécute sur le client après le chargement de la page initiale :
Pour remédier à cela, Blazor, à partir de .NET 8, permet de mélanger différents modes et introduit une quatrième option de rendu appelée mode Auto.
Pour ajouter de l'interactivité à un site web Blazor Static SSR, il faut revenir à la création de composants Blazor WASM ou Blazor Server. L'option de rendu automatique vise à contrer les principaux problèmes que sont les temps de chargement lents de Blazor WASM et l'exigence d'une connexion SignalR de Blazor Server en utilisant les deux modes de rendu à des moments différents :
Un composant Blazor fonctionnant en mode Auto commence par établir une connexion SignalR pour permettre une interactivité immédiate et éviter les temps de chargement prolongés. Parallèlement, il récupère discrètement le moteur d'exécution .NET et toutes les dépendances nécessaires pour fonctionner en tant qu'application WASM Blazor. Pour les visites ultérieures, Blazor passe de la version serveur à la version WASM, en maintenant la réactivité de la SPA sans dépendre davantage de la connexion SignalR.
C'est une approche fascinante qui ne manque pas de créativité ni d'ambition. Néanmoins, Blazor Static SSR incorporé avec des composants interactifs pose quelques défis anciens et nouveaux :
- Pas d'interactivité sans WASM ou SignalR : Le plus grand inconvénient de Blazor Static SSR est qu'il dépend toujours de Blazor WASM ou SignalR pour devenir un framework interactif, ce qui signifie qu'il hérite non seulement d'un, mais de tous les nombreux inconvénients non résolus lorsqu'il fonctionne en mode automatique.
- Complexité accrue : La combinaison de trois modes de rendu différents ajoute beaucoup de complexité sur le serveur et présente une courbe d'apprentissage abrupte pour les développeurs qui doivent comprendre et gérer ces complexités efficacement.
- Pas de déploiement sans serveur : Les déploiements à partir d'un CDN ne sont toujours pas possibles en raison de la dépendance à ASP.NET Core.
- Pas de support hors ligne : Blazor Static SSR minimise les recharges de pages complètes mais nécessite toujours une connexion active pour diffuser les mises à jour dans l'interface utilisateur.
- Défis liés à la mise en cache : Alors que le contenu statique peut facilement être mis en cache, le contenu dynamique qui change fréquemment peut être difficile à mettre en cache de manière efficace, ce qui peut entraîner la perte de précieuses optimisations de performance.
Cela dit, Blazor Static SSR offre également quelques avantages lorsqu'il n'est pas mélangé avec WASM ou Server together :
- Facilité de référencement : Comme les applications SSR préchargent tout le contenu sur le serveur et l'envoient au client sous forme de HTML, elles sont intrinsèquement favorables au référencement. Cela permet aux moteurs de recherche d'explorer et d'indexer le contenu plus efficacement.
- Chargement initial rapide : Blazor Static SSR peut fournir des chargements initiaux de page plus rapides que les SPA. En effet, le HTML est prêt à être rendu par le navigateur dès qu'il est reçu, sans attendre que le JavaScript côté client rende le contenu.
- Stabilité entre les navigateurs : Les applications de RSS ont souvent un comportement plus cohérent entre les différents navigateurs puisqu'elles ne dépendent pas du rendu côté client, qui peut parfois être imprévisible en raison des bizarreries JavaScript propres à chaque navigateur.
Blazor vs SPAs JavaScript traditionnelles
Dans l'ensemble, Blazor est une réalisation remarquable, avec beaucoup d'originalité et de finesse technique, mais à l'exception de Blazor WASM, Blazor Server et Blazor Static SSR se comportent très différemment des SPA traditionnelles.
Ni Blazor Server ni Blazor Static SSR ne chargent d'emblée tout le HTML, le JavaScript et le CSS nécessaires. Ils dépendent fortement d'un backend ASP.NET Core, ne peuvent pas être hébergés sans serveur et nécessitent une connexion constante à un serveur. Le frontend n'est pas séparé du backend et les données ne sont pas récupérées à l'aide d'API. Les SPA typiques maintiennent l'état côté client. Les interactions de l'utilisateur avec l'application peuvent modifier l'état, et l'interface utilisateur est mise à jour en conséquence sans aller-retour avec le serveur. Comme les SPA ne nécessitent pas de rechargement de la page pour les mises à jour de contenu, elles peuvent offrir une expérience utilisateur plus fluide et plus rapide, similaire à celle des applications de bureau. Avec les SPA conventionnelles, le même code peut souvent être partagé entre les applications web et mobiles, ce qui constitue un autre avantage par rapport à Blazor Server ou Static SSR. La séparation nette entre le frontend et le backend simplifie le modèle mental global et permet de répartir efficacement les disciplines entre différentes équipes.
Blazor WASM vs les SPA JavaScript
Blazor WASM se distingue comme étant la seule option de rendu qui s'aligne entièrement sur l'éthique d'une SPA conventionnelle. Malheureusement, la lourdeur de l'exécution du Runtime .NET sur WebAssembly le désavantage considérablement par rapport aux frameworks JavaScript comparables.
Blazor Server vs les SPA JavaScript
Bien que Blazor Server soit techniquement intriguant, offrant une approche unique du développement web, il combine paradoxalement les limitations d'une application à page unique et d'une architecture à forte intensité de serveur. Dans une certaine mesure, Blazor Server représente le pire des deux scénarios. Personnellement, c'est l'option la moins appréciée et cette conception ne semble pas avoir d'avenir.
Blazor Static SSR vs les SPA JavaScript
Blazor Static SSR s'écarte le plus du paradigme d'une SPA. En plus d'être placé sous la marque Blazor, il diverge significativement de l'architecture initiale du framework. Paradoxalement, c'est aussi là que résident ses points forts. Étant donné que les SPA sont intrinsèquement accompagnées de leur propre série de défis, la nécessité d'une SPA doit être bien justifiée, sinon opter pour une application orientée serveur peut être une solution plus directe et préférable la plupart du temps.
Blazor Static SSR est une option convaincante qui mérite d'être son propre framework, permettant aux développeurs .NET d'enrichir les fonctionnalités de l'ASP.NET Core de tous les jours.
Un mot d'avertissement
Est-ce qu'il faudrait opter pour Blazor aujourd'hui ? Pour être franc, probablement pas. Bien que Blazor suscite l'espoir, il faut rester honnête avec soi-même. La vérité, c'est que Blazor est en train de devenir une bête difficile à manier. En dépit de ses quatre modes de rendu, de ses couches complexes et de ses correctifs techniques astucieux, il n'est toujours pas à la hauteur des SPA établies. Cette situation nous amène à nous interroger sur la longévité de l'engagement de Microsoft et sur la durée de vie de Blazor. Les parallèles avec Silverlight sont difficiles à ignorer, et si l'équipe .NET ne fournit pas un framework techniquement solide, il est difficile d'envisager une adoption généralisée au-delà d'un groupe relativement restreint de passionnés de C# qui accepteront n'importe quelle folie à l'idée d'utiliser JS.
Une opportunité inexploitée ?
Pour terminer sur une note positive, C# pourrait-il apprendre quelque chose de plus du F# ? Grâce à Fable, un transpileur F# vers JavaScript, les développeurs F# ont été en mesure de créer des SPA interactives riches en utilisant F# depuis un certain temps. Développé en 2016, Fable a été construit à l'origine sur Babel, un compilateur ECMAScript 2015+ vers JavaScript. Quelque chose de similaire ne pourrait-il pas fonctionner pour le langage C# ? Cela pourrait ouvrir la voie à un framework C# très attrayant qui contournerait les complexités autour de WASM et SignalR.
Blazor n'a pas que le nom, mais aussi la gloire.
En fait, il est assez surprenant que nous n'ayons pas encore vu un tel développement, mais c'est peut-être une question de point de vue. Peut-être s'agit-il d'un cas où la mauvaise équipe s'est penchée sur le mauvais problème depuis le début ? Après tout, l'équipe ASP.NET Core excelle dans le développement web et non dans la conception de compilateurs. Tous les problèmes n'ont pas besoin d'être résolus à l'aide de SignalR ou d'API de streaming. Il est peut-être temps de suspendre l'utilisation d'autres modes de rendu et d'envisager Blazor sous un angle différent.
C'est sans doute la meilleure voie à suivre et il faut garder l'espoir jusqu'à ce moment-là.
Source : ".NET Blazor" par Dustin Moris G., ingénieur en informatique
Et vous ?
Que pensez-vous de Blazor pour .NET 8 ?
Voir aussi
Répondre avec citation
Partager