Aspnetcore: XAML statt HTML und CSS

@MohammadHamdyGhanem Siehe https://github.com/aspnet/Blazor/issues/374#issuecomment -376314750

Für Blazor zielen wir auf C#, HTML und CSS ab, aber für XAML können Sie sich Ooui ansehen .

@danroth27

Für Blazor zielen wir auf C#, HTML und CSS ab, aber für XAML

Ich sage nicht, dass Sie aufhören, HTML und CSS zu verwenden. Ich sage, geben Sie uns die Möglichkeit, XAML zu wählen, wenn wir möchten. Ich weiß, dass es eine Web-Community gibt, aber es gibt auch eine .NET-Desktop-Community, die Web-Apps schreiben möchte. Bitte beachten Sie sie. Ich selbst hasste ASP.NET trotz meiner Bemühungen, es in den letzten 15 Jahren zu lesen und zu lernen! Im Gegenteil, ich fand XAML attraktiv, leistungsstark und leicht zu erlernen. Ich hatte gehofft, dass silbernes Licht dominieren und sich zur Microsoft Wen-Technologie entwickeln wird, aber es starb 2012!
Ich hoffe, Sie befolgen diesen Vorschlag, auch wenn Sie ihn Xlazor nennen :)

XAML können Sie sich Ooui ansehen.

Ich bin nicht auf Produkte von Drittanbietern in so großem Umfang angewiesen, weil ich nicht gewähre, dass sie Bestand haben und sich weiterentwickeln werden.

@MohammadHamdyGhanem Blazor & Ooui sind separate Produkte, die auf WebAssembly basieren, ähnlich wie .NET auf .NET Framework basiert. Beide sind notwendig, da es Webentwickler gibt, die Razor/HTML/CSS (ASP.NET) bevorzugen, und Desktop-/Mobile-Entwickler, die XAML bevorzugen. Ich denke also, beide müssen in .NET/Xamarin (blazor ist bereits zusammengeführt) zusammengeführt werden und sollten separat verwendet werden, damit sie leicht gehalten werden können und sich nicht gegenseitig durcheinander bringen.

@plamen-i
Ich stimme zu. Aber mit Xamarin kenne ich mich noch nicht aus. Ich bevorzuge es, UWP-ähnliche Steuerelemente zu verwenden.

