Blazor de zéro : Chapitre 1 — Qu'est-ce que Blazor ?

· 8 min de lecture
Blazor .NET Web Development Series
Available in: Français · English · Español · Deutsch · Português · 한국어 · 日本語 · Русский · 中文 · العربية · हिन्दी · Polski · Türkçe · Bahasa Indonesia · Nederlands

Bienvenue au Chapitre 1 de Blazor de zéro. Si vous avez manqué le post d’introduction où j’explique le but de cette série et à qui elle s’adresse, commencez par là — c’est court.

Dans ce chapitre, nous allons répondre à la question fondamentale : qu’est-ce que Blazor ? Cela semble simple, mais la réponse a plusieurs couches, d’autant plus que « Blazor » a pris des significations légèrement différentes au fil des années. À la fin de ce post, vous saurez ce qu’est Blazor, comment il s’intègre dans l’écosystème .NET, quels sont les différents modèles de rendu et pourquoi vous pourriez — ou non — le choisir plutôt qu’un framework JavaScript.

Un peu d’histoire

Blazor a démarré comme un projet expérimental de Steve Sanderson chez Microsoft vers 2017. L’idée était provocatrice : exécuter du C# dans le navigateur via WebAssembly, en éliminant totalement le besoin de JavaScript. C’était une preuve de concept, et le nom était un mélange délibéré de Blazer et Razor — le moteur de templates sur lequel Blazor allait finalement être construit.

L’expérience a suscité suffisamment d’enthousiasme pour que Microsoft la prenne au sérieux. Blazor a été livré dans le cadre d’ASP.NET Core 3.0 en septembre 2019, d’abord sous forme de Blazor Server — un modèle qui exécute votre code C# sur le serveur et utilise une connexion SignalR en temps réel pour envoyer les mises à jour de l’interface au navigateur. Blazor WebAssembly a suivi en mai 2020 dans le cadre d’ASP.NET Core 3.1, apportant une véritable exécution côté client au framework.

.NET 6 et 7 ont affiné l’expérience développeur. Puis .NET 8, publié en novembre 2023, a fondamentalement repensé le modèle de rendu avec ce que Microsoft a appelé UI web full-stack. Le rendu statique côté serveur, le streaming rendering, le serveur interactif, WebAssembly interactif et un nouveau mode Auto coexistaient sous le même toit dans un seul projet. .NET 9 a construit sur ces fondations et corrigé les aspérités.

C’est là où nous en sommes aujourd’hui.

Ce qu’est vraiment Blazor

À son cœur, Blazor est un framework d’interface basé sur les composants pour .NET. Vous construisez votre interface à partir de composants — des éléments autonomes de C# et de balisage HTML qui peuvent maintenir un état, répondre à des événements et se composer en structures plus larges. Si vous avez travaillé avec React ou Vue, ce modèle mental vous semblera familier. La différence clé est qu’au lieu de JavaScript, vous écrivez du C#.

Les composants Blazor s’écrivent dans des fichiers .razor. Un fichier .razor mélange du balisage HTML et du code C# en utilisant la syntaxe Razor que vous connaissez peut-être déjà des vues ASP.NET MVC. Voici à quoi ressemble un composant simple :

@page "/counter"

<h1>Compteur</h1>
<p>Compte actuel : @currentCount</p>
<button @onclick="IncrementCount">Cliquez ici</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

Pas de JavaScript en vue. La directive @onclick connecte le clic du bouton à une méthode C#. L’expression @currentCount affiche la valeur actuelle. Quand l’état change, Blazor détermine ce qu’il faut mettre à jour dans le DOM.

C’est l’essentiel. Tout le reste — routage, injection de dépendances, formulaires, appels HTTP — est construit sur ce modèle de composants.

Les modèles de rendu

C’est là que réside beaucoup de confusion, alors soyons précis. « Blazor » désigne aujourd’hui une famille de modes de rendu, pas un seul modèle de déploiement. Comprendre la différence est important car cela affecte les performances, les exigences d’infrastructure et ce que vos composants peuvent ou ne peuvent pas faire.

SSR statique

Le mode le plus simple. Vos composants Razor s’affichent sur le serveur en HTML et ce HTML est envoyé au navigateur. Il n’y a pas de connexion persistante, pas de WebAssembly et pas d’interactivité côté client par défaut. C’est essentiellement ce que fait Razor Pages, mais en utilisant le modèle de composants.

Utilisez-le pour les pages riches en contenu, les landing pages, tout ce qui ne nécessite pas d’interactivité en temps réel.

Serveur interactif

Votre code de composant s’exécute sur le serveur. Une connexion WebSocket SignalR est établie entre le navigateur et le serveur. Quand vous cliquez sur un bouton ou tapez dans un champ, l’événement voyage via le WebSocket jusqu’au serveur, votre C# s’exécute, le diff est calculé et les mises à jour du DOM sont renvoyées au navigateur.

