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

Trouvez-vous l'analyse de M. Moris cr�dible et pertinente ?

Voir aussi

Microsoft annonce .NET 8 avec des am�liorations en mati�re de performances, de stabilit� et de s�curit�, ainsi que des am�liorations de la plateforme et des outils pour accro�tre la productivit�

Microsoft d�voile les mises � jour apport�es � ASP.NET Core dans .NET 8 Preview 2, dont l'ajout de Blazor QuickGrid et de plusieurs am�liorations de performance

Microsoft publie la premi�re pr�version publique de Blazor, son framework web .NET exp�rimental qui s'ex�cute au sein du navigateur