@MohammadHamdyGhanem Xamarin, insbesondere Xamarin.Forms ist die Zukunft, wenn Sie einmal schreiben (C#/XAML) und überall ausführen möchten. Investieren Sie etwas Zeit, um Xamarin.Forms zu lernen, und es wird Ihnen viel mehr auszahlen :-) Es ist ausgereifte Technologie, verwendet XAML und ist WPF/UWP sehr nahe.

Ich sage, Microsoft sollte eine XAML-Standard-API (wie .NET Standard) erstellen, die befolgt werden sollte, egal ob Xamarin, UWP und ASP.NET, oder .NET Standard um diese erweitern.
Steuerelemente und ihre Eigenschaften und Methoden sollten unabhängig von der zugrunde liegenden Implementierung dieselben Namen haben. Dadurch wird das Erlernen all dieser Komponenten erleichtert und der Code optimal wiederverwendbar.

@MohammadHamdyGhanem Sie sind es, denke ich ... Hier ist das Repo dafür, aber es war in den letzten Monaten ziemlich tot. Ich hoffe, es ist nicht so und warte auf eine Ankündigung für Build 2018.

Das ist eine Erleichterung. Vielen Dank.

xamarin.forms sind nicht so performant wie native Android- oder iOS-Apps, es ist gut für Statis-Inhalte in Apps oder Cloud-verbundenen Apps, aber wenn Sie wirklich eine tiefe Integration mit OS-APIs wünschen und native Leistung benötigen, ist xamarin nicht so performant, plus die Tools von xamarin.native ist einfach schrecklich,

Ich machte weiter und begann mit dem Aufbau einer Xaml-Engine, die nativ im Browser ausgeführt wird. Sie können es hier überprüfen: https://github.com/XamlEngine/Samples

XAML muss eine Option sein. Ich weiß nicht, wie gut das Asp.Net-Team mit XAML vertraut ist. Das Team verbringt Zeit damit, das Rad neu zu erstellen. Wie beim letzten Community-Standup haben sie gezeigt, wie man Komponenten in Blazor erstellt. Ich sagte Warum?. Und warum ich neue Arten des Schreibens von Komponenten lernen muss. Sie haben XAML, das für all diese Dinge perfekt ist.

Es gibt Tausende von JS-Frameworks wie VUE, Angular, React, die bei der Datenbindung helfen. Und XAML war das erste, das all dies tat. Probieren Sie es zumindest aus.

Wir sind mit XAML vertraut, aber unser Hauptziel bei Blazor ist es, Webentwickler anzusprechen, daher bleiben wir bei HTML und CSS. Allerdings gibt es bereits verschiedene Bemühungen, XAML-Unterstützung für .NET auf WebAssembly (Ooui, Uno, FrogUI) aufzubauen. Wir empfehlen daher, sich diese Projekte anzusehen, wenn Sie XAML bevorzugen.

@danroth27
Ich sehe, dass MS mit XAML-Rasierer arbeiten muss, um VB.NET zu retten. Meiner Meinung nach war ASP.NET einer der Gründe dafür, dass die Popularität von VB.NET in den letzten zehn Jahren zurückgegangen ist. VBScripts laufen nur im Internet Explorer. Es ist also tot geboren und jeder Webentwickler musste nur JavaScript verwenden, das C-ähnliche Syntax verwendet, daher ist es einfacher mit C# als mit VB.NET zu verwenden. Im Laufe der Jahre entstanden immer mehr JavaScript-Frameworks, und MS passte einige davon wie JQuery und Angular an. TypeScript ist auch etwas fortgeschrittenes JavaScript.
Dies machte C# zur einzig logischen Wahl für Anfänger und zwang sogar viele VB.NET-Entwickler, auf C# zu migrieren.
Xaml blazoer hat also zwei Ziele:

1. Ziehen Sie c#-Desktop-Entwickler an. Ocertime wird es HTML-Fans umbringen!
   2- Ziehen Sie vb.net-Entwickler an und speichern Sie diese schöne einfache Sprache für Anfänger.

Ich denke, hier liegt ein Missverständnis über XAML vor. Ich bin wirklich ein Fan von XAML in Blazor, aber nicht wie oben beschrieben und in aspnet/Blazor#374.

Was ich vorschlage, ist unten beschrieben:

Das Problem

Stellen Sie sich vor, ich habe diese Komponenten:

Schublade.cshtml:

<aside class="mdc-drawer mdc-drawer--modal">
    <strong i="10">@Header</strong>
    <strong i="11">@ChildContent</strong>
</aside>

<strong i="12">@functions</strong>
{
    [Parameter]
    DrawerHeader Header { get; set; }

    [Parameter]
    RenderFragment ChildContent { get; set; }
}

DrawerHeader.cshtml:

<div class="mdc-drawer__header">
    <strong i="16">@ChildContent</strong>
</div>

<strong i="17">@functions</strong>
{
    [Parameter]
    RenderFragment ChildContent { get; set; }
}

Stellen Sie sich nun vor, in meiner 3. Komponente Main.cshtml möchte ich ein Drawer hinzufügen und dessen Drawer.Header festlegen. Derzeit muss ich eine Eigenschaft vom Typ DrawerHeader erstellen und sie an meine Drawer.Header binden:

<div class="drawer-frame-root">
    <Drawer Header="@Header">
        <DrawerContent>

        </DrawerContent>
    </Drawer>
    <DrawerScrim />
</div>

<strong i="25">@functions</strong>
{
    DrawerHeader Header
    {
        get;
    } = new SubClassOfDrawerHeader();
}

Daher muss ich eine weitere Komponente namens SubClassOfDrawerHeader erstellen und ihr die Header-Eigenschaft zuweisen. Das macht eine Menge Komponenten in meinem Projekt aus.

Mein Vorschlag

Mein Vorschlag ist, die Verschachtelung von Eigenschaften im XAML-Stil zu verwenden:

<div class="drawer-frame-root">
    <Drawer>
        <Drawer.Header>
                <DrawerHeader>
                        <DrawerHeaderTitle>User's name</DrawerHeaderTitle>
                        <DrawerHeaderSubtitle>[email protected]</DrawerHeaderSubtitle>
                </DrawerHeader>
        </Drawer.Header>
        <DrawerContent>Some content</DrawerContent>
    </Drawer>
    <DrawerScrim />
</div>

Bitte schauen Sie sich <Drawer.Header>...</Drawer.Header> im obigen Code an.

@MohammadHamdyGhanem @xclud Haben Sie sich nach Belieben eine ähnliche Plattform auf Basis von Xaml angesehen - Platform.uno - wie von @danroth27 bereits erwähnt?

Wenn es XAML hat, würden wir SOFORT zu Blazor wechseln, weil wir Silverlight wirklich genossen haben.
HTML/Javascript-Codierung == sehr nervige Art, Code zu schreiben (auch bekannt als "Skript")

Wenn es XAML hat, würden wir SOFORT zu Blazor wechseln, weil wir Silverlight wirklich genossen haben.
HTML/Javascript-Codierung == sehr nervige Art, Code zu schreiben (auch bekannt als "Skript")

@wstaelens Ich habe Silverlight auch sehr genossen und ein Dutzend Apps damit gemacht. Aus diesem Grund genieße ich gerade die Uno- Plattform (auch bekannt als Silverlight auf Steroiden).

Wenn es XAML hat, würden wir SOFORT zu Blazor wechseln, weil wir Silverlight wirklich genossen haben.
HTML/Javascript-Codierung == sehr nervige Art, Code zu schreiben (auch bekannt als "Skript")

@wstaelens Ich habe Silverlight auch sehr genossen und ein Dutzend Apps damit gemacht. Aus diesem Grund genieße ich gerade die Uno-Plattform (auch bekannt als Silverlight auf Steroiden).

Das Problem ist, dass dies kein "offizielles" Microsoft-Projekt ist, also lebenslange Unterstützung... was auch immer... Blazor braucht nur XAML-Unterstützung.

Das Problem ist, dass dies kein "offizielles" Microsoft-Projekt ist, also lebenslange Unterstützung... was auch immer... Blazor braucht nur XAML-Unterstützung.

@wstaelens Absolut verstanden. Ich sehe Uno als etwas, das auf den Schultern der Microsoft-Giganten steht - UWP, Mono, Xamarin ... Sie haben die Plattform nicht von Grund auf neu entwickelt, sondern nutzen viele ausgereifte Technologien brillant und haben sehr gut funktioniert. Ich habe mich sehr gefreut, dass Uno letzten Monat auf der Microsoft Build gut aufgenommen wurde und kürzlich von Miguel de Icaza gebilligt wurde.

Viele C#-Entwickler verwenden gerne XAML über HTML und CSS. Viele Leute wollten offizielle plattformübergreifende Unterstützung für UWP/WPF/XAML. Imo Microsoft sollte mit Blazor auch XAML unterstützen. Wann werden wir überhaupt offiziellen plattformübergreifenden Support für XAML erhalten?

Ich selbst bin ein Fan von C#, aber mein Problem mit der Webentwicklung und Electron war nie Javascript. Es ist CSS.

Was nützt Blazor, wenn es keine Alternative für HTML/CSS bietet? Warum ist es so schwierig, einen Ersatz für HTML/CSS zu finden, warum ist plattformübergreifendes XAML so schwierig... Ich verstehe es einfach nicht. Microsoft verpasst immer Gelegenheiten und trifft unkluge Entscheidungen.

An dem Tag, an dem XAML plattformübergreifend wird (offiziell von Microsoft unterstützt), erhält Blazor die volle Unterstützung aller C#-Entwickler. Zumindest nicht für mich... weil ich keinen wirklichen Vorteil von Blazor sehe. Denn ich beschäftige mich NOCH mit CSS, id, class,

Ich bin anderer Meinung, alle Webentwickler sind an HTML und CSS gewöhnt. Bitte halte dich an HTML und CSS

@ GoranHalvarsson, warum sind sie dann nicht an JavaScript oder TypeScript

Ich bin anderer Meinung, alle Webentwickler sind an HTML und CSS gewöhnt. Bitte halte dich an HTML und CSS

Leider sind nicht alle Webautoren Entwickler, einige sind Softwareingenieure und wir bevorzugen XAML/C#, um Elemente vertikal auf einer Seite zu zentrieren. Was in HTML/CSS immer noch ein Rätsel ist. XAML ist weit überlegen.

Ich habe einen Skoda und einen Porsche, fahre den Skoda aber nur, weil ich daran gewöhnt bin? Es gibt Xamarin als Option oder Avalonia (wenn Microsoft es besitzt und es die WPF-Spezifikation repliziert). Vielleicht sollte Microsoft eine Umfrage an die Blazor-Community senden und sie fragen, ob sie eine auswählen müssten - XAML oder HTML?

Silverlight-Entwickler hielten sich vor über 10 Jahren für Webentwickler. Nur weil iOS und Android beschlossen, keine Plugins zuzulassen, blieben viele Webentwickler ohne eine Plattform, für die sie entwickeln konnten.

@GoranHalvarsson Wenn Sie alle Webentwickler sagen, sind viele von uns an HTML und CSS gewöhnt (weil wir es sein müssen), bevorzugen jedoch XAML/C#. Sie sprechen nicht im Namen der Webentwickler-Community. Sagen Sie uns also nicht, woran wir uns halten sollen.

Und was ist falsch daran, Entwicklern mehrere Technologien zur Verfügung zu stellen?

Ich habe HTML, CSS, JavaScript ausgiebig für Webprojekte verwendet (ich versuche mich heutzutage so weit wie möglich von JavaScript fernzuhalten).
Wenn es um Rich Internet Applications (RIA) oder Single Page Apps (SPA) geht, sind Xaml und C# König und Königin. Ich werde keine andere Option wählen.
Ich muss zugeben, dass ich zu den Glücklichen gehöre, die keiner auferlegten Plattform unterliegen, dem Luxus, den nicht jeder hat.

Ich habe vor kurzem ein Blazor Project SSB (ich benutze CSB noch nicht) mit Telerik und SyncFusion abgeschlossen. Die C#-Erfahrung war großartig! Das JavaScript / HTML / CSS war irritierend. Es scheint, dass die meisten Steuerelemente von Drittanbietern die meisten Fehler in CSS aufweisen. Sie möchten keinen großen SPA auf diese Weise bauen, es wäre mühsam zu warten.

In der Vergangenheit habe ich umfangreiche XAML / C# Erfahrung. Ich muss sagen, alles unter einem Dach zu haben, macht die Entwicklung nicht nur schneller und zuverlässiger, sondern macht auch mehr Spaß.

Mir persönlich ist es egal, ob XAML / C#-Unterstützung nicht im Browser ist, solange es plattformübergreifend ist. Es ist wahrscheinlich genauso wichtig, Kontinuität in einem Tech-Stack zu haben, mit einfachen Möglichkeiten, auf neuere Technologien zu migrieren. Eines der größten Probleme in der Vergangenheit (abgesehen von Silverlight) war die Verwendung von ORM-Lösungen von Drittanbietern. Bleiben Sie immer bei der von Microsoft unterstützten Technologie, wo immer möglich, ist mein Rat!

Wenn Microsoft WPF und WinForms plattformübergreifende / WASM-Unterstützung hinzufügen würde, wäre das Problem für mich gelöst. Ich würde Blazor wahrscheinlich nie wieder verwenden, wenn dies der Fall wäre, da wir alle die ultimative Lösung als Option hätten.