Développement web: Pourquoi Blazor est le framework idéal?

Par Bruno Barrette

Début novembre 2018, alors que ce n’était encore qu’un produit expérimental, j’en parlais lors d’un événement que nous avions organisé à nos bureaux. D’ailleurs, mon powerpoint pour la présentation avait été fait avec Blazor, j’en avais surpris plus d’un lorsque j’ai dévoilé le punch à la fin.

J’ai suivi l’évolution de cette expérience, qui est devenue un produit officiellement en développement, jusqu’à ce que ce soit lancé dans sa version WebAssembly en mai 2020. S’en est suivi une conférence au Blazor Day en juin, que j’ai présenté à 3 autres occasions dans la même année, quelques épisodes du Bracket Show sur le sujet, en plus d’un projet à temps plein depuis juin dernier.

Oh, et je ne fais que harceler mes collègues sur comment Blazor est merveilleux et pourquoi il n’y a que des gains à l’utiliser. J’ai donc eu envie de partager pourquoi cette technologie est à mon avis une grande révolution, mais sans entrer trop dans le côté technique (je laisse cet aspect à ce qu’on fait avec le Bracket Show).

HISTOIRE du framework

Début novembre 2018, alors que ce n’était encore qu’un produit expérimental, j’en parlais lors d’un événement que nous avions organisé à nos bureaux. D’ailleurs, l’un des powerpoint pour l’évènement avait été fait avec Blazor, j’en avais surpris plus d’un lorsque j’ai dévoilé le punch à la fin.

Depuis, j’ai suivi l’évolution de cette expérience, qui est devenue un produit officiellement en développement, jusqu’à ce que ce soit lancé officiellement dans sa version WebAssembly en mai 2020. 

S’en est suivi une conférence au Blazor Day en juin, que j’ai présenté à 3 autres occasions dans la même année, quelques épisodes du Bracket Show sur le sujet, en plus d’un projet à temps plein depuis juin dernier. Oh, et à cette époque, je ne faisait que harceler mes collègues sur comment Blazor est merveilleux et pourquoi il n’y a que des gains à l’utiliser. 

Et la bonne nouvelle est, qu’en novembre 2023, Microsoft lancera une nouvelle version Blazor, présentement nommée « Blazor United » , qui combine les avantages de « Razor pages », « Blazor Server » et « Blazor WebAssembly » en une seule framework. Un moyen pour les composantes Blazor de devenir une architecture unique pour tous vos scénarios d’interface utilisateur Web, soit qu’on aura la possibilité de basculer facilement entre différents modes de rendu et même de les mélanger dans la même page. 

Dans cet article, j’ai donc envie de partager pourquoi cette technologie est à mon avis une grande révolution, mais sans entrer trop dans le côté technique (je laisse cet aspect à ce qu’on fait avec le Bracket Show).

C’est quoi Blazor ?

Tout d’abord, pour ceux qui ne connaissent pas du tout Blazor.

Blazor est un cadriciel (framework) permettant de développer des applications web monopage (Single Page Application) en utilisant que du C#. On peut toujours utiliser du JavaScript, par contre ce n’est plus le langage principal comme avec les cadriciels populaires pour les applications client, tel que Angular ou React. Et contrairement à ce que certaines personnes ont connu avec Silverlight, aucun plugin n’est requis au niveau du navigateur grâce à WebAssembly, un standard web ouvert qui permet d’exécuter du code binaire dans le navigateur. 

En d’autres termes, le code compilé pour notre application est exécuté tel quel dans le navigateur, il n’est pas transformé de la même manière que TypeScript qui est ultimement du JavaScript une fois transpilé. On arrive donc à la question suivante: pourquoi est-ce si intéressant?

Blazor vaut-il la peine d’être appris ?

La première chose que je trouve intéressante c’est le fait qu’on travaille sur un seul langage de programmation. Je n’ai rien contre le fait de travailler avec différents langages dans un même projet, par contre travailler avec un seul augmente selon moi notre productivité (lorsque c’est un langage avec lequel on est à l’aise évidemment). Avec Blazor, un développeur full-stack n’a plus besoin de connaître multiples frameworks; s’il connaît C#, MVC, ASP.NET, il a déjà presque tout ce qu’il faut pour faire du Blazor.

Certes, il faut se maintenir à jour d’un point de vue technologique, apprendre de nouveaux langages, essayer de nouvelles choses, je ne serais pas là à parler de Blazor si je ne l’avais pas fait. Par contre dans l’optique qu’un framework est un peu comme une boîte à outils, si j’ai le choix entre apporter avec moi un seul coffre qui contient des outils que je maîtrise très bien, versus deux coffres dont un qui contient des choses avec lesquelles j’ai moins de connaissance, mon choix va être porté vers ce qui me donne un meilleur rendement.

Évitez les erreurs avec un seul langage de programmation: C#

