加载失败
Avalonia 宣布推出 MAUI 后端，意味着现有 MAUI（微软的跨平台 UI 框架）代码可以在 Avalonia 支持的目标上运行，从而补上长期缺失的 Linux 桌面与在浏览器以 WASM 运行的能力。评论者基于两个前提出发：其一，MAUI 本质上是移动/桌面优先的框架，不是面向 Web 的解决方案；其二，把桌面 GUI 绘制为浏览器内的像素画会丢失 DOM 语义和无障碍支持。讨论围绕可访问性、演示与性能问题、Avalonia 为遗留 WPF 迁移带来的实际价值，以及是否应采用 Blazor/DOM-first 或其他替代方案来实现“真·Web”体验展开，同时也有关于渲染后端（Skia/Impeller/Graphite）的技术争论。
多位评论者指出 Avalonia 在浏览器端通过 Canvas/WASM 像素化渲染 MAUI 应用，会丧失 DOM 语义导致一系列问题：无法 Ctrl+F 查找、无法选择/复制文本、无法复制超链接地址、手机长按分享失效、屏幕阅读器无效以及 IME（输入法）支持欠缺。有人将这种“页面内像素岛”直接类比为 Silverlight/Flash，认为它们对搜索引擎、浏览器原生功能和无障碍工具是“不可见”的。尽管理论上可用透明 DOM 元素或 ARIA 手工映射来补救，但评论指出这既易错又可能带来性能损耗，整体上难以达到“真实网页”级别的可访问性体验。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
多个评论报告在线演示加载很慢（有的超过一分钟），交互体验糟糕：滑块拼图拖拽不稳定或卡死、随机化时返回导致页面锁定、计算器出现错误、点击不响应并能把标签页卡住或锁死。WASM 包体与 Canvas 单元素结构让首屏加载变慢、DevTools 与浏览器插件调试受限，离线或带宽弱环境尤为糟糕。这些具体缺陷让评论者认为当前实现更像是“技术 demo”而非可用于生产的 web 体验。
不少人强调 .NET MAUI 是为移动/桌面（iOS/Android/macOS/Windows）设计的框架，并非 web-first。Avalonia 把 MAUI 渲染到 WASM/Canvas 上，会把桌面 GUI 直接搬到浏览器，评论把这类做法称为“现代版 Silverlight”：技术上可行但破坏了网页原生语义與工具链，因此难以替代标准的 web 开发路径。针对网页目标的建议是使用 Blazor 或把渲染映射到真实 DOM，而把 MAUI+Avalonia 更多看作补全 Linux/桌面平台的方案而非 Web 的长期解决方案。
评论里许多人称赞 Avalonia 在跨平台尤其是 Linux 桌面上的价值：它能让大量 WPF/XAML 项目以较少改动迁移到 macOS、Android、iOS 甚至通过 WASM 展示。实测经验显示 Avalonia 安装与上手体验优于 MAUI，能快速实现诸如无边框/置顶窗口等特性，适合企业将遗留 Windows GUI 进行现代化改造。Avalonia 采用 Skia 渲染并在讨论接入 Impeller，以提升 GPU 性能，这令它在图形密集型桌面应用上具有吸引力。
评论普遍提到微软在 UI 技术栈上长期分裂（WinForms、WPF、UWP、WinUI、MAUI 等并存），且常常不在自家重要产品上“自用”新框架（例如 Teams 用 Electron/WebView2），这导致开发者对 MAUI 的长期支持和投入产生怀疑。历史上的若干重构、裁员与 MAUI 团队资源被诟病，使许多人担心微软可能不会稳固支持该框架。因此在企业级决策中，不少人倾向于选择社区成熟或被广泛采用的替代方案而非完全依赖微软新框架。
有经验的评论者建议若目标是第一类 Web 体验，应优先把渲染映射到真实 DOM（或采用 Blazor、Dioxus 等 DOM-first 框架），以保留可选文本、可访问性与浏览器功能。对于跨平台桌面，常被提到的替代包括直接使用 Avalonia、Qt、Electron、Tauri、Flutter 或 Kotlin Compose Multiplatform，并根据项目在性能、打包体积和开发效率间权衡。总体共识是：WASM 很有潜力，但若不上层 DOM 语义就会重蹈 Silverlight 的覆辙，真正的 web 优先实现应避免把整页当作像素画。
技术讨论集中在 Avalonia 当前基于 Skia 的渲染与可能接入 Flutter 的 Impeller。评论引用资料称 Impeller 通过离线编译着色器与预构建 pipeline state 来减少运行时着色器编译卡顿，从而在动画与动态图形上表现更稳定；另有评论指出 Skia 的 Graphite 后端正在收敛这些优势，且 Impeller 更偏向移动场景、Graphite 更偏桌面。选择哪个渲染后端会影响帧率稳定性、动画流畅度及运行时开销，实际优劣与目标平台和工作负载密切相关。
很多开发者抱怨 MAUI 在安装、工具链和日常开发中的痛点：入门配置繁琐、XAML + MVVM 带来大量样板代码（例如为布尔取反写专用 converter）、热重载与性能调优不够成熟，某些视图在未优化时会严重掉帧。这些现实问题让部分团队转向 Avalonia、Blazor、Kotlin Compose 或其他成熟工具，以换取更稳定的开发体验和更少的调试成本。评论中也提到社区为 MAUI 做过贡献，但对维护力度与长期承诺仍表示担忧。
.NET MAUI: .NET Multi-platform App UI，源自 Xamarin Forms 的微软跨平台 UI 框架，面向 iOS/Android/Windows/macOS 的移动/桌面优先工具集，原生控件抽象为目标平台适配器。
Avalonia: 一个开源的 .NET 跨平台 UI 工具包，采用自绘（drawn）渲染（基于 Skia），支持 Linux、macOS、Windows、移动和平面上的 WASM 目标，可作为 MAUI 的后端实现。
WASM (WebAssembly): 浏览器中的低级字节码格式，允许非 JavaScript 语言运行于浏览器，适用于将 .NET、Rust 等运行时带到前端，但通常会产生较大的初始负载并需与 DOM 做互操作。
Canvas 渲染 (HTML canvas): 把界面像素化地绘制到单一画布元素上而非生成 DOM 节点，这能得更高的图形控制与性能，但会丧失文本选择、可访问性语义、浏览器原生行为及插件扩展能力。
Impeller: 由 Flutter 团队开发的 GPU-first 渲染后端，通过离线编译着色器和预构建 pipeline state 来减少运行时卡顿、提高动画流畅性，正在被某些项目评估或采用。
Skia / Graphite: Skia 是广泛使用的 2D 图形库（Chrome、Fuchsia 等使用）；Graphite 是 Skia 的一个较新后端，旨在提升桌面渲染性能并缩小与其他后端的差距。
Blazor: 微软的 Web 框架，可在浏览器通过 WASM 或服务器端渲染运行 .NET 代码，并输出真实 DOM/HTML/CSS，从而保留网页的可访问性与浏览器功能。
XAML: 一种用于描述 UI 结构与绑定的 XML 样式标记语言，广泛用于 WPF、UWP、MAUI 和 Avalonia（变体）中定义视图与数据绑定。