Fermer

octobre 25, 2018

Blazor Q & A avec Daniel Roth de Microsoft


Vous voulez en savoir plus sur le passé, le présent et l'avenir de Blazor? Nous avons rencontré Daniel Roth de Microsoft pour connaître son opinion.

L’équipe de Progress Telerik est très enthousiaste à propos de Blazor depuis qu’il a été annoncé qu’il s’agissait d’un projet expérimental. Ed Charbeneau a écrit un certain nombre de billets de blog à ce sujet (vous pouvez les trouver ici ici ) et nos équipes de produits et d'ingénieurs l'ont expérimenté.

Nous vous avons tous dit que cela vous intéressait. nous avons également pensé rencontrer virtuellement Daniel Roth, directeur principal de programme chez Microsoft, responsable de Blazor, pour en savoir plus sur le passé, le présent et l'avenir du projet.

Voici un récapitulatif des activités de ce projet. notre conversation.

Sara (SF): Nous sommes ravis d'entendre parler de Blazor et de vous faire part de vos réflexions avec les développeurs. Merci de prendre le temps. Pourquoi ne commençons-nous pas au début. Parlez-nous un peu de la création de Blazor.

Daniel Roth (DR): Bien sûr. Merci pour cette opportunité.

L'équipe .NET souhaitait depuis longtemps améliorer l'expérience client des développeurs Web .NET, mais comme les navigateurs ne prenaient auparavant en charge que JavaScript, nous ne pouvions rien faire d'autre que d'ajouter un autre cadre JavaScript dans l'écosystème déjà encombré. Tout cela a changé lorsque le groupe de la communauté WebAssembly a annoncé qu'il était parvenu à un consensus entre les navigateurs, ce qui a ouvert la voie à d'autres plates-formes pour s'exécuter dans le navigateur. Même à ce moment-là, personne ne savait vraiment s'il était logique d'essayer de prendre en charge .NET sur WebAssembly jusqu'à ce que Steve Sanderson construise le premier prototype Blazor en tant que démonstration pour sa présentation NDC Oslo 2017 sur les nouvelles fonctionnalités du navigateur. L’expérience de Steve de créer des applications Web côté client tout en .NET était si astucieuse qu’elle a ouvert les yeux à beaucoup de gens sur ce qui est désormais possible.

SF: Très cool. Je n'avais pas réalisé que c'était à NDC Oslo qu'il avait montré la démo. Je vais devoir y retourner et regarder ça. Selon vous, que propose JavaScript et TypeScript sur WebAssembly?

DR: Pour la plupart des types d’application (mobile, poste de travail, serveur, périphériques, etc.), vous disposez d’un riche écosystème de langages, frameworks et outils que vous pouvez utiliser en tant que développeur. La grande exception est le navigateur. Historiquement, les navigateurs ne prenaient en charge que l’utilisation de JavaScript. WebAssembly change réellement ce système pour offrir aux développeurs Web un écosystème de développeurs beaucoup plus vaste. Si vous pouvez compiler votre code dans WebAssembly, il peut alors s'exécuter dans n'importe quel navigateur moderne et à la vitesse du processeur.

SF: Cela semble tout à fait logique. Qui ne voudrait pas ce genre de performance et de vitesse? Alors, pourquoi Blazor est-il considéré comme "expérimental?"

DR: Blazor a commencé comme un projet expérimental, car nous ne savions pas si tout allait bien fonctionner avec .NET dans le navigateur WebAssembly. Nous avons beaucoup appris depuis le début de l'expérience et Blazor soutient désormais une communauté enthousiaste . Il reste encore des défis techniques à résoudre, tels que performances, débogage et taille de téléchargement, mais nous sommes convaincus que nous pouvons tous les résoudre.Nous avons déjà décidé de procéder à la production du modèle de composant Blazor UI dans .NET Core 3.0 afin qu'il puisse être exécuté côté serveur avec ASP .NET Core: le support de WebAssembly nécessitera toutefois un peu plus de temps.

SF: Pouvez-vous expliquer un peu plus la production du modèle de composant d'interface utilisateur Blazor dans .NET Core 3.0? Blazor no plus "expérimental?"

