Article_Blazor_blogue

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

Blazor. 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).

Tout d’abord, pour ceux qui ne connaissent pas du tout Blazor, une brève présentation de ce que c’est. 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. 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 va changer le 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.

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *