Avec l'invention de Blazor, je me demande s'il existe des gains d'efficacité significatifs (à la fois dans la création de code et dans la compilation / exécution de code) entre ces deux langages.
https://github.com/SteveSanderson/Blazor
Si quelqu'un l'a réellement implémenté, avez-vous entrepris des tests de performances ou avez-vous des commentaires anecdotiques (oui, excusez-moi de vos excuses) sur le processus d'écriture de code, par rapport à Razor?
Les informations que je présente ci-dessous sont principalement paraphrasées de l'entrée de Steven Anderson sur le blog du 2 février et de ma propre compréhension des objectifs du projet:
Blazor est destiné à combiner les idées de la pile actuelle de .NET Razor avec une architecture de structure SPA moderne.
Création de code
est conçu pour être flexible et encourage les dispositions basées sur les composants, comme le montre cet exemple:
<div class="my-styles">
<h2>@Title</h2>
@RenderContent(Body)
<button onclick=@OnOK>OK</button>
</div>
@functions {
public string Title { get; set; }
public Content Body { get; set; }
public Action OnOK { get; set; }
}
ce qui crée un composant réutilisable dans le balisage html:
<MyDialog Title="Ski Lift controls" onOK="DismissSkiDialog">
Gondola @gondolaId is now <em>running</em>
</MyDialog>
Exécution
Blazor devrait être rapide, car webAssembly est rapide. Il se compile en bytecode qui est directement exécuté par le chargeur de wasm du navigateur. En javascript, par exemple, les fichiers .js
doivent d'abord être chargés et des fichiers séparés sont combinés, puis analysés et tokenisés et intégrés dans une structure arborescente, qui peut ensuite être interprétée par le moteur javascript d'un navigateur (moteur v8 de chrome , par exemple) .
Pour une comparaison approfondie de webAssembly et de l'exécution javascript, consultez cet article .
Architecture et conception du SPA
Comme il existe d'excellents frameworks déjà construits en javascript pour le web, Blazor s'est inspiré des idées déjà utilisées dans les frameworks modernes tels que React, Vue et Angular, et proposera des concepts détaillés dans la publication tels que:
Notez que bien que ces concepts existent pour le côté serveur dans Razor, ils n'existent pas tous du côté client. Le routage frontal n'est pas disponible dans Razor et a souvent été combiné avec un framework javascript pour remplir ce scénario.
J'ai personnellement travaillé sur des applications d'entreprise servant des pages Razor avec AngularJs. Il peut parfois être salissant et ne jamais se sentir «propre».
En résumé
Razor est une solution pour l'architecture basée sur serveur qui peut gérer la logique api et les modèles côté serveur, mais il ne peut pas offrir de logique côté client en dehors de javascript.
Blazor est la prochaine étape (et, espérons-le, le successeur) qui permettra la même fonctionnalité côté serveur que Razor, mais intégrera la logique côté client en utilisant C#
au lieu de javascript.
Je travaille actuellement sur un petit projet de test avec Blazor, et jusqu'à présent je le trouve facile à utiliser. Mais comme l'indiquent les avertissements sur le blog et la page GitHub, il n'est même pas proche de la production.
Dans le .NET Conf 2018, il a été annoncé que les composants Razor ("Blazor côté serveur") feront partie de .NET Core 3.0 . Ce code a été affiché:
// inside index.cshtml - serverside use of blazor
<SurveyPrompt Title="How is Blazor working for you?" />
<div>
<img id="bot" src="@imageurl" />
<div>
<button class="btn btn-primary" onclick="@changeImage">Click me</button>
@functions{
string imageurl = "/images/dotnet-bot-1.png";
void changeImage()
{
if(imageurl.Contains("1"))
{
imageurl= imageurl.Replace("1", "2");
}
else
{
imageurl= imageurl.Replace("2", "1");
}
}
}
Razor est une solution pour l'architecture basée sur serveur qui peut gérer la logique API et les modèles côté serveur, mais il ne peut pas offrir de logique côté client en dehors de JavaScript.
Blazor est la prochaine étape (et, espérons-le, le successeur) qui permettra la même fonctionnalité côté serveur que Razor mais intégrera la logique côté client en utilisant C # au lieu de JavaScript.