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,...