Comprendre le positionnement de Blazor

Backend, Frontend, FullStack

Software is eating the world, et le “web is eating software” depuis quelques années maintenant.

Cette omniprésence du web s’accompagne d’un nombre d’évolutions croissant et différents changements d’architectures.

D’un monde orienté quasi intégralement côté backend, où la consommation des données et la génération de l’UI (les vues) se faisait côté serveur. Nous nous sommes orientés vers un monde orienté services, où pour des raisons d’ergonomie et de vitesse de plus en plus de responsabilités sont déportées côté client.

Le schisme entre le backend et le frontend

Ainsi les vues, et la consommation de données exposées par des services se font le plus souvent côté client.

Pour accompagner ce transfert de responsabilité tout un tas de nouvelles libraires, frameworks et outils sont arrivés : jQuery, AngularJS, Angular, Vue, React, npm, bower, gulp, webpack, etc.

image

L’unification technologique que l’on pouvait avoir côté serveur, se complète d’une multitude de nouvelles technologies côté client.

Les développeurs doivent donc maitriser des technologies et langages très différents entre le côté backend et le côté frontend, pour avoir le profil fullstack ci-souvent souhaité.

Illustration dans le monde Microsoft

Dans l’écosystème Microsoft, cette séparation entre le front et le back peut être illustré par l’évolution d’ASP.net.

Au tout début de .net, l’essentiel des développeurs Microsoft étant des développeurs Windows, l’éditeur proposa une technologie de développement web adaptée : ASP.net Webforms. Reproduisant presque à l’identique le modèle de développement Windows, la technologie de développement web était la solution idéale pour inciter ce public à passer au web. Comme beaucoup de technologies de l’époque, les projets ASP.net webforms se concentraient quasi-exclusivement côté serveur. A l’arrivée d’Ajax, Microsoft continua sur cette lancée en proposant ASP.net Ajax et un toolkit associé permettant de bénéficier du développement côté client… sans faire de développement client ! Merci l’update panel et consors !

Afin de proposer un réel modèle de développement Web, ASP.net MVC fut ensuite proposé avec une intégration native de différentes technologies frontend. Le javascript et son écosystème prenant une place prépondérante au sein de ce type d’applications.

Incompréhensions, antipatterns

Nombre d’incompréhensions et d’antipatterns sont issus de toutes ces évolutions et de cette séparation entre le frontend et le backend :

  • L’incompréhension de la différence entre une librairie et un framework. Non, AngularJS n’est pas la suite logique de JQuery, utiliser un framework n’est pas anodin. C’est un choix technique majeur, qui définit un couplage très fort vers une certaine technologie
  • La non-compréhension que la plupart des frameworks frontend, sont des framework SPA, qui n’ont pas été conçus à la base pour être intégrés dans des sites web « classiques » multi-page. Ce n’est pas pour rien si ces frameworks proposent un grand nombre de fonctionnalités qui font doublon avec les frameworks serveurs traditionnels (vue, binding, routing, etc.)
  • Une incompréhension sur l’utilisation de ces frameworks dans des applications multi-page. Oui il peut être pratique d’utiliser des vues côté client pour afficher des données issues de services web, mais il faut être très clair sur la séparation des responsabilités.

Des décisions compliquées

Impact de cette explosion de technologies, et de changements de frameworks à la mode :

  • Il est compliqué de faire les bons choix techniques et d’assurer une bonne pérennité de ses applications
  • Dans un monde agile où l’on recherche le plus souvent des développeurs polyvalents « fullstack », le volume de compétences à avoir pour être « fullstack » est très (trop) important. Les développeurs peuvent avoir tendance à privilégier le côté back, ou le côté front en fonction de leurs intérêts.

Nombre de développeurs ne semblent pas trop effrayés par toutes ces évolutions du web, et s’intéressent à toutes les nouvelles technos à la mode.