DR: Blazor est réellement composé de deux parties: une infrastructure d’interface utilisateur basée sur des composants et un environnement d’exécution .NET basé sur WebAssembly. L'exécution de Blazor sur le serveur signifie que les composants s'exécutent sur le serveur sous .NET Core alors que l'interface utilisateur est gérée via une connexion SignalR. Vous écrivez votre code en utilisant .NET et vous obtenez toujours la sensation interactive riche d'une application basée sur un navigateur. Le modèle Blazor côté serveur ne dépendant pas de WebAssembly, nous avons décidé de procéder à la production de la partie de l'infrastructure d'interface utilisateur de Blazor dans .NET Core 3.0. Nous intégrons le modèle de composant Blazor à ASP.NET Core, ce que nous appelons maintenant Razor Components. Dans le même temps, nous continuons à travailler sur le support WebAssembly côté client, qui restera expérimental encore un moment. L’important est que nous conservions le même modèle de composant que vous utilisiez le serveur ou le navigateur. Les mêmes composants peuvent être utilisés sur le serveur ou dans le navigateur, à condition qu'ils aient été implémentés avec les abstractions appropriées.

SF: Nice. D'ACCORD. Les composants Razor sont donc des composants d’interface utilisateur Web dynamiques qui prennent en charge un modèle d’hébergement flexible?

DR: Exactement. Vous pouvez héberger des composants Razor dans une application ASP.NET Core (par exemple, en tant que page routable ou depuis une page Razor ou une vue MVC) ou les héberger directement dans le navigateur via WebAssembly. Là encore, il s’agit de la production du modèle de composant Blazor dans ASP.NET Core.

SF: Les assemblages .NET existants (antérieurs à Blazor) sont-ils compatibles avec Blazor?

DR: Avec Blazor exécuter des assemblys .NET ordinaires dans le navigateur. Blazor prend en charge .NET Standard, qui est une zone de surface d’API normalisée pour toutes les différentes versions de .NET (postes de travail, centraux, mobiles). La prise en charge de .NET Standard dans Blazor est limitée en raison du sandbox du navigateur. Par exemple, vous ne pouvez pas ouvrir de fichiers arbitraires sur le système de fichiers ni établir de connexions réseau arbitraires, tout comme vous ne pouvez pas utiliser JavaScript. Mais dans la plupart des cas, les bibliothèques .NET Standard devraient «fonctionner».

SF: Depuis que Blazor exécute .NET dans le navigateur, les outils de développement Edge / Chrome peuvent-ils être utilisés pour casser / déboguer le côté client code?

DR: Nous disposons actuellement d’un support très précoce pour le débogage des applications Blazor directement dans le navigateur Chrome. Cela fonctionne normalement: nous fournissons un service proxy de débogage qui complète le protocole de débogage de Chrome avec un contexte spécifique .NET. Vous pouvez ensuite utiliser les outils de développement du navigateur pour vous connecter à distance à l'instance de navigateur que vous souhaitez déboguer via le proxy de débogage. Cela nécessite quelques étapes manuelles pour la configuration aujourd'hui, mais à l'avenir, nous prévoyons de fournir une expérience en matière d'outil permettant le débogage du navigateur, comme lorsque vous appuyez sur F5 dans Visual Studio. Nous n’avons pas encore implémenté le débogage dans Edge, mais ce serait une configuration similaire. La bonne chose à propos de cette configuration est qu’en plus du débogage de votre code .NET, vous pouvez également accéder à n’importe quel code JavaScript que vous pourriez utiliser via JavaScript interop. Il reste encore beaucoup de travail à faire pour que l'expérience ressemble réellement à une expérience de débogage .NET normale, mais c'est un problème sur lequel nous travaillons.

Vous pouvez également héberger votre application côté serveur Blazor, puis Le débogage .NET normal fonctionne comme pour n'importe quelle application .NET existante. De nombreux utilisateurs de Blazor nous disent qu'ils utilisent le modèle côté serveur pendant le développement afin de pouvoir déboguer avec l'intention d'exécuter ultérieurement l'application côté client sur WebAssembly. C'est un autre bon exemple des avantages d'un modèle d'hébergement flexible.

SF: Le framework Blazor peut-il être utilisé pour créer des applications de bureau?

