Aspnetcore: Séparez l'expérience .NET Core à WASM de Blazor

Salut @EisenbergEffect ! Le travail de base de WebAssembly est actuellement géré par l'équipe Mono. Nous construisons Blazor au-dessus de ce qu'ils fournissent. D'autres membres de la communauté .NET sont également libres de le faire et plusieurs le sont déjà ( Ooui , Uno , cshtml5 ). Vous pouvez suivre les progrès de mono.wasm dans le dépôt Mono .

Je ne suis vraiment pas intéressé par la compilation de Mono en WebAssembly. Je ne m'intéresse qu'à .NET Core. Ce que je demande c'est quelque chose comme ça :

• Utilisez l'interface de ligne de commande .NET pour créer un projet .NET Core C#.
• Utilisez le .NET CLI pour compiler mon projet .NET Core vers WASM, avec les 3 sorties décrites ci-dessus.

@ danroth27 Est-ce pris en charge aujourd'hui ?

Les gens de Mono travaillent également sur une compilation complète à l'avance (AoT) du code .NET vers WebAssembly avec le kit de développement logiciel MSBuild. La dernière mise à jour qu'ils ont publiée sur l'effort était http://www.mono-project.com/news/2018/01/16/mono-static-webassembly-compilation/. @mhutch est probablement le meilleur contact pour obtenir le dernier statut.

Je ne suis pas intéressé par Mono. Je m'intéresse uniquement à .NET Core. Existe-t-il une histoire pour .NET Core WASM ?

Existe-t-il une histoire pour .NET Core WASM ?

Pas actuellement. .NET Core est principalement utilisé aujourd'hui pour les scénarios de serveur multiplateforme. Mono est l'environnement d'exécution .NET utilisé aujourd'hui pour les scénarios clients multiplateformes (Android, iOS, macOS, jeux). La plupart des scénarios WebAssembly d'aujourd'hui sont des scénarios clients, donc Mono est la solution la moins chère pour le moment. Avec le temps, il est raisonnable de s'attendre à une convergence, mais cela prendra un certain temps.

FWIW Je pense vraiment que cette question des temps d'exécution et des cibles de plate-forme doit être abordée en premier. Quand j'entends dire que je dois utiliser deux versions différentes de .NET pour créer une application... utilisez Mono pour votre client, puis utilisez .NET Core pour votre serveur... cela ne m'excite pas du tout. Je veux juste utiliser .NET Core et, franchement, oublier qu'il existe d'autres .NET. Un .NET s'il vous plaît :)

@EisenbergEffect du vue de la consommation, cela devrait être à peu près un détail d'implémentation dont le runtime exécute votre code.

Je ne suis pas d'accord. Jamais dans mon histoire d'ingénieur logiciel, je n'ai considéré quel temps d'exécution exécute mon code comme un détail d'implémentation que je peux ignorer.

@ danroth27 Juste quelques retours de mon équipe de développement, nous aimerions également voir Blazor utiliser éventuellement .NET Core. Nous ne sommes pas intéressés par Mono ou même le framework .NET complet. Nous voulons le même runtime sur le client et le serveur.

Nous ne sommes pas intéressés par Mono ou même le framework .NET complet. Nous voulons le même runtime sur le client et le serveur.

Eh bien, quoi que nous fassions, vous n'aurez pas exactement le même temps d'exécution sur le serveur et dans le navigateur : le moteur d'exécution du navigateur doit être basé sur WebAssembly, mais pas celui du serveur. Ce n'est pas sans rappeler à quel point l'exécution sur iOS est fondamentalement différente de l'exécution sur le serveur. Le facteur unificateur sur le client et le serveur est .NET Standard. Cela dit, je pense que nous partageons votre objectif de vouloir unifier sur une seule implémentation d'exécution. Cela n'a pas de sens pour Microsoft à long terme de posséder et de maintenir deux environnements d'exécution à deux fois le prix. Le travail de convergence est déjà en cours à bien des égards. De plus en plus de code dans Mono et .NET Core est partagé. Mais arriver à un seul runtime est toujours un effort majeur qui prendra un certain temps.

En attendant Blazor est une expérimentation et nous expérimentons ce qui peut fonctionner aujourd'hui 😃

@ danroth27 Merci pour l'excellente réponse, Dan !

Excellent tout à fait d'accord

Le mardi 15 mai 2018, à 10 h 54, paulost [email protected] a écrit :

@ danroth27 https://github.com/danroth27 Merci pour l'excellent
réponse, Dan !

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/aspnet/Blazor/issues/835#issuecomment-389046589 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/ACnwPz_cCiVg6iti9VR9pQWY34_Hibf4ks5tymapgaJpZM4T-jpA
.

