Aspnetcore: XAML 代替 HTML 和 CSS

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

对于 Blazor，我们的目标是 C#、HTML 和 CSS，但对于 XAML，您可以查看Ooui 。

@danroth27

对于 Blazor，我们针对 C#、HTML 和 CSS，但针对 XAML

我不是说你停止使用 HTML 和 CSS。 我说如果我们愿意，请给我们选择 XAML 的选项。 我知道有一个网络社区，但也有想要编写网络应用程序的 .NET 桌面社区。 请考虑他们。 尽管我在过去的 15 年里努力阅读和学习 ASP.NET，但我自己还是讨厌 ASP.NET！ 相反，我发现 XAML 很有吸引力、功能强大且易于学习。 本来希望银光能主宰进化成微软文科技，结果在2012年就夭折了！
我希望你能考虑这个建议，即使你把它命名为 Xlazor :)

你可以看看Ooui的XAML。

我不依赖如此大规模的第三方产品，因为我不承认它们会持续和发展，所以如果第三方产品死了可能会错过所以我需要重写使用它的大型项目！

@MohammadHamdyGhanem Blazor 和 Ooui 是基于 WebAssembly 的独立产品，就像 .NET 基于 .NET Framework 一样。 这两者都是必要的，因为有喜欢 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。

我说微软应该制作一个 XAML 标准 API（如 .NET Standard），它应该被 Xamarin、UWP 和 ASP.NET 遵守，无论什么剃刀名称，或者扩展 .NET Standard 以包含它。
无论底层实现如何，控件及其属性和方法都应该具有相同的名称。 这将使所有这些组件更容易学习，并使大部分代码可重用。

@MohammadHamdyGhanem他们是我认为......这是它的

那是一种解脱。 谢谢。

xamarin.forms 的性能不如原生 anroid 或 ios 应用程序，它适用于应用程序或云连接应用程序上的 statis 内容，但如果你真的想要与 OS apis 深度集成并且需要原生性能 xamarin 不那么高性能，加上工具xamarin.native 很糟糕，

我继续并开始构建一个在浏览器中本地运行的 Xaml 引擎。 你可以在这里查看： https :

XAML 必须是一个选项。 不知道Asp.Net 团队对XAML 熟悉多少。 团队正在花时间重新创建轮子。 就像最近的Community Standup一样，他们展示了如何在 Blazor 中创建组件。 我说为什么？ 以及为什么我必须学习编写组件的新方法。 你有 XAML，它非常适合所有这些事情。

有数千个 JS 框架，如 VUE、Angular、React，它们有助于数据绑定。 而 XAML 是第一个做到这一切的。 至少试一试吧。

我们熟悉 XAML，但我们使用 Blazor 的主要目标是针对 Web 开发人员，因此我们坚持使用 HTML 和 CSS。 也就是说，已经有各种努力在 WebAssembly（Ooui、Uno、FrogUI）上构建对 .NET 的 XAML 支持，因此如果 XAML 是您的偏好，我们建议查看这些项目。

@danroth27
我看到 MS 必须在 XAML 剃刀上工作才能保存 VB.NET。 在我看来，ASP.NET 是导致 VB.NET 流行度在过去十年下降的原因之一。 VBScripts 只能在 Internet Explorer 中运行，所以它生来就死了，任何 Web 开发人员都只能使用使用 C-Like 语法的 JavaScript，所以它更容易与 C# 一起使用，而不是与 VB.NET 一起使用。 多年来，JavaScript 框架不断涌现，MS 对其中的一些框架进行了调整，例如 JQuery 和 Angular。 TypeScript 也是一些高级 JavaScript。
这使得 C# 成为初学者唯一合乎逻辑的选择，甚至迫使许多 VB.NET 开发人员迁移到 C#。
所以，Xaml blazoer 有两个目标：

1. 吸引 c# 桌面开发人员。 Ocertime 它会杀死 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; }
}

现在想象在我的第三个组件 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您是否按照自己的意愿查看了基于 Xaml 的类似平台 - Platform.uno - 正如前面@danroth27 所提到的？

如果它有 XAML，我想我们会立即转向 blazor，因为我们真的很喜欢 Silverlight。
HTML/Javascript 编码 == 非常烦人的代码编写方式（又名“脚本”）

如果它有 XAML，我想我们会立即转向 blazor，因为我们真的很喜欢 Silverlight。
HTML/Javascript 编码 == 非常烦人的代码编写方式（又名“脚本”）

@wstaelens我也非常喜欢 Silverlight，并用它制作了十几个应用程序。 这就是为什么我现在很享受Uno Platform（又名 Silverlight on steroids）的原因。