Ensuite il y a évidemment le langage de programmation, c’est-à-dire C#. Sur ce point c’est évidemment une préférence personnelle, et un choix d’entreprise, par contre là où l’avantage est selon moi est sur le côté fortement typé. Avec JavaScript et TypeScript (je vise ceux-ci vu leur utilisation courante du côté du web), il est facile d’introduire des erreurs dans nos applications simplement avec une faute sur le nom d’une propriété ou variable. Le moment où on le réalisera, ce sera pendant l’exécution de l’application, et ce ne sera pas toujours évident d’où provient l’erreur. Et même si ce l’est, il faut surtout se dire qu’on aurait dû attraper cette erreur en amont, avant même de pouvoir exécuter notre application. C’est sur ce point que Blazor, et C#, viennent se démarquer.

Language de programmation typé

En utilisant un langage fortement typé, on ne peut pas se tromper sur le nom d’une propriété ou variable, l’application ne compilera pas. On ne peut pas décider d’ajouter une propriété à la volée sur un objet, l’application ne compilera pas. Ceci nous assure tout d’abord une sécurité sur le fonctionnement de l’application (avant même de parler de tests unitaires pour en assurer le bon fonctionnement), et cela nous évite de devoir retourner dans notre code pour corriger la faute dans un mot qui fait que rien ne fonctionne.

Évitez à nouveau la duplication de code

Pour terminer, un autre point important en faveur de Blazor est la duplication de code, ou plutôt l’élimination de ceci. Pendant toute ma carrière, qui a débuté dans les applications Windows avec VB6, on m’a martelé l’idée qu’il fallait éviter de dupliquer du code. “Il faudrait extraire une fonction pour éviter de dupliquer le code”, « Tu pourrais utiliser le polymorphisme pour éviter de répéter du code qui est commun à tes objets”, et j’en passe. Jusqu’au jour où je suis tombé sur un projet avec le côté serveur en C# et le côté client en Angular avec TypeScript. Là j’ai commencé à entendre des phrases de ce genre:

“Pour ton modèle que ton API expose, il va falloir faire un objet identique du côté client. Et n’oublie pas de le mettre à jour quand tu le modifies”

“La validation il faut la mettre côté serveur. Par contre il faudrait aussi refaire le même genre de chose côté client pour que l’utilisateur ne puisse pas saisir n’importe quoi”.

On se retrouvait donc à dupliquer du code, cette action qu’on proscrit depuis des années! Ça ne faisait pas de sens dans ma tête, et évidemment ce genre de chose vient ajouter un risque d’oublier un changement, qu’on va encore une fois réaliser uniquement au moment d’essayer notre application. Avec Blazor, ce souci disparaît, tout simplement. Blazor permet de partager des librairies entre le côté client et serveur, on peut donc facilement y centraliser nos objets de communication entre client et serveur ainsi que des choses comme la validation. Plus besoin de répéter, on vient donc augmenter notre productivité, uniformiser les comportements, réduire nos risques d’erreurs et surtout éviter de se retrouver à maintenir deux fois le “même code”.

BLAZOR, LE FUTUR DU développement web?

J’espère que ce point de vue sur Blazor vous aura intéressé, peut-être même que cela vous aura donné le goût de l’essayer. Une chose est certaine, Blazor n’est pas que de passage, il est là pour rester. Plusieurs efforts sont en cours présentement pour en faire un langage de choix autant pour les applications web que mobiles et de bureau, donc si vous développez en utilisant C#, les chances que vous fassiez du Blazor dans les prochaines années sont très fortes. 

Si vous voulez en savoir plus, n’hésitez pas à consulter nos autres articles sur Blazor ou à découvrir nos vidéos sur notre chaîne Youtube Bracket Show.

Découvrez également nos réalisations ainsi que notre offre de service sur la création de logiciels sur mesure.

Pour suivre le lancement de la nouvelle version de Blazor en novembre 2023, c’est par ici. 

Autres articles qui pourraient vous intéresser

Custom Software Development | Done Technologies

Les microservices : une architecture Agile — Deuxième partie

Lisez la première partie de cet article ici : « Les microservices : une architecture Agile — Première partie ». Utiliser le DDD (Domain Driven Design) pour créer des microservices En nous appuyant sur la séparation des modèles qu’offre le DDD, nous pouvons rejoindre facilement le même concept qui est à la base des microservices. Il suffit de décomposer...
Custom Software Development | Done Technologies

Technique spike : tout ce qu’il y a à savoir sur la technique

Initialement introduite par l’Extreme Programming, il existe une technique qui consiste à ajouter un élément au carnet de produit (product backlog) qu’on peut qualifier de « Spike ». Il s’agit d’un item pour lequel l’équipe s’entend sur une limite de temps à investir. Le but est d’acquérir des connaissances qui sont nécessaires pour réduire le risque, pour...
CQRS et Event Sourcing : nos meilleures ressources

CQRS et Event Sourcing: nos meilleures ressources

CQRS est un schéma (« pattern ») d’architecture et de conception qui sépare la lecture des données (requête) des actions (commandes) dans le but de produire un système qui peut facilement être mis à l’échelle (« scaling ») et offrir des avantages utiles. Consultez la présentation d’un de nos experts. Voici quelques articles connexes (anglais...