@EisenbergEffect J'avais un point de vue similaire sur Mono, mais quand j'ai appris que depuis que Microsoft a acquis Xamarine, Mono est la technologie Microsoft... Et est optimisé pour les scénarios clients... Et je peux l'utiliser pour exécuter mon code ".net standard" à l'intérieur navigateur aujourd'hui... Toutes les préoccupations ont été balayées.

Pour récupérer les composants d'exécution du navigateur uniquement :
https://jenkins.mono-project.com/job/test-mono-mainline-wasm/label=ubuntu-1804-amd64/

... Maintenant, je reviens à la création de ma propre pile d'interface utilisateur basée sur XAML en C# ciblant WebGL

Pour être clair, il ne s'agit pas d'utiliser une technologie non Microsoft. Il s'agit de vouloir utiliser uniquement .NET Core. Je recherche un .NET open source et multiplateforme avec une interface de ligne de commande unifiée multiplateforme. Pas deux ou trois .NET ou plusieurs compilateurs. J'aurais pensé que de nouveaux efforts seraient concentrés sur .NET Core et l'unification, j'ai donc trouvé surprenant que WASM soit uniquement pour Mono et nécessite une chaîne d'outils différente.

Je demande personnellement l'unification de la plate-forme .NET depuis plus de 10 ans. Alors, pardonnez-moi si je suis un peu agité dans ce fil, car après 10 ans, j'ai toujours besoin de 3 .NET pour construire mes services et mes clients. Il y a très peu de choses pour lesquelles je suis prêt à attendre 10 ans. J'ai quitté .NET il y a plusieurs années et depuis décembre, j'y réfléchis pour voir si la situation s'est améliorée. Je suis plus qu'un peu découragé de constater que bon nombre des mêmes problèmes que j'ai laissés derrière moi persistent.

Je le dis en toute sincérité, je veux aimer à nouveau .NET. S'il vous plaît, prenez cela au sérieux.

Je le dis en toute sincérité, je veux aimer à nouveau .NET. S'il vous plaît, prenez cela au sérieux.

Nous prenons ce problème au sérieux et nous travaillons activement à la convergence des différents runtimes .NET. Mais cela prendra du temps, et nous pouvons très bien décider qu'à court terme, pour des raisons pratiques, il est logique de procéder avec Mono avec une feuille de route plus longue pour la convergence avec .NET Core.

J'ai encore besoin de 3 .NET pour construire mes services et clients

Je suppose que les trois .NET auxquels vous faites référence sont .NET Framework, .NET Core et Mono. La bonne nouvelle est que nous avons annoncé lors de BUILD que .NET Core 3 prendra en charge les applications de bureau Windows, ce qui, espérons-le, réduira le besoin d'un de ces environnements d'exécution et fournira une preuve supplémentaire que la convergence est notre objectif commun.

FWIW, Mono est déjà passé au compilateur Roslyn et au système de construction msbuild, ce n'est donc pas vraiment une chaîne d'outils différente. Vous pouvez créer des projets basés sur .Net Core et Mono dans une seule solution, avec le même système de génération et le même compilateur. Mono utilise également des parties importantes et de plus en plus nombreuses des bibliothèques de classes .NET Core.

WASM est une cible assez inhabituelle. Non seulement il n'est pas possible de compiler JIT, mais des choses comme les threads, les fichiers et les sockets ont des modèles très différents de la plupart des autres plates-formes. Mono possède de nombreuses technologies existantes développées pour les ports vers d'autres plates-formes inhabituelles/contraintes comme iOS, watchOS, PS4, etc. , backend bitcode LLVM et liaison gérée.

Je m'attends à ce que le type de projet WASM de Mono utilise des projets de style SDK, avec un SDK MSBuild fourni via NuGet, et utilisable à partir de dotnet .

Je pense que je sens une certaine haine de Mono ici, non ?
S'il vous plaît, ne soyez pas si prompt à vouloir jeter Mono. Vous vous souvenez quand Microsoft n'aimait pas Linux ? Mono était là pour les développeurs C#. Vous vous souvenez quand Microsoft n'aimait pas Mac OS ? Mono était de nouveau là. Maintenant, JavaScript mange nos déjeuners, devinez qui se présente ? Vous pariez que Mono est là pour sauver la situation, étant le premier .net complet à fonctionner sur Wasm. S'il vous plaît, montrez un peu de respect!

Écoutez, nous, les développeurs C# de ce côté, aimons Mono. Ils font un travail fantastique. Laissez Mono tranquille. Si cool kid .Net Core veut faire la fête, c'est bien aussi, MAIS MONO RESTE !

