官方解释BlazorBlazor允许您使用c#代替JavaScript构建交互式webUI。Blazor应用程序由使用C#、HTML和CSS实现的可重用WebUI组件组成。客户端和服务器代码都是用C#编写的，允许您共享代码和库。Blazor是一个使用.NET构建交互式客户端WebUI的框架：使用C#而不是JavaScript来创建交互式、信息丰富的UI。共享用.NET编写的服务器端和客户端应用程序逻辑。将UI呈现为HTML和CSS以支持各种浏览器，包括移动浏览器。与Docker等现代托管平台集成。使用.NET的客户端Web开发提供了用C#而不是JavaScript编写代码的优势。利用现有的.NET库生态系统。在服务器和客户端之间共享应用程序逻辑。受益于.NET的性能、可靠性和安全性。在Windows、Linux和macOS上使用VisualStudio保持高效。建立在一组稳定、功能丰富且易于使用的通用语言、框架和工具之上。看到这里有些小伙伴手里的瓜都快要吐出来了，确实有些夸张，至少VS在三个平台上高效运行，嗯。..继续吃瓜BlazorVsMVC官方对MVC的解释是什么：ASP.NETCoreMVCisarichframeworkforbuildingWebapplicationsandAPIsusingthe"Model-View-Controller"designpattern.圈子的重点是，Blazor是一个交互式的WebUI，而MVC是一个Web应用程序和API。什么是交互式WebUI？谷歌和百度绕了过去。没有这个解释，连Wiki都糊涂了。尝试理解，交互式WebUI侧重于交互，而Blazor官方的解释是使用C#而不是JavaScript，那我们看看JavaScript有什么功能，我从百度上找了一段：在HTML页面中嵌入动态文本来做浏览器事件阅读并编写响应验证数据的HTML元素，以在数据提交到服务器之前检测访问者的浏览器信息。控制cookies，包括创建和修改等。有了这些基本功能，用户就不用在静态页面里跳来跳去了。确实，体验会好很多。Blazor有什么优势？它提供了一些交互能力，不再是纯静态页面，虽然MVC可以使用JavaScript实现同样的效果，但是你需要掌握JavaScript，甚至还要学习jQuery、Angular、Vue等。Blazor提供的交互能力使用C#。吹完了，但是你真的能100%C#吗？很难，兼容性，性能等等各种问题，好吧，那我可以不使用吗？等等，下面有瓜子Blazor与现代前端（Angular、Vue等）的对比。我们从几个方面来比较一下。在非复杂场景下Vite几乎可以实现HotReload，但是奇葩问题太多，前景非常好。目前比较好用的是Ctrl+F5启动或者使用命令行。VS2022的Ctrl+F5已经支持HotReload现代前端：Webpack/Vite全家桶以Vue为例，Vue全家桶包括VueCli、VueRouter、VuexBlazor：Cli:dotnetcliRouter:Microsoft.AspNetCore.Components.Routing.RouterVuex：Blazor状态管理，区别在于WASM状态保存在浏览器的内存中，而Server保存在服务器的内存中。而且，Blazor更强大的状态管理是.Net原生支持持久化存储、跨行存储（Server下共享服务器内存）、ASP.NETCore保护浏览器存储（Server独享功能）组件库主流Bootstrap、AntDesign、MaterialDesign等都有两面性。但是由于现代前端多年的积累，在质量上确实存在一定的差距。除了丰富之外，Blazor还允许通过JavaScript调用加载它并生成Angualr和React等组件。虽然这看起来和用C#代替JavaScript有点冲突，但也有利于融入更大的环境React中复用的BlazorComponent其实是支持HotReload的。先不说HotReload是个什么样子，光是这个方向其实就很值得期待HotReload的未来。不仅可以为React提供可重用的组件，还可以为WPF第三方库提供几个前端常用的库进行对比。网络：现代前端有axios，Blazor有HttpClient数据操作：现代前端有Lodash，Blazor有Linq时间：现代前端有moment。Blazor有Rx.Net（没用过，理论上.Net基本可以用，欢迎指正）Mock：现代前端有Mock.Js，Blazor有Moq，当然除了mock还有end-到结束，双方也有。相比之下，.Net其实还是有一些优势的，是不是就完美了呢？当然不是，说说缺点吧。Charts：现代前端有ECharts等，Blazor不想多说。虽然Blazor没有成熟免费的Charts组件库，但是因为Blazor可以和JS交互，调用ECharts也非常简单。一点考验小伙伴的动手能力文本编辑，拖拽。..布拉佐骂了一句，退出了群聊。..包管理Blazor:NuGet现代前端:NPM,Yarn性能数据不直观，看一下.NetConf2021上的demo截图：有量化数据吗？是的：视频地址：https://sec.ch9.ms/ch9/daba/4...AOT能解决所有的烦恼吗？也不是。至少在应用规模上，确实要大很多，但这并不妨碍AOT能够解决特定场景下的问题。技术总是选择在合适的场景中使用它，而不是盲目地使用它。结束了吗？当然不是。事实上，这种比较对Blazor是不公平的，因为Blazor在.的肩膀上有更多的亮点。Come.Net类库、跨平台应用（MAUI）等。其实没必要只看Blazor的劣势，更要看.Net前端能走多远。这不正是我们所期待的吗？看到这里，一些.Net古董大佬们要出声了，Silverlight！是的，但这次WASM不再要求下载插件。WebAssemblyVsServer（服务器端渲染）WebAssembly：WebAssembly是一种可以在现代网络浏览器中运行的新编码方式——它是一种低级类汇编语言，具有可以接近原生的紧凑二进制格式，并为C/C++等语言提供了编译目标，使其可以在Web上运行。它还被设计为与JavaScript共存，允许两者一起工作。服务器端（ServerSideRender-SSR）：在服务器端将组件渲染为HTML字符串，直接发送给浏览器，最后在客户端“激活”这些静态标记作为完全交互的应用程序。为什么使用SSR服务器端渲染（SSR）的优势主要是：更好的SEO，因为搜索引擎爬虫可以直接查看完全渲染的页面。更快的内容到达时间(time-to-content)何时使用SSR使用服务器端渲染(SSR)时有一些权衡：开发条件有限。只能在某些生命周期钩子函数（lifecyclehook）中使用的浏览器特定代码；某些外部扩展库（externallibrary）可能需要特殊处理才能在服务器呈现的应用程序中运行。涵盖构建设置和部署的更多要求。与可以部署在任何静态文件服务器上的完全静态单页应用程序(SPA)不同，服务器呈现的应用程序需要服务器端运行时环境。更多的服务器端负载。服务器端渲染与预渲染（SSR与预渲染）如果您研究服务器端渲染(SSR)只是为了改进一些营销页面（例如/、/about、/contact等）的SEO，那么您可能需要预渲染。与其使用Web服务器即时动态编译HTML，不如使用预渲染在构建时简单地生成特定于路由的静态HTML文件。优点是设置预渲染更容易，并允许您将前端作为一个完全静态的站点。BlazorServer支持PrerenderingBlazor，你应该选择WebAssembly还是Server？看.NetConf2021大会上的一张图：总结一下：服务器必须保持长连接并且有更高的UI延迟。WebAssembly下载量较大，运行时性能较慢我们正在做的是另一个老生常谈的问题，.Net的覆盖范围太广，很难解决所有问题。权衡利弊后，能否为.Net生态做出自己的小小贡献呢？开源组件库回归组件库。目前市面上其实有不少组件库。为什么要继续在这个泥潭里插足？开发过组件库的同学，或者贡献过源码的同学应该都知道写一个组件是多么的复杂。每个人对设计都有不同的审美观点。当你喜欢的设计没有提供实现时怎么办？从头开始写，太累了，所以我们尝试了一种方法。先看大体思路：简单分析：在Blazor的基础上，构建一个新的组件库，叫做BlazorComponent，它有什么特点？只提供交互，不提供样式标准化的Dom结构开放几乎所有可定制的Slots（slots，概念引用自Vue），让你替换Domslots的统一单元测试和Slots的交互（目前38%，短期）goal是80%，长期目标是90%+）基于MaterialDesign的示例项目（样式引用自Vuetify）可以实现生产可用性（我们自己公司在用，也被世界500强企业）快速实现新组件库只需要基于一定的设计+样式控制属性+特殊交互即可。未来值得期待。我们希望未来是这样的：惭愧，流行了一波。MASABlazorBlazor基于BlazorComponentandMaterialDesign组件库目前共有68个基础组件，未来会不断增加预设组件，提供与.Net功能的深度集成和常用的组合组件，如Url、面包屑、菜单三联动、高级搜索、i18n等。MASABlazorPro提供各种常用场景的预设布局，由专职团队维护。问题快速响应知名公司。未来也将一直沿用MASAStack产品线。将继续免费和开源地添加新功能。未来我们还计划支持一键切换主题（代码切换已经提供）、预设布局、数据展示组件、WorkFlow组件等。MASABlazorPro基于MASABlazor提供的管理模板。先放几张设计稿，源码会和MASABlazor一起放出来。MASAEShop基于MASAFramework构建的EShopOnDapr将使用MASABlazorPro提供完整的前后端示例。那么用在合适的场合才是最合适的。不管是春天还是冬天，重要的是能不能解决你此时此刻的痛点。最后，MASABlazor的小广告即将放出，敬请期待，如果您对我们的组件库感兴趣，无论是代码贡献、使用还是问题，请联系我们参考https://dotnet.microsoft.com/...https://docs.microsoft.com/zh...https://sec.ch9.ms/ch9/daba/4...https://developer.mozilla.org...https：//ssr.vuejs.org/en/
