Aspnetcore: HTMLとCSSの代わりにXAML

@MohammadHamdyGhanemhttps ： //github.com/aspnet/Blazor/issues/374#issuecomment-376314750を参照してください

Blazorの場合はC＃、HTML、CSSを対象としていますが、XAMLの場合はOouiをご覧ください。

@ danroth27

Blazorの場合、C＃、HTML、CSSをターゲットにしていますが、XAMLの場合は

HTMLとCSSの使用をやめるとは言いません。 必要に応じて、XAMLを選択するオプションを提供してください。 Webコミュニティがあることは知っていますが、Webアプリを作成したい.NETデスクトップコミュニティもあります。 それらを考慮してください。 過去15年間、ASP.NETについて読んで学習しようと努力したにもかかわらず、私自身はASP.NETが嫌いでした。 それどころか、XAMLは魅力的で、強力で、習得が容易であることがわかりました。 シルバーライトが支配的で進化してMicrosoftWenテクノロジーになることを望んでいましたが、2012年に消滅しました。
Xlazorという名前を付けたとしても、この提案を考慮してください:)

XAMLではOouiを見ることができます。

サードパーティの製品に大規模に依存することはありません。なぜなら、サードパーティの製品が長持ちして進化することを認めていないためです。サードパーティの製品が死んだ場合は見逃す可能性があるため、それを使用する大規模なプロジェクトを書き直す必要があります。

@MohammadHamdyGhanem BlazorとOouiは、.NETが.NET Frameworkに基づいているのと同じように、WebAssembly上に構築された別個の製品です。 Razor / HTML / CSS（ASP.NET）を好むWeb開発者と、XAMLを好むデスクトップ/モバイル開発者がいるため、両方が必要です。 したがって、両方を.NET / Xamarinにマージする必要があり（blazorはすでにマージされています）、軽量に保ち、互いに混乱しないように、別々に使用する必要があると思います。

@ plamen-i
同意します。 しかし、私はまだXamarinに精通していません。 私はUWPのようなコントロールを使用することを好みます。

@MohammadHamdyGhanem Xamarin、特にXamarin.Formsは、一度作成して（C＃/ XAML）どこでも実行できる未来です。 Xamarin.Formsを学ぶために少し時間を費やすと、はるかに多くの利益が得られます:-)成熟したテクノロジーであり、XAMLを使用し、WPF / UWPに非常に近いです。

Microsoftは、Xamarin、UWP、ASP.NETに準拠するXAML標準API（.NET Standardなど）を作成するか、.NETStandardを拡張してこれを含める必要があると言っています。
コントロールとそのプロパティおよびメソッドは、基本的な実装に関係なく同じ名前にする必要があります。 これにより、これらすべてのコンポーネントの学習が容易になり、コードを最大限に再利用できるようになります。

@MohammadHamdyGhanem彼らは私が思うに...これが

それは安心です。 ありがとう。

xamarin.formsは、ネイティブのanroidまたはiosアプリほどパフォーマンスが高くありません。アプリやクラウドに接続されたアプリの統計コンテンツには適していますが、OS apiとの緊密な統合が本当に必要で、ネイティブのパフォーマンスが必要な場合は、xamarinはパフォーマンスに加えてツールを使用しません。 xamarin.nativeのはひどいです

私は先に進み、ブラウザーでネイティブに実行されるXamlエンジンの構築を開始しました。 こちらで確認できます： https ：

XAMLはオプションである必要があります。 Asp.NetチームがXAMLにどれだけ精通しているかわかりません。 チームはホイールの再作成に時間を費やしています。 最近のコミュニティスタンドアップのように、彼らはBlazorでコンポーネントを作成する方法を示しました。 なぜ言ったの？ そして、なぜ私はコンポーネントを書く新しい方法を学ばなければならないのか。 これらすべてに最適なXAMLがあります。

データバインディングに役立つVUE、Angular、ReactなどのJSフレームワークは数千あります。 そして、XAMLはこれらすべてを最初に行ったものです。 少なくとも試してみてください。

私たちはXAMLに精通していますが、Blazorの主な目標はWeb開発者をターゲットにすることであるため、HTMLとCSSに固執しています。 とはいえ、WebAssembly（Ooui、Uno、FrogUI）で.NETのXAMLサポートを構築するためのさまざまな取り組みがすでに行われているため、XAMLを使用する場合は、これらのプロジェクトを確認することをお勧めします。

