Présentation de Blazor pour les développeurs ASP.NET Web Forms

Le framework ASP.NET Web Forms est un incontournable du développement web .NET depuis la première publication du .NET Framework en 2002. Alors que le web était encore à ses tout premiers balbutiements, ASP.NET Web Forms a rendu la création d’applications web simple et productive en adoptant un grand nombre des schémas qui étaient utilisés pour le développement de bureau. Dans ASP.NET Web Forms, les pages web peuvent être rapidement composées à partir de contrôles IU réutilisables. Les interactions utilisateur sont gérées naturellement comme des événements. Il existe un riche écosystème de contrôles IU Web Forms fournis par Microsoft et les fournisseurs de contrôles. Les contrôles allègent les efforts pour se connecter aux sources de données et pour afficher des visualisations de données riches. Pour l’aspect visuel, le concepteur Web Forms fournit une interface simple par glisser-déposer pour gérer les contrôles.

Année après année, Microsoft a introduit de nouveaux frameworks web basés sur ASP.NET pour répondre aux tendances du développement web. Parmi ces frameworks web, citons ASP.NET MVC, ASP.NET Web Pages et plus récemment ASP.NET Core. Chaque fois qu’un nouveau framework sortait, certains prédisaient le déclin imminent d’ASP.NET Web Forms et le critiquaient en affirmant que c’était un framework web obsolète et démodé. Malgré ces prédictions, de nombreux développeurs web .NET continuent de voir ASP.NET Web Forms comme un moyen simple, stable et productif de faire leur travail.

À l’heure où nous rédigeons cet article, près d’un demi-million de développeurs web utilisent ASP.NET Web Forms chaque mois. Le framework ASP.NET Web Forms est stable au point que la documentation, les exemples, les livres et les billets de blog écrits il y a dix ans ont gardé toute leur utilité et leur pertinence. Pour de nombreux développeurs web .NET, « ASP.NET » reste synonyme de « ASP.NET Web Forms » comme c’était le cas quand .NET a été conçu pour la première fois. Les arguments sur les pour et les contre d’ASP.NET Web Forms par rapport aux autres nouveaux frameworks web .NET peuvent continuer à faire rage. ASP.NET Web Forms reste un framework populaire pour créer des applications web.

Malgré tout, les innovations dans le développement logiciel ne ralentissent pas. Tous les développeurs de logiciels doivent rester au courant des nouvelles technologies et tendances. Deux tendances en particulier méritent notre attention :

1. Le passage à l’open source et au multiplateforme
2. Le passage de la logique d’application au client

Un .NET open source et multiplateforme

Lorsque .NET et ASP.NET Web Forms ont été publiés pour la première fois, l’écosystème de la plateforme était très différent de ce qu’il est aujourd’hui. Les marchés Desktop et Server étaient dominés par Windows. D’autres plateformes comme macOS et Linux luttaient encore pour se faire une place. ASP.NET Web Forms est livré avec le .NET Framework en tant que composant uniquement Windows, ce qui signifie que les applications ASP.NET Web Forms ne peuvent s’exécuter que sur des ordinateurs Windows Server. Actuellement, de nombreux environnements modernes utilisent différents types de plateformes pour les serveurs et les ordinateurs de développement, de sorte que la prise en charge multiplateforme est une condition sine qua non pour de nombreux utilisateurs.

La plupart des frameworks web modernes sont aussi maintenant open source, ce qui présente un certain nombre d’avantages. Les utilisateurs ne sont pas tenus à un seul propriétaire de projet pour corriger les bogues et ajouter des fonctionnalités. Les projets open source offrent une meilleure transparence sur la progression du développement et les changements à venir. Les projets open source bénéficient des contributions de toute une communauté et favorisent un écosystème open source de grand soutien. Malgré les risques liés à l’open source, de nombreux consommateurs et contributeurs ont trouvé des atténuations appropriées qui leur permettent de profiter des avantages d’un écosystème open source de manière sûre et raisonnable. Parmi ces atténuations, citons les contrats de licence de contributeur, les licences conviviales, les analyses de pedigree et les fondations de soutien.