@humbersoft Si vous voulez une raison pour laquelle nous "détestons" Mono, je vous en donnerai une. Il voit des erreurs comme celle-ci dans la console de votre navigateur : « WASM : il aurait dû être installé dans le fichier `/Users/builder/jenkins/workspace/test-mono-mainline-webassembly/label/highsierra/sdks/out/wasm-interp/ lib/mono/4.5/mscorlib.dll' répertoire." Qui est jenkins ? Quel étrange message ! Un développeur Mono a évidemment codé en dur son chemin personnel dans le runtime.

@paulost Jenkins est un service de construction continue. Recherche le. C'est très populaire.

Merci @MisinformedDNA mais pourquoi Mono me dit-il qu'il devrait être installé dans ce chemin exact sur mon système ? Je n'essaie pas de créer Mono, mais seulement de l'utiliser pour exécuter une application Blazor. Un runtime expédié ne devrait pas vous parler de son chemin de service de build.

Je n'ai pas le contexte complet de l'erreur, mais je peux garantir que vous verrez des informations de débogage supplémentaires car Blazor n'est pas un produit expédié. Mono peut être livré, mais nous pouvons également utiliser des versions d'aperçu de Mono ou des bibliothèques d'aperçu construites au-dessus de Mono. Rappelez-vous, nous sommes encore dans la phase expérimentale.

Enfin, Xamarin fonctionne sur Mono, qui exécute probablement des milliers d'applications mobiles. C'est une technologie bien faite. Serait-il préférable d'avoir un runtime? Bien sûr. Mais .NET Framework est uniquement Windows et Mono a ensuite été créé en tant que port pour la compatibilité avec Linux et .NET Core a ensuite été créé pour une meilleure évolutivité dans le cloud. Pensez-vous vraiment que MS préfère gérer trois environnements d'exécution distincts ? Bien sûr que non. Mais tous les langages n'ont pas l'ampleur ou l'ambition de .NET. De plus, au cas où vous l'auriez manqué, MS porte WPF, WinForms et UWP vers .NET Core 3.0 . .NET Core est l'avenir, mais cela prendra du temps.

Oui, la prise en charge de Mono webassembly est en préversion et n'est encore livrée dans aucune version.

Dans ce cas particulier, le runtime tente de déterminer le répertoire d'assemblage du runtime (qui contient des fichiers tels que mscorlib.dll) en fonction de son emplacement actuel dans le système de fichiers, et le dernier recours est le chemin dans lequel le runtime a été compilé. Sur wasm, le concept d'"emplacement du système de fichiers" ne s'applique pas vraiment... Sur d'autres configurations intégrées similaires, le code d'intégration enregistre généralement un résolveur d'assemblage personnalisé (par exemple pour résoudre à partir d'un zip APK Android), et je suppose que ce n'est pas le cas. été mis en place ici encore.

@PaulOst
C'est le problème avec la vie à la pointe de la technologie, vous risquez de vous couper. Mono pour WASM en est à ses débuts et est très expérimental, mais il est plus complet que le DotNet Anywhere sur lequel Blazor était basé à l'origine. Ce n'est pas encore fini à coup sûr, donc des erreurs comme celle que vous rencontrez sont à prévoir.

Certains développeurs aiment les morceaux chauds, certains attendent plutôt que tout soit cool et calme. Ce sont des morceaux chauds, vous devez peut-être ajuster un peu vos attentes. Je comprends la perspective cependant, vous voulez un produit poli. Pouvez-vous imaginer attendre que .NET Core cible Wasm ? Ils peuvent ne pas y accéder avant 3 ans. Mono est un produit solide et c'est une chance que Microsoft les ait, sinon, nous n'aurions pas d'histoire .NET pour WASM et tant d'autres plateformes.

Une autre chose, je vous soumets que la plupart des développeurs préfèrent le nouveau Microsoft qui développe des technologies importantes comme celle-ci à l'air libre. Nous finirons par avoir un meilleur produit.

Cela étant dit, Blazor peut même ne pas voir le jour pour diverses bonnes raisons. Prévoyez cela aussi.

Je suis allé de l'avant et j'ai commencé à créer un moteur Xaml qui s'exécute nativement dans le navigateur. Vous pouvez le vérifier ici : https://github.com/XamlEngine/Samples

Rejoindre cette discussion un peu tard, mais surpris qu'autant de personnes s'inquiètent de la façon dont leur code standard .NET s'exécute. Appliquez l'étiquette de votre choix sur l'environnement d'exécution - Mono, .NET Core, FlubberGast - quel que soit l'environnement d'exécution réel qui sera différent. Il est impossible que .NET Core sur le serveur soit le même que .NET Core sur WASM ou qu'il soit compilé contre WASM. Alors, qui s'en soucie vraiment ?

Ce qui compte, c'est la façon dont le caoutchouc rencontre la route ou la facilité d'accès à ce code d'exécution. Je suis d'accord avec @EisenbergEffect qu'avoir un chemin de niveau inférieur plus facile pour obtenir .NET bootstrap pourrait être un énorme coup de pouce pour .NET en général.

Pourquoi ne pas en faire une poussée sérieuse en plus de ce que fait Blazor, car cela stimulerait sûrement l'innovation autour des différentes façons d'utiliser .NET dans le navigateur. Cela ne peut être un énorme avantage pour la visibilité de NET que si de nombreux nouveaux projets apparaissent et utilisent .NET de manière nouvelle et innovante dans le navigateur. Je suis sûr que Rob pose la question car il a des idées sur la façon de construire un nouveau cadre quelconque :-)

C'est faisable aujourd'hui avec le module Mono.wasm actuel et à l'avenir avec .NET Core ou au moins le compilateur Mono AOT, mais je pense que la construction d'une interface d'hébergement standard qui pourrait faciliter l'amorçage de .NET dans le navigateur irait un long chemin vers ce but. Le temps d'exécution réel pourrait ensuite être branché et échangé au fur et à mesure que la technologie et les ressources mises à jour deviennent disponibles.

Cela semble être une énorme opportunité pour .NET d'être l'un des premiers à adopter l'espace Web Assembly. Ce que j'ai vu avec Blazor semble très prometteur, mais je pense que ce n'est pas assez progressif si c'est le seul point d'exposition WASM officiel de .NET. J'aime vraiment le modèle Blazor et ce qu'il permet, mais je pense que ce n'est que la pointe de l'iceberg de ce qui est possible si l'écosystème pour exécuter .NET était aussi simple que de créer une application .NET standard. Je ne parle pas nécessairement des frameworks d'interface utilisateur ici - mais même de la possibilité d'amorcer et d'appeler des classes .NET lâches, soit en tant que point d'entrée et traitement de type Web Worker, soit même en tant que moyen d'interopérabilité à partir d'applications JavaScript existantes. Même pour cela, les avantages du partage d'un code d'entreprise/de validation pourraient être incroyablement précieux.

Beaucoup de potentiel - ce serait cool de permettre cela autant que possible en facilitant l'utilisation de cette technologie, même les bits de niveau inférieur !

@RickStrahl Cela peut ne pas sembler progressif car ils sont encore en phase expérimentale, mais ils ont beaucoup d'idées sur lesquelles ils travaillent, notamment le rendu du serveur, les applications de bureau/mobiles, les travailleurs Web, etc. Cela vous donnera une meilleure idée de ce que ils envisagent.

Oh, je ne pense pas que Blazor ne soit pas progressif - j'ai clarifié dans mon message ci-dessus. Même en jouant avec cela, je peux tout à fait dire que ce sera un excellent moyen de créer des applications. Il y a tellement de petits moments où vous allez juste - ce serait tellement pénible en Javascript/Typescript.

Mon point est principalement que je pense qu'ils devraient également ajouter la fonctionnalité .NET brute en plus de Blazor. Cette infrastructure doit être construite de toute façon pour prendre en charge Blazor, alors pourquoi ne pas l'exposer d'une manière plus conviviale afin qu'il soit très facile de supprimer « l'hébergement » .NET dans une application cliente.

Je ne suis pas sûr de comprendre, Blazor nous permet d'utiliser la plupart des fonctionnalités .NET, quelle fonctionnalité spécifiquement manquez-vous ?

Je dois utiliser Blazor. Que se passe-t-il si j'ai une application HTML existante ou si je construis quelque chose avec un autre framework et que je n'ai pas besoin de Blazor ? Il existe toujours un excellent cas d'utilisation pour fournir un accès au code .NET dans le navigateur en dehors d'un framework HTML (partage de code de validation, utilitaires, etc., etc.).

Je dois utiliser Blazor. Que se passe-t-il si j'ai une application HTML existante ou si je construis quelque chose avec un autre framework et que je n'ai pas besoin de Blazor ? Il existe toujours un excellent cas d'utilisation pour fournir un accès au code .NET dans le navigateur en dehors d'un framework HTML (partage de code de validation, utilitaires, etc., etc.).

Je ne comprends pas. Blazor est essentiellement :

1. Syntaxe Razor pour les composants Web,
2. divers assistants d'interopérabilité JS,
3. WebAssembly mono-basé .NET

Vous voulez probablement le deuxième et le troisième d'entre eux, et le premier ne vous fait pas de mal.

Mon point est principalement que je pense qu'ils devraient également ajouter la fonctionnalité .NET brute en plus de Blazor. Cette infrastructure doit être construite de toute façon pour prendre en charge Blazor, alors pourquoi ne pas l'exposer d'une manière plus conviviale afin qu'il soit très facile de supprimer « l'hébergement » .NET dans une application cliente.

C'est certainement l'intention de l' effort mono.wasm tel que je le comprends. Nous nous référons souvent à Blazor et mono.wasm dans le même souffle, mais en réalité Blazor n'est qu'un framework web. C'est mono.wasm qui fournit le runtime .NET sous-jacent basé sur WebAssembly. D'autres frameworks sont libres de s'appuyer sur le même runtime, et des frameworks alternatifs existent déjà ( Ooui , Uno ). @kumpera @mhutch sont probablement les bonnes personnes de l'équipe Xamarin pour parler de l'expérience de développement qu'ils espèrent permettre autour de l'utilisation de mono.wasm indépendamment de tout framework d'interface utilisateur particulier.

Le fichier zip fournit, aujourd'hui, un support extrêmement brut pour l'écriture d'applications C# sans Blazor. C'est assez bon pour valider la technologie mais cela demande beaucoup de travail manuel.

Notre objectif est de fournir ce que suggère cette description de problème, une chaîne d'outils complète comprenant des liaisons riches et le débogage.

Quel fichier zip ?

@EisenbergEffect ce dont vous devriez vous soucier est .NET Standard, pas .NET Core.
Assurez-vous que vos API dépendantes reposent sur .NET Standard et tout va bien.

@weitzhandler Je pense que vous manquez peut-être mon point de vue. Si je veux construire quelque chose avec .NET, je dois installer un ensemble concret d'outils, n'est-ce pas ? J'ai commencé à travailler avec .NET il y a plus de 15 ans, donc je ne trouve personnellement rien de tout cela intimidant ou déroutant (bien que je préfère ne pas avoir d'outillage quasi duplicatif installé sur ma machine). Mais imaginez quelqu'un qui n'a aucune expérience avec .NET et qui est un utilisateur Mac. Ils décident de créer une application .NET, à la fois front-end et back-end. Ils entendent que .NET Core est la dernière nouveauté, alors ils passent par le rigamarole pour installer le .NET CLI et le code VS. Ensuite, ils découvrent qu'ils ne peuvent pas construire leur front-end avec ça. Ils doivent aller chercher un ensemble d'outils différent (avec un nom différent, d'un endroit différent, avec un leadership différent, etc.). Encore une fois, imaginez qu'ils n'ont aucun antécédent avec .NET. Ce n'est pas une bonne première expérience. Ok, maintenant imaginez que cette personne est un architecte ou un CTO qui essaie de donner une nouvelle évaluation de .NET pour la première fois ou après plusieurs années. Peut-être qu'ils définissent la direction de leur entreprise. Est-ce l'expérience que vous souhaitez que cette personne ou ses conseillers techniques aient ? Ils vont le comparer à Go, Node, Rust, etc.

Quant à mes sentiments personnels, ma tolérance est assez faible après tant d'années et tant de versions de .NET. J'essaie d'aider des gens comme @ danroth27 à comprendre un peu ce qui doit arriver pour que les gens comme moi s'intéressent à nouveau à .NET. Il y a beaucoup plus que cela, mais avoir un peu plus d'unification aiderait certainement. Je veux juste installer un seul code CLI et VS. Le processus de mise en place et d'exécution d'une application .NET à pile complète sur des plates-formes non Windows ne devrait pas être plus compliqué que cela.

Mon message original était destiné à brosser un tableau simple de ce à quoi devrait ressembler une "étoile du nord" WASM du point de vue de l'expérience de développement et de la sortie de construction. J'installe la CLI, j'écris du code C# (avec l'éditeur que je veux), puis j'exécute une commande CLI pour créer mon code C# sur WASM, produisant un ensemble raisonnable de fichiers de sortie (wasm, liaisons, types). Cela devrait être le but. Si ce n'est pas là aujourd'hui, c'est compréhensible. Mais assurons-nous que nous naviguons sur le navire .NET dans la bonne direction, vers la meilleure expérience possible, sans nous contenter de ce qui est simplement le plus simple ou le plus rapide pour les ingénieurs Microsoft.

@EisenbergEffet
Rob, je suis d'accord que l'objectif serait finalement de faire fonctionner .NET Core partout, même en remplaçant Mono par celui-ci.
Je voudrais même qu'un " .NET UI Standard " qui rend partout le même soit inclus avec .NET Core, mais .NET Core est relativement récent. .NET Standard était la meilleure solution pour mettre cette divergence en forme, et il ne semble actuellement pas que vous puissiez demander mieux.

Mon vote est pour le remplacement de Mono par .NET Core pour les mêmes points que @EisenbergEffect a fait.

@EisenbergEffect Je rêve d'un micro caliburn pour le web, est-ce ce que vous avez en tête ? En fait, j'ai commencé à travailler sur le successeur spirituel avec knockout et Duocode (port JavaScript de mscorlib) il y a quelque temps avant que l'assemblage Web ne soit une chose.

@AndersMalmgren Aurelia ressemble beaucoup à Caliburn.Micro pour le web aujourd'hui. La version vNext sur laquelle nous travaillons pour la sortie cette année prend même en charge les moteurs de rendu alternatifs afin qu'elle puisse être rendue non seulement en HTML, mais également en applications natives de bureau, 3D et console. Il est écrit en TypeScript, pas en .NET. Il sera peut-être possible de porter Aurelia sur .NET Core à un moment donné dans le futur, une fois que cette technologie aura mûri un peu plus.

Cela dit, puisque Microsoft construit Blazor, je suis moins susceptible de construire personnellement quoi que ce soit pour .NET WASM car cela me mettrait en concurrence avec Microsoft. D'après l'histoire, nous savons qu'aucun open source au sein de l'écosystème .NET n'est jamais égal à quoi que ce soit lorsque Microsoft a décidé de créer quelque chose de similaire, que cet open source soit mieux conçu, plus extensible, plus performant, etc. J'admets être assez blasé ici. La seule chose qui est susceptible de changer cela, c'est si Microsoft m'engageait à diriger un framework et un écosystème front-end basés sur .NET Core. Ce ne serait pas Blazor cependant. Blazor n'est pas bien conçu (il répète les modèles anit .NET d'il y a 10 ans), il n'est pas non plus assez ambitieux, assez conforme aux normes ou assez tourné vers l'avenir, à mon avis. C'est une plus grande opportunité en jeu pour Microsoft, mais la fenêtre se ferme. J'ai essayé de convaincre diverses personnes chez Microsoft d'adopter ce qu'elles pouvaient faire, mais jusqu'à présent, j'ai échoué. Le front-end ne semble pas être une grande priorité pour Microsoft en ce moment.

@EisenbergEffect Le problème pour moi est que Blazor utilise Razor qui est MVC. Nous avons besoin d'un véritable MVVM qui peut prendre la puissance d'un runtime clr complet. Comme les modèles basés sur les conventions de type, etc. J'ai commencé ce travail avec DuoCode et knockout et j'ai utilisé mes Knockout.BindingConventions pour les coller ensemble. J'ai même une syntaxe comme celle-ci qui fonctionne

public IEnumerable<IResult> Save()
{
    var confirm = new ConfirmResult("Proceed?");
    yield return confirm;

    if (confirm.Result == ConfirmResults.Cancel)
        yield break;

    yield return new service.SendCommand(new SaveSomethingCommand(this.something));
}

https://github.com/AndersMalmgren/Knockout.BindingConventions.DuoCode/wiki/IResult-state-machine

Knockout s'est éteint et mon intérêt avec lui. Mais le rêve continue :D

Eh bien, je pourrais reprendre le travail mais avec Vue ou similaire.

Peut-être Aurelia au lieu de Vue, puisqu'Aurelia descend de Durandal, qui vient de Caliburn.Micro. De plus, Aurelia a des conventions, des modèles JS vanille, fonctionne mieux, a une forte conformité aux normes et beaucoup plus de qualités que les autres frameworks n'ont pas 😄

Ce ne serait pas Blazor cependant. Blazor n'est pas bien conçu (il répète les modèles anit .NET d'il y a 10 ans), il n'est pas non plus assez ambitieux, assez conforme aux normes ou assez tourné vers l'avenir, à mon avis.

Qu'est ce qui ne va pas avec ça?

@EisenbergEffect ou Aurélia. J'aime Aurelia, mais comme il utilise JavaScript ou Typescript, qui est un langage d'effacement de type, vous perdez toute cette douce magie d'exécution CLR que vous pouvez faire. De plus, JavaScript DI est pour être honnête par rapport à ce que vous pouvez faire avec un bon runtime clr. J'ai implémenté un petit conteneur DI pour Duocode pour le même projet mentionné précédemment et l'injection basée sur le type en frontend est la voie à suivre à mon avis. Je dois me pencher sur la modularité d'Aurelia, le knockout était très extensible à l'époque, et Vue semble poursuivre cette tendance.

@AndersMalmgren Aurelia est probablement le framework front-end le plus extensible aujourd'hui. L'implémentation de vNext sur laquelle nous travaillons l'amène également à un autre niveau. Vous pourriez également être surpris de ce que nous pouvons faire avec notre DI :) Il est basé sur le type et a des durées de vie extensibles, etc. Étant donné que JS a un support natif pour les classes, il n'y a pas d'effacement. Nous pouvons également modéliser des interfaces avec une méthode d'aide DI ou un symbole Vanilla JS. Ainsi, TS peut les fusionner avec des interfaces TS, permettant les mêmes modèles que .NET. En d'autres termes, vous pouvez très bien avoir IAuthenticationService injecté dans une classe au moment de l'exécution 😄 Pour autant que je sache, nous sommes le seul framework qui peut le faire. J'ai essayé d'apporter autant de bonnes parties de Xaml et Caliburn.Micro sur le Web tout en laissant les mauvaises parties derrière moi. Ainsi, MVVM est encore plus simple et plus puissant dans Aurelia également. Je vais créer une série d'articles de blog sur Aurelia pour les développeurs Xaml et Aurelia pour les développeurs ASP.NET MVC. Cela pourrait aider les gens à faire le lien et à comprendre pourquoi/comment cela rend le développement frontal non seulement rapide et facile, mais aussi SOLIDE.

@manigandham J'ai passé de nombreuses années en tant que développeur .NET, leader open source .NET et MVP Microsoft, donnant beaucoup de commentaires à Microsoft sur des choses comme celle-ci. J'ai même travaillé pour Microsoft en tant que Sr. PM, Sr. PM Manager et Principal PM Manager pendant une courte période (pas dans l'équipe .NET cependant). Malheureusement, sur une période d'environ 12 ans pendant que je faisais cela, j'ai vu très peu de choses en sortir, en particulier en ce qui concerne les commentaires que j'ai donnés sur les frameworks front-end. Donc, vous devrez me pardonner si je n'ai pas envie de passer mon samedi à écrire un article de 10 000 mots sur les problèmes de conception avec Blazor, les problèmes de normes Web, la vision du produit, etc. Je ne suis tout simplement pas sûr que ce soit le cas. équivaut à n'importe quoi. Si Microsoft veut m'embaucher pour diriger l'avenir du front-end pour eux, j'y réfléchirais certainement, mais comme je l'ai dit, le front-end n'est pas vraiment une priorité pour eux en ce moment. Et pour autant que je sache, Blazor n'est même pas encore financé.

Et pour ceux qui ne me connaissent pas, je veux juste ajouter que je ne suis pas en colère contre tout ça ou une personne en colère. Je sais que parfois les choses semblent un peu comme ça quand tu ne me connais pas et que tu viens de lire mes commentaires ici ou là. Cependant, je suis très très passionné par le front-end. J'ai construit des frameworks front-end, des bibliothèques et des outils pendant presque toute ma carrière. C'est une courte période de 15 ans, mais c'est relativement long à consacrer à ce domaine. Donc, j'ai vu beaucoup de choses, fait beaucoup de choses et j'ai absolument des opinions bien arrêtées. Je suis passionné et je suis frustré quand je vois Microsoft répéter de vieilles erreurs ou faire des choses que j'ai déjà vues mal tourner ailleurs. Donc, je n'ai aucune mauvaise volonté ici. Je veux vraiment que Microsoft réussisse. Je veux les voir être le leader du front-end. Je suis juste frustré et un peu triste pour être honnête, quand je vois que cela ne se produit pas. Je veux le meilleur pour .NET et sa communauté.

vous devrez me pardonner si je n'ai pas envie de passer mon samedi à écrire un papier de 10 000 mots sur les problèmes de conception avec Blazor

Le fait est que vous avez fait une réclamation, puis quelqu'un vous a simplement demandé d'entrer plus en détail à ce sujet :

Blazor n'est pas bien conçu (il répète les modèles anit .NET d'il y a 10 ans), il n'est pas non plus assez ambitieux, assez conforme aux normes ou assez tourné vers l'avenir, à mon avis.

Moi aussi, je serais curieux de connaître des exemples particuliers.

Et étant donné la nature de Blazor en ce moment, je ne suis pas sûr qu'il soit juste de le comparer avec un produit Microsoft moyen. Ce _n'est pas_ encore un produit, et il est développé au grand jour bien plus qu'il ne le serait s'il l'était.

@chucker je comprends. C'est bon marché de ma part de faire une réclamation comme ça et de ne pas entrer dans les détails. Je suis reconnaissant que vous soyez intéressé à en savoir plus.

De mon point de vue cependant, la plupart de ce que je dirais sont des commentaires que j'ai déjà donnés à Microsoft, souvent à plusieurs reprises auparavant. Donc, même si ce serait intéressant pour vous, je ne suis pas sûr que cela ferait une différence pour Microsoft. Je ne sais pas si quelque chose changerait.

Cela dit, je vais essayer de commencer à décrire quelque chose. Il serait cependant trop long de déposer un commentaire GitHub. J'ai un peu peur du contrecoup si je publie un blog à ce sujet. J'ai été victime d'intimidation et de haine à de nombreuses reprises dans ma carrière par divers groupes qui n'aimaient pas être critiqués. Bien qu'il s'agisse principalement de membres de l'équipe Facebook/React récemment, je ne suis pas sûr de vouloir m'ouvrir à nouveau.

Peut-être qu'il y a un moyen pour que je puisse encadrer un tel message où cela ferait une différence et n'inviterait pas beaucoup de manière négative. C'est un jeu difficile à jouer. Je vais quand même y réfléchir.

Je peux confirmer qu'à bien des égards, Blazor connu et inconnu n'est pas parfaitement conçu et nous accueillons tous les commentaires constructifs pour l'améliorer. Comme en témoigne notre arriéré de problèmes, il y a beaucoup de travail à faire ! Et tandis que la perfection de la conception restera presque certainement insaisissable, en fin de compte, ce qui compte vraiment, c'est si les développeurs trouvent l'utilisation de Blazor productive et utile. Cela semble réalisable.

@EisenbergEffect J'accueille certainement toute critique ou commentaire objectif et constructif que vous pourriez avoir. Comme pour toute critique objective, je ne peux pas promettre que cela changera quoi que ce soit. Je peux seulement dire que nous ferons de notre mieux pour l'examiner attentivement.

De plus, personne ne mérite d'être victime d'intimidation ou de haine et un tel comportement est explicitement contraire à notre Code de conduite .

À mon humble avis, Blazor a déjà réussi. Au cours de mes 20 années de développement avec les technologies Microsoft et non Microsoft, j'ai vu le même modèle émerger à chaque fois. Chaque fois que quelque chose de nouveau sort, vous voyez deux types de développeurs. Celui qui voit le modèle de programmation comme un véhicule pour aller quelque part et celui qui aime passer des heures et des heures à bricoler différentes bibliothèques. J'ai essayé de me convaincre que l'utilisation de toutes ces différentes bibliothèques js de toutes ces différentes sociétés me donne plus de mobilité et de liberté en tant que développeur, mais je découvre rapidement comment elles s'éloignent toutes dans la vision, la mission et, malheureusement, la compatibilité à un moment donné. J'ai toujours fini par chercher un modèle de programmation unifié et j'ai réalisé que des conventions strictes ne sont pas toujours une mauvaise chose. En bref. Je me soucie de la solution et Microsoft ne m'a jamais laissé tomber. Certaines de mes applications Web les meilleures et les plus utilisées sont toutes réalisées sur la technologie Microsoft et je pense que Blazor apportera un bon modèle de programmation unifié qui fonctionne bien mais ne dépend pas de centaines d'autres bibliothèques travaillant ensemble.

À mon humble avis, Blazor a déjà réussi. Au cours de mes 20 années de développement avec les technologies Microsoft et non Microsoft, j'ai vu le même modèle émerger à chaque fois. Chaque fois que quelque chose de nouveau sort, vous voyez deux types de développeurs. Celui qui voit le modèle de programmation comme un véhicule pour aller quelque part et celui qui aime passer des heures et des heures à bricoler différentes bibliothèques. J'ai essayé de me convaincre que l'utilisation de toutes ces différentes bibliothèques js de toutes ces différentes sociétés me donne plus de mobilité et de liberté en tant que développeur, mais je découvre rapidement comment elles s'éloignent toutes dans la vision, la mission et, malheureusement, la compatibilité à un moment donné. J'ai toujours fini par chercher un modèle de programmation unifié et j'ai réalisé que des conventions strictes ne sont pas toujours une mauvaise chose. En bref. Je me soucie de la solution et Microsoft ne m'a jamais laissé tomber. Certaines de mes applications Web les meilleures et les plus utilisées sont toutes réalisées sur la technologie Microsoft et je pense que Blazor apportera un bon modèle de programmation unifié qui fonctionne bien mais ne dépend pas de centaines d'autres bibliothèques travaillant ensemble.

Si Microsoft ne prenait pas d'influence de l'extérieur, nous serions bloqués sur les formulaires Winform et les formulaires Web.

https://devblogs.microsoft.com/dotnet/introducing-net-5/
Aujourd'hui, nous annonçons que la prochaine version après .NET Core 3.0 sera .NET 5. Ce sera la prochaine grande version de la famille .NET.

Il n'y aura plus qu'un seul .NET et vous pourrez l'utiliser pour cibler Windows, Linux, macOS, iOS, Android, tvOS, watchOS et WebAssembly et plus encore.

Nous présenterons de nouvelles API .NET, des capacités d'exécution et des fonctionnalités de langage dans le cadre de .NET 5.