@ danroth27
MSはVB.NETを保存するためにXAMLかみそりで動作する必要があることがわかります。 私の意見では、ASP.NETは、過去10年間でVB.NETの人気が低下した理由の1つでした。 VBScriptはInternetExplorerでのみ実行されるため、生まれつき、Web開発者はCのような構文を使用するJavaScriptを使用するだけで済み、VB.NETよりもC＃で簡単に使用できます。 何年にもわたってJavaScriptフレームワークが出現し続け、MSはJQueryやAngularなどのいくつかを採用しました。 TypeScriptも高度なJavaScriptです。
これにより、C＃が初心者にとって唯一の論理的な選択となり、多くのVB.NET開発者がC＃に移行することを余儀なくされました。
したがって、Xamlblazoerには2つの目標があります。

1. C＃デスクトップ開発者を引き付けます。 いつかそれはhtmlファンを殺しすぎるでしょう！
   2- vb.net開発者を引き付け、この美しく簡単な初心者の言語を保存します。

ここでXAMLについて誤解があると思います。 私は本当にBlazorのXAMLのファンですが、上記やaspnet / Blazor＃374で説明した方法ではありません。

私が提案していることは以下のとおりです。

問題

私がこれらのコンポーネントを持っていると想像してください：

Drawer.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; }
}

次に、3番目のコンポーネントMain.cshtmlで、 Drawerを追加し、そのDrawer.Headerます。 現在、タイプDrawerHeaderプロパティを作成し、それをDrawer.Headerバインドする必要があります。

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

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

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

したがって、 SubClassOfDrawerHeaderという名前の別のコンポーネントを作成し、Headerプロパティを割り当てる必要があります。 これは私のプロジェクトにたくさんのコンポーネントを作ります。

わたしの提案

私の提案は、XAMLスタイルのプロパティのネストを使用することです。

<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>

上記のコードの<Drawer.Header>...</Drawer.Header>をご覧ください。

@MohammadHamdyGhanem @xclud @ danroth27で前述したように、Xamlをベースにした同様のプラットフォーム（ Platform.uno）をご覧になりましたか？

XAMLがあれば、Silverlightを本当に楽しんだので、すぐにBlazorに移行すると思います。
HTML / Javascriptコーディング==コード（別名「スクリプト」）を書くための非常に厄介な方法

XAMLがあれば、Silverlightを本当に楽しんだので、すぐにBlazorに移行すると思います。
HTML / Javascriptコーディング==コード（別名「スクリプト」）を書くための非常に厄介な方法

@wstaelens私もSilverlightをとても楽しんで、それを使って12個のアプリを作成しました。 これが、私が今Uno Platform（別名Silverlight on steroids）を楽しんでいる理由です。

XAMLがあれば、Silverlightを本当に楽しんだので、すぐにBlazorに移行すると思います。
HTML / Javascriptコーディング==コード（別名「スクリプト」）を書くための非常に厄介な方法

@wstaelens私もSilverlightをとても楽しんで、それを使って12個のアプリを作成しました。 これが、私が今Uno Platform（別名Silverlight on steroids）を楽しんでいる理由です。

問題は、これが「公式の」マイクロソフトプロジェクトではないため、ライフタイム...サポート...何でも... blazorに必要なのはXAMLサポートだけであるということです。

問題は、これが「公式の」マイクロソフトプロジェクトではないため、ライフタイム...サポート...何でも... blazorに必要なのはXAMLサポートだけであるということです。

@wstaelens絶対に理解しました。 Unoは、Microsoftの巨人（UWP、mono、Xamarin）の肩の上に立っているものだと思います。彼らはプラットフォームをゼロから構築したわけではありませんが、多くの成熟したテクノロジーをうまく利用して非常にうまく機能しています。 先月のMicrosoftBuildでUnoが好評を博し、最近Miguel deIcazaが承認したのを見て本当にうれしかったです。

多くのC＃開発者は、HTMLやCSSではなくXAMLを使用するのが大好きです。 多くの人が、UWP / WPF / XAMLの公式のクロスプラットフォームサポートを望んでいました。 Imo Microsoftは、BlazorでもXAMLをサポートする必要があります。 XAMLの公式クロスプラットフォームサポートはいつ提供されますか？

