Ce dont Blazor a besoin: un écosystème

La prédiction est difficile, surtout avec Blazor. Si vous essayez de décider si Blazor décollera, alors ne regardez pas les spécifications techniques: regardez l'écosystème qui grandit autour de lui. C'est ce qui s'est produit avec d'autres frameworks côté client réussis comme Angular, React et Vue.js.

Si vous essayez de décider si Blazor va décoller en tant qu'outil de développement côté client, vous devriez regarder l'historique, pas la fonctionnalité, des frameworks comme React, Vue.js et Angular.

Deux fois la semaine dernière, j'ai eu des clients qui comparent Blazor à la technologie précédente de Microsoft qui supportait également l'exécution de code / bibliothèques côté serveur dans le navigateur: Silverlight . Je pense que c'est comme comparer des pommes et des orangs-outans. La comparaison correcte pour Blazor est l'un des cadres côté client JavaScript, comme React, Angular ou Vue.js. La comparaison de Blazor à ces jeux d'outils réussis a également l'avantage de mettre en évidence ce dont Blazor a besoin pour réussir.

Le facteur de succès critique pour Blazor n'est pas un problème technique comme Ahead of Time compiler ou réduire la taille de la téléchargement initial. Il y a, je parie, plusieurs solutions intelligentes à ces problèmes (et au moins une organisation open source pense qu’elle l’a déjà résolu). La sophistication technique n'est pas ce qui a fait de Vue.js ou Angular ou React des plates-formes réussies.

Blazor n'est pas Silverlight

Tout d'abord, discutons du sujet "Pourquoi Blazor n'est pas Silverlight". Oui, comme Blazor, Silverlight était un outil multiplateforme qui fonctionnerait avec n'importe quel navigateur. Mais Silverlight (comme Adobe Flash) était un package distinct du navigateur. Bien que vous puissiez télécharger Silverlight à l'aide d'un navigateur, il serait plus exact de dire que Silverlight s'exécute «dans la fenêtre du navigateur» plutôt que «dans le navigateur». Vraiment, une fois que Silverlight a commencé à s'exécuter, cela n'avait plus grand-chose à voir avec le navigateur.