DR: L'objectif principal de Blazor est la création d'applications Web. , mais nous avons essayé d’utiliser Blazor avec Electron pour créer des applications de bureau multiplates-formes. Nous avons créé un prototype utilisant Blazor dans un processus .NET Core pour gérer l'interface utilisateur d'une application Electron sur un canal IPC, et cela a bien fonctionné. Vous pouvez trouver un exemple en utilisant ce modèle sur notre page de communauté Blazor. C’est toujours un prototype et nous ne savons pas pour le moment si c’est une direction à suivre.

SF: Vous avez déjà mentionné la communauté Blazor à plusieurs reprises. Parlez-moi un peu plus à ce sujet.

DR: La communauté Blazor est l’une de mes parties préférées de mon travail sur le projet Blazor. Ils sont un groupe passionné et utile! De nombreux projets de communauté ont vu le jour autour de Blazor pour fournir des bibliothèques de composants, des bibliothèques d'assistance, des bibliothèques d'interopérabilité JavaScript, des outils et de nombreux exemples d'applications amusantes. Nous faisons de notre mieux pour partager ces projets sur la Blazor community page . Le forum de discussion Blazor Gitter est également un lieu de rencontre idéal si vous avez une question à propos de Blazor ou si vous souhaitez simplement discuter de l'avenir du développement Web avec .NET.

SF: Quels types de projets et applications ont-ils créé?

DR: La communauté Blazor a développé avec enthousiasme une variété d’échantillons d’applications amusantes utilisant Blazor. Ils ont construit des éditeurs Markdown, des listes de tâches, des calculatrices, des clones Twitter, des applications de discussion en ligne et tout un ensemble de jeux simples, tels que Asteroids, Tetris, etc. Vous pouvez trouver ces applications sur la page de notre communauté Blazor.

Nous rencontrons également régulièrement les clients internes et externes de Microsoft qui testent Blazor pour des scénarios de production potentiels. Un scénario intéressant est le site Try.NET . Try.NET vous permet d'écrire du code .NET dans un navigateur, puis de l'exécuter. Actuellement, Try.NET compile et exécute votre code sur le serveur, mais ils étudient la possibilité d'utiliser Blazor pour construire et exécuter votre code directement dans le navigateur.

SF: Maintenant, quelques questions personnelles: -). Quel est votre truc préféré à propos de Blazor?

DR: Mon truc préféré à propos de Blazor est de pouvoir créer des applications Web en utilisant mon langage "natif" pour écrire du code. Je peux utiliser les outils, les langages et les bibliothèques avec lesquels je suis familier, ce qui me rend plus productif. Ce n’est pas que je n’aime pas le JavaScript; la communauté JavaScript a fait des choses phénoménales. Mais travailler avec .NET et C # est ce avec quoi je suis le plus à l’aise et le plus productif. J'aime aussi beaucoup le fait que développer avec une seule plateforme me permette de partager et de réutiliser du code. inutile de réimplanter deux fois des éléments dans une plate-forme complètement différente.

En même temps, je pense que Blazor a beaucoup à offrir, même si vous n'êtes pas déjà familiarisé avec .NET. Blazor vous offre un modèle de composant d'interface utilisateur simple et intuitif, doté d'un excellent outillage, basé sur .NET, une plate-forme stable et mature. J'aime beaucoup la façon dont Blazor m'aide à démarrer rapidement et me permet de me concentrer sur la création de mon application. Lorsque vous combinez Blazor avec un backend ASP.NET Core rapide et sécurisé, je pense que vous avez une solution gagnante.

SF: Il est très difficile de discuter de cela. Une dernière question … En regardant dans le Magic 8 Ball, quel est l'avenir du Blazor?

DR: “Outlook good” ?. À court terme, le modèle de composant Blazor, ou Composants Razor, deviendra une partie intégrante de la façon dont vous écrivez une interface utilisateur Web avec ASP.NET Core, vous permettant d'écrire de riches applications Web interactives sans avoir à écrire beaucoup de JavaScript. À l'avenir, j'espère que .NET rejoindra un écosystème de développeurs riche en langages et outils pouvant être utilisés pour le développement Web côté client, ce qui rendra la création d'applications Web plus simple et plus productive qu'auparavant.

SF: Merci beaucoup pour votre temps et votre perspicacité, Daniel. Nous sommes impatients de voir ce que l'avenir nous réserve!




Source link