私自身はC＃のファンですが、Web開発とElectronに関する私の問題はJavascriptではありませんでした。 CSSです。

HTML / CSSの代替手段を提供していない場合、Blazorのポイントは何ですか？ HTML / CSSの代わりを見つけるのがとても難しいのはなぜですか、クロスプラットフォームのXAMLがとても難しいのはなぜですか...私はそれを理解していません。 マイクロソフトは常に機会を逃しており、賢明でない決定を下しています。

XAMLがクロスプラットフォーム（Microsoftによって公式にサポートされる）になる日、それはBlazorがすべてのC＃開発者の完全なサポートを得る日です。 まあ、少なくとも私にとっては... Blazorの本当の利点が見当たらないからです。 私はまだCSS、id、classを扱っているので、

私は同意しません、すべてのWeb開発者はhtmlとcssに慣れています。 htmlとcssに固執してください

@GoranHalvarssonでは、なぜJavaScriptやTypeScriptに慣れていないのでしょうか。

私は同意しません、すべてのWeb開発者はhtmlとcssに慣れています。 htmlとcssに固執してください

残念ながら、すべてのWeb作成者が開発者であるわけではなく、一部はソフトウェアエンジニアであり、要素をページの垂直方向に中央揃えするよりもXAML / C＃を使用することをお勧めします。 これはまだHTML / CSSの謎です。 XAMLははるかに優れています。

私はシュコダとポルシェを持っていますが、私はそれに慣れているのでシュコダを運転するだけですか？ オプションとしてXamarinまたはAvaloniaがあります（MicrosoftがXamarinを所有し、WPF仕様を複製した場合）。 たぶん、MicrosoftはBlazorコミュニティに調査を出し、XAMLかHTMLかを選択する必要があるかどうかを尋ねる必要があります。

10年以上前のSilverlight開発者は、自分たちをWeb開発者と見なしていました。 iOSとAndroidがプラグインを許可しないことを決定したという理由だけで、多くのWeb開発者は開発するためのプラットフォームがないままになりました。

@GoranHalvarssonすべてのWeb開発者と言えば、私たちの多くはhtmlとcssに慣れていますが（そうしなければならないため）、XAML / C＃を好みます。 Web開発者コミュニティを代表して話すことはありません。 だから私たちが何に固執すべきかを教えてはいけません。

そして、開発者が複数のテクノロジーを利用できるようにすることの何が問題になっていますか？

私はWebプロジェクトにHTML、CSS、JavaScriptを幅広く使用してきました（最近はJavaScriptをできるだけ避けようとしています）。
リッチインターネットアプリケーション（RIA）またはシングルページアプリ（SPA）に関しては、XamlとC＃が王様と女王様です。 私は他の選択肢を取りません。
私は、誰もが持っているわけではない贅沢である、課せられたプラットフォームの影響を受けない幸運な人の一人であることを認めなければなりません。

最近、TelerikとSyncFusionを使用してBlazor Project SSB（まだCSBを使用していません）を完了しました。 C＃の経験は素晴らしかったです！ JavaScript / html / CSSは苛立たしいものでした。 ほとんどのサードパーティ製コントロールには、CSS内にほとんどのバグがあるようです。 このように大規模なSPAをATMで構築したくない場合は、維持するのが面倒です。

過去に、私はXAML / C＃の豊富な経験があります。 すべてを1つの屋根の下に置くことで、開発がより速く、より信頼できるだけでなく、より楽しくなると言わなければなりません。

個人的には、クロスプラットフォームである限り、XAML / C＃サポートがブラウザーにない場合はそれほど気にしません。 新しい技術に移行する簡単な方法で、技術スタックに継続性を持たせることもおそらく同じくらい重要です。 過去の最大の問題の1つ（Silverlightは別として）は、サードパーティのORMソリューションの使用に関するものでした。可能な限り、マイクロソフトがサポートする技術を常に使用することをお勧めします。

Microsoftがクロスプラットフォーム/ WASMサポートをWPFとWinFormsに追加した場合、問題は解決されます。 もしそうなら、私はおそらく二度とBlazorを使うことはないでしょう。なぜなら、私たち全員がオプションとして究極の解決策を持っているからです。