Avantages : Accès complet aux ressources serveur (bases de données, système de fichiers, secrets). Chargement initial rapide. Taille de téléchargement réduite. Fonctionne dans les navigateurs sans support WebAssembly.

Inconvénients : Chaque interaction utilisateur nécessite un aller-retour vers le serveur, ce qui ajoute de la latence. Les ressources serveur s’adaptent au nombre de connexions actives. L’application se dégrade si la connexion est interrompue.

Utilisez-le pour les applications métier, les outils internes, les applications où l’accès aux données côté serveur prime sur la capacité hors ligne.

WebAssembly interactif

Le runtime .NET est téléchargé dans le navigateur et votre application s’exécute entièrement côté client. Après le téléchargement initial, l’application fonctionne complètement hors ligne et chaque interaction est instantanée — sans allers-retours serveur pour la logique d’interface.

Avantages : Exécution véritablement côté client. Fonctionne hors ligne. Charge serveur réduite une fois l’application chargée.

Inconvénients : Téléchargement initial plus volumineux (runtime .NET + votre application). Premier chargement plus lent. Vous avez besoin d’une API pour accéder aux données côté serveur.

Utilisez-le pour les applications pouvant fonctionner hors ligne, les outils nécessitant une réactivité immédiate, les scénarios où le traitement serveur n’est pas nécessaire pour l’interface.

Mode Auto

Introduit dans .NET 8. L’application démarre en mode Serveur interactif (chargement initial rapide, sans attendre que WebAssembly se télécharge). Une fois les fichiers WebAssembly téléchargés en arrière-plan, les visites suivantes basculent automatiquement en mode WebAssembly.

Cela vous donne le chargement initial rapide du mode Serveur et finalement l’exécution complète côté client de WebAssembly. C’est le modèle le plus complexe à appréhender, mais c’est une valeur par défaut pratique pour de nombreuses applications.

Mélanger les modes dans la même application

Avec .NET 8 et les versions ultérieures, vous n’êtes pas limité à un seul mode de rendu pour toute l’application. Une landing page peut être en SSR statique ; le tableau de bord authentifié peut être en Serveur interactif ; un widget de visualisation de données peut être en WebAssembly interactif. Le framework gère les transitions.

Dans cette série, nous commencerons par le Serveur interactif car c’est le plus simple à mettre en place et le modèle mental le plus direct. Nous explorerons les autres modes au fur et à mesure.

Comment Blazor se compare aux frameworks JavaScript

Si vous avez développé avec React, Angular ou Vue, c’est probablement la comparaison qui vous intéresse.

Les similitudes sont réelles. Le modèle de composants de Blazor est délibérément similaire à celui de React. Vous avez des props (Paramètres dans Blazor), un état local (champs dans le bloc @code), des hooks de cycle de vie et le même modèle de communication données vers le bas / événements vers le haut. Si vous connaissez React, vous serez à l’aise en quelques heures.

La différence clé est le langage. Dans Blazor, vous écrivez du C#. Votre logique métier, vos règles de validation et vos modèles de données peuvent tous être partagés entre votre frontend Blazor et votre backend ASP.NET Core. Fini de dupliquer une classe User en TypeScript quand vous l’avez déjà en C#.

L’écart d’écosystème est réel mais se réduit. L’écosystème npm est énorme. L’écosystème NuGet pour les composants d’interface est plus petit, bien qu’il ait considérablement grandi. Pour une librairie de graphiques spécifique ou un widget de glisser-déposer, JavaScript a encore plus d’options. Mais pour la plupart des applications métier, ce qui est disponible dans l’écosystème .NET est largement suffisant.

L’interopérabilité JavaScript existe quand vous en avez besoin. Blazor vous permet d’appeler JavaScript depuis C# et C# depuis JavaScript. Pour les API navigateur sans wrapper .NET, ou quand vous voulez utiliser une librairie JS existante, l’interop est disponible. Cela ajoute une couche mais ce n’est pas pénible.

La réponse honnête : si votre équipe est entièrement composée de développeurs JavaScript qui construisent un produit public où le SEO, les performances et l’écosystème npm sont critiques, restez avec JavaScript. Si votre équipe est composée de développeurs .NET, si vous construisez des applications internes ou métier, ou si le partage de code entre frontend et backend vous importe, Blazor est un choix convaincant.

Ce dont vous avez besoin pour suivre la série

Pour le reste de cette série, vous aurez besoin de :

  • .NET 9 SDK — téléchargez-le sur dot.net
  • Un IDE — Visual Studio 2022 (l’édition Community est gratuite), VS Code avec l’extension C# Dev Kit, ou JetBrains Rider
  • Une aisance de base avec C# — classes, propriétés, interfaces, async/await

C’est tout. Pas de Node, pas de npm, pas de webpack.

La suite

Au Chapitre 2, nous allons générer votre première application Blazor, parcourir la structure du projet et nous assurer que vous pouvez l’exécuter localement. À la fin, vous aurez une application fonctionnelle et une image claire de ce que fait chaque fichier.

À bientôt.