如果它有 XAML，我想我们会立即转向 blazor，因为我们真的很喜欢 Silverlight。
HTML/Javascript 编码 == 非常烦人的代码编写方式（又名“脚本”）

@wstaelens我也非常喜欢 Silverlight，并用它制作了十几个应用程序。 这就是为什么我现在很喜欢 Uno Platform（又名 Silverlight on steroids）。

问题是这不是一个“官方”微软项目，所以生命周期......支持......无论如何......blazor只需要XAML支持。

问题是这不是一个“官方”微软项目，所以生命周期......支持......无论如何......blazor只需要XAML支持。

@wstaelens完全理解。 我认为 Uno 是站在微软巨头肩膀上的东西——UWP、mono、Xamarin……他们没有从头开始构建平台，而是巧妙地利用了许多已经运行良好的成熟技术。 我真的很高兴看到 Uno 上个月在 Microsoft Build 上受到好评，并且最近得到了 Miguel de Icaza 的认可。

许多 C# 开发人员喜欢在 HTML 和 CSS 上使用 XAML。 很多人想要官方的 UWP/WPF/XAML 跨平台支持。 Imo Microsoft 也应该使用 Blazor 支持 XAML。 我们什么时候才能获得对 XAML 的官方跨平台支持？

我自己是 C# 的粉丝，但我在 Web 开发和 Electron 方面的问题从来都不是 Javascript。 它是 CSS。

如果 Blazor 不提供 HTML/CSS 的替代方案，它的意义何在？ 为什么找到 HTML/CSS 的替代品如此困难，为什么跨平台 XAML 如此困难......我只是不明白。 微软总是在错过机会并做出不明智的决定。

XAML 成为跨平台（由 Microsoft 正式支持）的那一天，也就是 Blazor 获得所有 C# 开发人员全面支持的那一天。 好吧，至少对我来说不是……因为我看不到 Blazor 的真正优势。 因为我还在处理 CSS、id、class，

我不同意，所有 Web 开发人员都习惯于 html 和 css。 请坚持使用 html 和 css

@GoranHalvarsson那么为什么他们不习惯 JavaScript 或 TypeScript？

我不同意，所有 Web 开发人员都习惯于 html 和 css。 请坚持使用 html 和 css

不幸的是，并非所有网络作者都是开发人员，有些是软件工程师，我们更喜欢 XAML/C# 在页面上垂直居中元素。 这在 HTML/CSS 中仍然是个谜。 XAML 要优越得多。

我有一辆斯柯达和一辆保时捷，但只是因为我习惯了才开斯柯达？ 有 Xamarin 作为选项或 Avalonia（如果 Microsoft 拥有它并且它复制了 WPF 规范）。 也许微软应该向 Blazor 社区进行一项调查，并询问他们是否必须选择一个——XAML 还是 HTML？

10 多年前，Silverlight 开发人员认为自己是 Web 开发人员。 仅仅因为 iOS 和 Android 决定不允许插件，许多 Web 开发人员就没有开发平台。

@GoranHalvarsson当您说所有 Web 开发人员时，我们很多人都习惯于 html 和 css（因为我们必须这样做），但更喜欢 XAML/C#。 您不代表 Web 开发人员社区发言。 所以不要告诉我们应该坚持什么。

为开发人员提供多种技术有什么问题？

我在 Web 项目中广泛使用了 HTML、CSS、JavaScript（我现在尽量远离 JavaScript）。
当谈到富 Internet 应用程序 (RIA) 或单页应用程序 (SPA) 时，Xaml 和 C# 是王者和王后。 我不会采取任何其他选择。
我不得不承认，我是幸运的人，不受任何强加平台的约束，这种奢侈不是每个人都拥有的。

我最近使用 Telerik 和 SyncFusion 完成了 Blazor 项目 SSB（我还没有使用 CSB）。 C# 体验很棒！ JavaScript / html / CSS 很烦人。 似乎大多数第三方控件在 CSS 中都有最多的错误。 您不会希望以这种 ATM 方式构建大型 SPA，维护起来会很痛苦。

过去我有丰富的 XAML/C# 经验。 我必须说，将所有内容集中在一个屋檐下使开发不仅更快、更可靠，而且更令人愉快。

就个人而言，只要 XAML/C# 支持是跨平台的，我就不太在意浏览器是否支持 XAML/C#。 在技​​术堆栈中保持连续性可能同样重要，通过简单的方法迁移到更新的技术。 过去最大的问题之一（将 Silverlight 放在一边）是使用第三方 ORM 解决方案，我的建议是尽可能坚持使用 Microsoft 支持的技术！

如果微软为 WPF 和 WinForms 添加了跨平台/WASM 支持，这个问题就会为我解决。 如果是这种情况，我可能永远不会再使用 Blazor，因为我们都有最终的解决方案作为选择。