Et, dès qu'une plateforme majeure ( iPad ) a refusé de télécharger Silverlight, Silverlight a cessé d'être un outil multiplateforme (sa principale raison d'exister). Par la suite, Silverlight a suivi une trajectoire similaire, bien que plus nette, vers l'oubli comme Adobe Flash. Et les fournisseurs de navigateurs pouvaient rejeter sélectivement Flash et Silverlight sans compromettre la position de leur produit en tant que «bon navigateur».

Blazor, d'autre part, exploite une norme HTML5: WebAssembly. Refuser Blazor nécessite qu'un fournisseur de navigateur cesse d'être compatible HTML5… et ne pas être compatible fait un mauvais navigateur. Blazor tire parti des fonctionnalités du navigateur natif de la même manière que Vue.js ou React ou Angular tirent tous parti de la prise en charge de JavaScript par le navigateur (et aucun fournisseur de navigateur ne désactivera JavaScript). De plus, Blazor n'est pas le seul outil basé sur WebAssembly dans l'univers (voici une liste de plus de 180 projets open source qui dépendent de WebAssembly). Si un fournisseur de navigateur désactive WebAssembly, il désactive tous ces projets pour les utilisateurs du navigateur.

Il existe d'autres raisons pour lesquelles une comparaison Blazor à Angular / React / Vue.js est appropriée. En regardant Blazor avec sa prise en charge des composants, la création d'interfaces utilisateur par composition et le routage entre les composants au sein d'une seule page, il est évident que l'équipe Blazor a les mêmes paradigmes en tête que les frameworks JavaScript. Actuellement, en termes de fonctionnalités natives, Blazor correspond à la fonctionnalité de ces cadres ou est très proche (si, sur la base de votre expérience React / Angular / Vue.js, vous êtes sur le point de hurler de colère à cette affirmation, supportez-moi pendant une minute et rappelez-vous que j'ai dit la fonctionnalité "native").

Alors maintenant, pour la discussion principale: "Qu'est-ce qui est nécessaire pour que Blazor soit en concurrence avec Vue.js, Angular ou React?"

Permettez-moi de commencer par un expérience personnelle: j'ai récemment terminé d'écrire un cours sur React pour Learning Tree International. L'un des défis de la rédaction d'un cours React est de gérer tout ce que React ne fait pas. React ne dispose pas, par exemple, d'un mécanisme intégré pour effectuer des appels de service Web comme la méthode ajax de jQuery (vous pouvez vous rabattre sur l'objet XMLHttpRequest de JavaScript… mais qui le veut?). Il n'y a pas non plus de prise en charge pour un magasin centralisé qui partage des données entre tous les composants d'une application, ce qui est essentiel dans toute grande application.

Mais, bien sûr, vous pouvez faire ces deux choses avec React – il vous suffit de choisir le bon complément React. Et, pour ces deux exemples, il existe plusieurs packages concurrents … ce qui a créé le problème lorsque j'ai écrit mon cours: quel complément dois-je utiliser dans le cours pour gérer l'état partagé (vanilla Flux? Redux? Mbot? Relay?) ou pour effectuer des appels de service Web (Axios? isomorphic-fetch? what-wg.fetch?)?

Et ce n'est que la pointe de l'iceberg proverbial: une recherche rapide sur Google vous donnera une page qui répertorie 20 outils de développement React dans une variété de catégories. Et ce ne sont que les «20 meilleurs outils» selon un auteur – il y en a bien plus.

Mais, malgré tout le chagrin que cette richesse me donne quand je porte mon chapeau d'auteur de cours, c'est une aubaine pour moi quand je mettre mon chapeau de développeur: je peux choisir l'outil qui répond le mieux aux besoins de mon application ou de mon client. L'écosystème qui existe autour de React est ce qui fait de React (et des autres plates-formes côté client performantes) un excellent choix de développement.

Mais les outils ne sont qu'une partie de l'écosystème d'une technologie. En tant que personne qui croit fermement que la véritable définition de «programmation» est «Googling Stack Overflow», l'autre partie critique d'un écosystème est l'expertise disponible.

Poursuivant avec React comme exemple, Amazon répertorie (littéralement) des centaines de titres consacrés à React, allant de la couverture soupe-aux-noix de l'outil, à des guides sur les meilleures pratiques, à des titres qui explorent en détail React add- ins. En ligne, il existe un univers de blogs (voici 10 juste pour les débutants). Et il est très difficile de trouver une question liée à React à laquelle on n'a pas encore répondu sur Stack Overflow (le ciel sait que j'ai essayé). Vous obtiendrez les mêmes résultats avec Vue.js ou Angular.

L'expertise ne s'arrête cependant pas aux gourous. La mise en œuvre d'applications utilisant n'importe quelle technologie nécessite des personnes. En tant qu'ex-chef d'un service informatique, je ne m'intéresse à une technologie que lorsqu'il y a beaucoup de consultants, d'entrepreneurs et de nouvelles recrues potentielles disponibles à un coût que je peux me permettre. Je préfère utiliser une technologie qui a beaucoup de gens à un prix raisonnable disponible qu'une technologie techniquement «supérieure» qui nécessite des ninjas à prix élevé qui, probablement, ne sont pas à ma disposition de toute façon.

The Blazor Ecosystem

En tant qu'outil qui n'a vraiment qu'un an, Blazor ne peut évidemment pas avoir le genre de ressources que Vue.js ou React (tous deux âgés de six ans) ou Angular (trois ans dans sa version actuelle, dix ans si vous comptez son existence précédente comme AngularJS). Mais, parce que Blazor exploite .NET Core et le langage C #, une grande partie de l'expertise requise pour utiliser Blazor est déjà en place: si vous connaissez .NET Core, vous savez une grande partie de ce qui compte dans Blazor.

Je suggérerais également qu'une grande partie des connaissances conceptuelles requises par Blazor (composition utilisant des composants, routage à l'intérieur d'une page) est déjà connue par React, Vue.js et les développeurs Angular: les détails changent mais la chanson reste la même . Un développeur .NET qui travaille avec l'un de ces cadres côté client possède déjà une grande partie de l'expertise nécessaire pour créer des applications Blazor.

Ce qui signifie que ce qui manque actuellement à Blazor, c'est cet écosystème d'outils.

Ici, comme pour toute nouvelle technologie, Blazor peut souffrir du «problème du pain d'épice»: il ne peut pas courir tant qu'il n'a pas chaud et il ne peut pas avoir chaud avant de courir. Un écosystème d'outils se développe là où il y a beaucoup de développeurs qui étendent la plateforme principale, mais «beaucoup de développeurs» ne sont attirés que par les plateformes où il y a un écosystème riche.

Pourtant, cela se produit: En termes d'intérêt / sensibilisation / satisfaction des développeurs, Vue.js et React ont, au cours des cinq dernières années, supplanté Angular en tant qu'outils les mieux cotés. Vraisemblablement, la même chose pourrait arriver avec Blazor.

Et une partie de cela se produit déjà. Les fournisseurs (comme Progress avec Telerik ) fournissent des suites de contrôles d'interface utilisateur comparables aux suites disponibles sur d'autres plates-formes. Initialement, une grande partie de la communauté des développeurs open-source s'est concentrée sur la fourniture à Blazor de fonctionnalités natives des frameworks JavaScript (c'est-à-dire l'accès aux API HTML5, comme la géolocalisation). Mais cela change à mesure que la communauté ajoute de nouvelles fonctionnalités (il existe déjà un package Blazor qui fournit des fonctionnalités équivalentes à Redux ).

La vraie question est donc: "Comment se développe l'écosystème d'outils pour Blazor?" Gardez un œil sur cette croissance. Si cet écosystème d'outils se développe de la même manière que pour Angular, React ou Vue.js, alors vous devriez vous attendre à voir Blazor se frayer un chemin dans cette foule. Et si ce n'est pas … eh bien, Blazor est toujours une technologie intéressante.

Et pas comme Silverlight. Du tout.