La communauté .NET a adopté la prise en charge du multiplateforme et l’open source. .NET Core est une implémentation open source et multiplateforme de .NET qui s’exécute sur une multitude de plateformes, notamment Windows, macOS et diverses distributions Linux. Xamarin fournit Mono, version open source de .NET. Mono s’exécute sur Android, iOS et divers autres facteurs de forme, notamment les montres et les télévisions intelligentes. En 2020, Microsoft a publié .NET 5 qui a réuni .NET Core et Mono dans « un seul runtime et framework .NET qui peut être utilisé partout et qui a des comportements d’exécution et des expériences de développement uniformes ».

Est-ce qu’ASP.NET Web Forms tire parti du passage à l’open source et à la prise en charge du multiplateforme ? Malheureusement, la réponse est non, ou du moins pas autant que le reste de la plateforme. L’équipe .NET a clairement indiqué que la technologie ASP.NET Web Forms ne sera pas portée sur .NET Core ou .NET 8. Pourquoi ?

Des efforts ont été faits au début de .NET Core pour porter ASP.NET Web Forms. Le nombre de changements cassants requis a été jugé trop élevé. Il a également été admis que, même pour Microsoft, le nombre de frameworks web qu’il peut prendre en charge simultanément est limité. Peut-être qu’une personne de la communauté embrassera la cause et créera une version open source et multiplateforme d’ASP.NET Web Forms. Le code source d’ASP.NET Web Forms a été mis à la disposition de tout le monde sous forme de référence. Mais pour l’instant, il semble qu’ASP.NET Web Forms reste réservé à Windows et sans modèle de contribution open source. Si la prise en charge du multiplateforme ou l’open source deviennent importants pour vos scénarios, vous devrez alors rechercher quelque chose de nouveau.

Cela signifie-t-il qu’ASP.NET Web Forms est mort et ne devrait plus être utilisé ? Bien sûr que non ! Tant que le .NET Framework est fourni avec Windows, ASP.NET Web Forms reste un framework pris en charge. Pour de nombreux développeurs Web Forms, l’absence de prise en charge du multiplateforme et de l’open source n’est pas un problème. Si vous n’avez pas besoin de la prise en charge multiplateforme, de l’open source ou de l’une des autres nouvelles fonctionnalités de .NET Core ou de .NET 8, vous pouvez très bien continuer à utiliser ASP.NET Web Forms sur Windows. ASP.NET Web Forms reste et restera un moyen productif d’écrire des applications web pendant encore de nombreuses années.

Toutefois, une autre tendance est à prendre en considération : le passage au client.

Développement web côté client

Tous les frameworks web basés sur .NET, y compris ASP.NET Web Forms, ont toujours eu une chose en commun : ils sont rendus via un serveur. Dans les applications web rendues via un serveur, le navigateur envoie une demande au serveur, qui exécute du code (code .NET dans les applications ASP.NET) pour produire une réponse. Cette réponse est renvoyée au navigateur pour qu’il la gère. Dans ce modèle, le navigateur est utilisé comme moteur de rendu dynamique. Une grande partie du travail consistant à produire l’interface utilisateur, exécuter la logique métier et gérer l’état se fait sur le serveur.

Toutefois, les navigateurs sont devenus des plateformes polyvalentes. Ils implémentent un nombre toujours croissant de normes web ouvertes qui accordent l’accès aux fonctionnalités de l’ordinateur de l’utilisateur. Pourquoi ne pas tirer parti de la puissance de calcul, du stockage, de la mémoire et autres ressources de l’appareil client ? Les interactions avec l’interface utilisateur en particulier peuvent bénéficier d’une expérience plus riche et plus interactive lorsqu’elles sont gérées au moins partiellement ou complètement côté client. La logique et les données qui doivent être gérées sur le serveur peuvent toujours être gérées côté serveur. Les appels d’API web ou même les protocoles en temps réel, tels que WebSockets, peuvent être utilisés. Les développeurs web peuvent disposer gratuitement de ces avantages s’ils sont prêts à écrire en JavaScript. Les frameworks d’interface utilisateur côté client, comme Angular, React et Vue, simplifient le développement web côté client et ont gagné en popularité. Les développeurs ASP.NET Web Forms peuvent également tirer parti du client et même bénéficier d’un support immédiat avec des frameworks JavaScript intégrés comme ASP.NET AJAX.