Mais d’autres refusent cet écosystème à l’évolution archaïque et anarchique, en prenant une solution qui peut sembler radicale et vieux-jeu mais qui est tout à fait pertinente si l’on privilégie la pérennité.

VanillaJS

Le no-framework côté frontend qui consiste à n’utiliser qu’une librairie comme jQuery, soit aucune librairie tout court prend petit à petit de l’importance. Préconisé/formalisé par le mouvement Vanilla JS, ce type de décision ne doit pas être vu comme rétrograde, mais comme raisonnable pour ceux qui souhaitent privilégier la pérennité des développements.

Car oui, il n’est pas indispensable ni obligatoire d’utiliser Angular, React, Vue, ou autre framework pour développer une application web ! Tout dépend des besoins, et des critères des choix des technologies, du curseur que l’on place entre la spécialisation/complexité de l’implémentation proposée, et la pérennité de la solution finale.

Une première solution pour éviter cette séparation entre le front et le back, est d’utiliser le même langage des deux côtés : Javascript.

Blazor : ASP.net MVC FullStack

Blazor est une autre piste permettant de ne pas subir cette séparation. Blazor est pour le moment uniquement une « simple » expérience gérée par l’équipe ASP.net et non pas un produit final.

L’idée est assez simple, proposer un socle technologie simple permettant de créer des pages web en capitalisant sur ses compétences .net.

Avoir comme unique solution d’utiliser le langage javascript côté client et côté serveur serait un risque pour Microsoft de perdre toute pertinence dans le monde de développement web (à l’exception notable de TypeScript).

Microsoft propose donc avec Blazor de capitaliser ses compétences .net, en utilisant le langage C# et le moteur de vue Razor côté backend comme actuellement, mais surtout à présent également du côté frontend.

Une technologie qui pourrait être la solution idéale pour éviter le javascript « madness » et ne plus avoir besoin de se baser essentiellement sur cet écosystème.

Le tout en respectant bien évidemment les standards du web grâce à l’utilisation de WebAssembly et asm.js.

L’exécution de code C# côté client au sein d’un navigateur est rendu possible grâce à une implémentation du runtime .net en WebAssembly développée par l’équipe Xamarin.

Pour les anciens navigateurs qui ne supportent pas WebAssembly, asm.js est utilisé comme fallback afin d’être exécuté de manière universelle.

Comme il n’est pas utile de répéter ce qui est déjà présent online, vous pouvez en savoir plus d’un point de vue technique via ce post : https://blogs.msdn.microsoft.com/webdev/2018/03/22/get-started-building-net-web-apps-in-the-browser-with-blazor/

Un positionnement osé ?

Inutile de le repréciser cette technologie s’adresse avant tout aux développeurs .net, en proposant une alternative à javascript.

Bien que reposant sur les standards, proposer une alternative à javascript est plutôt osé. En proposant une solution rassurante et uniquement adaptée à sa population de développeurs .net, Microsoft risque de donner de nouveau une image d’éditeur qui ne s’intègre pas à l’écosystème actuel en proposant ses propres solutions. Cela devrait néammoins être atténué par l’approche du « nouveau » Microsoft : le projet est open-source sur github, et respecte les standards.

Mais comme souvent, cette nouvelle solution n’est pas exclusive mais complémentaire. Il ne faut pas voir Blazor comme étant une solution remplaçant ASP.net MVC mais comme une solution complémentaire à ASP.net MVC.

Pour caricaturer un petit peu, si vous êtes dans une startup ou chez un éditeur de logiciels qui privilégie l’utilisation des dernières technos pour satisfaire à de nouveaux besoins, vous pouvez utiliser ASP.net MVC « classique » et tout l’écosystème javascript. Si vous travaillez pour un éditeur ou une entreprise en interne, où la pérennité des développements est essentielle et où le coût d’utilisation de l’écosystème Javascript et le coût de la gestion de ces compétences n’est pas acceptée ou souhaitable, vous pourrez potentiellement vous orienter vers Blazor.

Laisser un commentaire

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