Mais le pontage de deux plateformes et écosystèmes différents (.NET et JavaScript) a un coût. Une maîtrise de deux mondes parallèles avec différents langages, frameworks et outils est requise. Le code et la logique ne peuvent pas être facilement partagés entre le client et le serveur, ce qui entraîne des duplications et une surcharge en ingénierie. Il peut également être difficile de suivre l’écosystème JavaScript, qui a l’habitude d’évoluer à une vitesse vertigineuse. Les préférences en matière de framework front-end et d’outil de build changent vite. Le secteur a observé la progression de Grunt à Gulp, puis à Webpack, et ce n’est pas fini. La même évolution effrénée s’est produite avec les frameworks front-ends comme jQuery, Knockout, Angular, React et Vue. Mais, au vu du monopole du navigateur JavaScript, le choix était très mince. Enfin, jusqu’à ce que la communauté web se réunisse et produise un miracle !

WebAssembly répond à un besoin

En 2015, les principaux fournisseurs de navigateurs ont uni leurs forces dans un groupe de la communauté W3C pour créer une norme web ouverte appelée WebAssembly. WebAssembly est un code d’octet pour le web. Si vous pouvez compiler votre code sur WebAssembly, celui-ci peut ensuite s’exécuter sur n’importe quel navigateur sur n’importe quelle plateforme à une vitesse quasi native. Les premiers efforts se sont concentrés sur C/C++. Le résultat était une démonstration spectaculaire de l’exécution de moteurs graphiques 3D natifs directement dans le navigateur sans plug-ins. WebAssembly a depuis été standardisé et implémenté par tous les principaux navigateurs.

Des travaux sur l’exécution de .NET sur WebAssembly ont été annoncés fin 2017 et publiés en 2020, avec prise en charge dans .NET 5 et ultérieur. La capacité à exécuter du code .NET directement dans le navigateur permet le développement web full-stack avec .NET.

Blazor : développement web full-stack avec .NET

La capacité seule à exécuter du code .NET dans un navigateur ne fournit pas une expérience de bout en bout pour créer des applications web côté client. C’est là où Blazor entre en jeu. Blazor est un framework d’interface utilisateur web côté client basé sur C# au lieu de JavaScript. Blazor peut s’exécuter directement dans le navigateur via WebAssembly. Aucun plug-in de navigateur n’est requis. Les applications Blazor peuvent aussi s’exécuter côté serveur sur .NET et gérer toutes les interactions utilisateur sur une connexion en temps réel avec le navigateur.

Blazor offre une excellente prise en charge des outils dans Visual Studio et Visual Studio Code. Le framework comprend également un modèle de composant IU complet et dispose de fonctionnalités intégrées pour :

• Formulaires et validation
• Injection de dépendances
• Routage côté client
• Dispositions
• Débogage dans le navigateur
• Interopérabilité JavaScript

Blazora beaucoup en commun avec ASP.NET Web Forms. Les deux frameworks offrent des modèles de programmation IU avec état qui sont basés sur des composants et pilotés par des événements. La principale différence architecturale est qu’ASP.NET Web Forms s’exécute uniquement sur le serveur. Blazor peut s’exécuter sur le client dans le navigateur. Mais si vous venez d’ASP.NET Web Forms, beaucoup d’aspects vous sembleront familiers dans Blazor. Blazor est une solution naturelle pour les développeurs ASP.NET Web Forms qui cherchent un moyen de tirer parti du développement côté client et du futur multiplateforme open source de .NET.

Ce livre fournit une présentation de Blazor qui s’adresse spécialement aux développeurs ASP.NET Web Forms. Chaque concept Blazor est présenté dans le contexte de fonctionnalités et pratiques ASP.NET Web Forms analogues. À la fin de ce livre, vous aurez compris :

• Comment créer des applications Blazor.
• Comment fonctionne Blazor.
• Comment Blazor est lié à .NET.
• Les stratégies raisonnables pour migrer des applications ASP.NET Web Forms existantes vers Blazor quand elles sont appropriées.

Commencer à utiliser Blazor

Il est facile de commencer à utiliser Blazor. Accédez à https://blazor.net et suivez les liens pour installer le SDK .NET et les modèles de projet Blazor appropriés. Vous trouverez également des instructions pour configurer les outils Blazor dans Visual Studio ou Visual Studio Code.