在职业生涯中，我只在 c# 代码库中工作过。显然，很多项目都有 js SPA 前端，但我不在那一边。
我正在涉足其他语言，我非常喜欢阅读 twitter 上的最新技术文章、文章、youtube 视频等。
最近，我越来越感到不可思议：”这是怎么回事，我在 .net 中使用这个已经很多年了，我甚至不知道没有它生态系统是如何存在的。其他人对此有何看法？
举几个例子：
我刚刚看了这个视频 https://www.youtube.com/watch?v=zB9tEQYLPL4。显然，go + htmx 已经成功地重新创建了 razor 或 blazor 模板，人们津津乐道于他们几乎做到了类型安全，这是多么疯狂。这并不是真正的类型安全，它更像 typescript，可以自动完成，但不是真正的类型安全。
我记得我读过一篇关于顶级 javascript ORM 的文章。Drizzle？人们意识到它实际上是在后台查询整个数据库，然后在其 rust 引擎中进行内存查询操作？一般来说，我不得不忽略人们所说的 “ORM不好 “的评论，因为我知道他们的ORM其实很糟糕。这充其量就像使用原始的 EF。
特别是在 javascript 中构建东西和配置。在 .net 中，它是如此简单，我甚至不知道发生了什么。它就是能运行。我在本地按下 F5，然后将其放入生产的任何管道中。Javascript 主程序只是去了 babel webpack，它们有冲突，C make，我不知道发生了什么……
几个月前，人人都在谈论 react 服务器组件，不是说它有多疯狂，就是说它对 sql 注入有多不安全。我们在 Blazor 中使用它已经有好几年了。
调试……我还需要说什么吗？有一些文章毫无讽刺意味地鼓吹打印调试而不是附加调试器。这可能是因为在其他语言中，打印调试实际上是有效的，因为在其他语言中，你不需要点击行号然后敲 F5。
我确实喜欢其他语言中的一些东西。我认为用 react 编写用户界面，按下 strg s 并立即看到结果是一件令人惊叹的事情。我喜欢…”硬编码字符串选项 “作为实际类型。我喜欢……作为实际类型的 “硬编码字符串选项”，它就像枚举，但我觉得更漂亮。我不知道这个功能到底叫什么。
我还非常喜欢 typescript 类型魔法。基于一个对象自动生成一个类型。在一行中用 2 个属性扩展该类型并使用其中一个。我很怀念 C# 中的这一功能。但总的来说，这些都是小问题，而不是 “兄弟，你是怎么存在的？一些聪明人怎么能不把 ef core 1:1 偷到 rust、go 或 js 中去呢？
我真的不知道我是否有问题。在我看来，这些所谓知识广博的开发人员似乎都缺少 .net 这一部分。这感觉就像一座奇怪的孤岛。这真的是一种浪费。
在这一点上，我觉得我们在循环往复。每个概念都会在几年内重复出现，只是实施方式和名称略有不同而已
作为一名拥有 40 多年经验的开发人员，我可以告诉你这是事实，而且已经持续了很长时间。
一直都是
🌍 🧑🚀 🔫 🧑🚀
……并将永远是 *astronautmeme*
我也有同样的经历（🖐️hello），而且完全同意。
一针见血。
我想说的是，就像古埃及人拥有钻探石油的所有工程技术，却从未发现或尝试过石油一样。或者说，特斯拉创造了无线电所需的部件（他试图传输能量），尽管他从未在空中发射或接收过任何音频信号，但却在死后获得了荣誉。
我的意思是，很多东西在泛型/模板、垃圾收集等之前就已经存在了。
现在，我们将这些东西集合到一种语言中，它们与以前相比有了很大的不同，也变得更好了。
是的，老实说–对于一个正在考虑最热门趋势的新手来说，看看像 Ada 这样的古老语言，你就会感到震惊了。:D 它于 1980 年首次发布。https://ada-lang.io/
泛型、契约设计、生命周期检查、并发类型、约束、语义类型……
你所说的 ADA 并不是 1980 年的 ADA。例如，泛型出现于 2005 年，是基于 C++ 模板的。
编辑：澄清一下。Ada的泛型出现在2007年发布的Ada 2005版本中。.NET在2005年底发布的.NET Framework 2.0中采用了泛型。
2007 年发布的 Ada 2005 版本。
Ada83 已经有了泛型，而 C++ 的 STL 就是在用 Ada 编写的早期原型基础上诞生的。
我在 20 世纪 90 年代使用的是带有泛型的 Ada
这些年发生了很多变化，尤其是在 C# 网络生态系统中。
WebForms => MVC => Core => Blazor 等等。
它们是不同的，而不仅仅是重复同样的东西。但在它们进入.NET之前，它们确实存在于其他地方。
你怎么能忘记 silverlight 呢？
我一直在努力忘记 Silverlight，但烧伤的疤痕依然存在:)
我们还在用 ie 维持一台机器的运行，只是为了运行一个授权的 Silverlight 应用程序…
创伤后应激障碍
创伤后 Silverlight 开发
没错。我们（这个行业）不断发明新方法来做上一代人已经知道如何做的事情。
如果我们有某种学徒–>技工–>工匠大师的职业发展路径，那么应用程序的开发将受益匪浅。
在 “全部在服务器上！”和 “全部在客户端上！”之间嘀嗒嘀嗒地走来走去，如果我不觉得自己像个老顽固，而我又笑着第十二次看到它的话，这一点几乎是可笑的….。
10 打印 “YUP
20 GOTO 10
不要错过
我刚看到一篇文章，说 blazor 服务器端渲染是下一个伟大的东西，等等等等……所以我们要回到服务器渲染代码……使用 razor……就像 mvc 所做的那样？15 年前…
是的，用不同的名字，就像 angular 也在做的那样……或者朝那个方向发展
我认为 Blazor SSR 最大的亮点在于组件思维和组件构建。所有东西都是组件，包括页面。
这并不新鲜，网络表格就有 .ascx 又名用户控件。经典的 Asp 有 “包含”，即 ActiveX 控件
这也不新鲜
几乎所有适合 Blazor SSR 的东西都不应该脱离 SSR。
FTW！这是 WebForms 开发的巅峰之作
你让我想起了过去，我还记得那玩意儿问世时的激动心情
Blazor 是有状态的服务器端渲染，它取代了旧式的、缓慢的 MVC 无状态服务器端渲染，后者取代了旧式的、缓慢的有状态服务器端渲染，称为 asp webforms。
这篇文章是关于 blazor webassembly 的初始 SSR 吗？
我还没来得及全部看一遍，只看了标题和摘要
一切都是一个循环。想一想：最初，所有的东西都是在单一主机上运行的。后来，我们发现这样做成本太高，而且一切都需要横向扩展，于是我们放弃了大型机。后来，我们又觉得管理所有这些机器太难了，于是我们又开始使用大型集中式服务器，尽管是运行多个虚拟机，同时使用 Citrix 等桌面。现在，我们正在用容器取代虚拟机，用……取代桌面。我不确定什么会取代思杰。尽管自动化程度更高，但我们正在慢慢回归分散化的趋势。
是的，我们正在这样做。
还记得 “Xml 是未来 “吗？
https://www.bitecode.dev/p/hype-cycles
我认为这是因为 1.我们从未足够重视问题。只关注解决方案。2.上次搬家时，想要的人不在那里。
例如，react 的出现是为了解决一个非常具体的问题–知道要更新什么的痛苦。因此，它被设计成不更新，而是重新生成。
跳上 svelte 列车的人并没有体验到这种痛苦。相反，他们看到了反应是如何需要你明确知道更新的原因的，并发现这很痛苦。于是，他们制作了一个编译器来解决这个问题。
然后他们发现，要做到这一点并不总是那么容易。因此，他们引入了信号，以明确哪些因素会导致变化。
因此，这与其说是一个圆，不如说是一个来回摆动的钟摆。我只是想知道它是如何在中间的某个地方停顿下来的，但只要有新人加入，有旧人退出，我想每一代人都会重新发现过去的痛苦。
快到 30 了。让我感到惊讶的是，便携式存储的战争已经平息。旋转软盘、固态存储、大型/小型、密度不断增加。我以为战争会升级，直到每个人的钥匙链上都有 5 TB。但我没想到，人们会在需要的时候，在 3 分钟内下载 100 GB 的文件。然后将其丢弃，以后需要时再下载。如果是企业需要，你可以计算一下，按需下载比存储更便宜。
是啊，我们又回到了数据集中的时代，就像在大型机和哑终端时代一样。我在想，这是否就是为什么消费级存储的价格没有像 10-15 年前那样下降的原因。固态存储是最近唯一价格下降的产品。
让我感到惊讶的是，便携式存储的战争已经平息。
我想说，这也是一个不断来回摆动的钟摆。在早期的 Unix 时代，你会有一个连接到分时系统的哑巴 “终端”。后来，家用电脑开始流行。然后，Sun 试图建立 “网络计算”。然后，个人电脑变得越来越强大。现在，我们称之为 “云”。但智能手机也变得更加强大。
一些公司可以从租赁计算资源和存储容量的订阅服务中获益，而另一些公司则可以从人们直接购买本地资源和容量中获益。
LINQ 和泛型使 C# 领先于许多语言，而其他语言仍在追赶。
LINQ 在其他语言中的缺失真的伤害了我学习它们的意志。
每次使用其他语言时，我都会立刻感受到没有 LINQ 的沉重。作为一个 Rust 爱好者，我觉得它是功能最齐全的，但又不完全是。PHP 得到了 Laravel Collections 库，感觉与 LINQ 很接近，但还不够。围棋……也许有一天会有，但我不会屏住呼吸。
如果我们能得到总和类型、标记联合和错误值类型，我想我就没有理由再使用其他语言了。
其他语言是如何解决与泛型相关的问题的？ 都是工厂方法吗？
是的。在 1.16/17 版本之前，围棋就是这样的，那还是去年的事。地鼠对代码的编写方式（简洁性等）很有主见，对增加泛型的反应也是褒贬不一。在此之前，你必须为每种类型编写自己的列表代码。我并不精通此道，但我对从一开始就没有使用泛型感到惊讶，而且普遍认为泛型在地鼠圈中并不受欢迎。
保持代码简单，以便软件可靠性工程师能快速排除故障，是 go 的最初目标。源于 C++ 的泛型（又称模板参数）可能给最初的设计者留下了伤痕。试图理解一套你从未见过的 C++ 泛型模板可能需要一些时间……从 SRE 的角度来看，这是非常糟糕的。
花了整整一个工作日用 scala 映射 kafka 流……用了一大堆抽象和工厂…我很庆幸自己主要在 go 中工作……scala 代码几乎转换成了 main.go 文件中的 for 循环。
有相当多的语言拥有比 C#”更好 “或 “更强大/更灵活 “的泛型，但它们通常并不附带语言的某些控制功能，也无法与 dotnet 运行时相提并论。
在其他语言中也存在类似于 linq 的东西，只是很难对这些实现进行比较，因为你最终也会被归入其他功能的比较中。
LINQ 在 C# 中如此出色是因为 LIN 部分（语言集成查询）。
Java 的流就像没有语言集成的 LINQ，因此笨重得要命。
就 Java 而言，以我过时的经验来看，它与 C# 并无太大区别。可能有一些细微的差别我不记得了，但如果我没记错的话，共同点比不共同点多。
Java 其实没有泛型，只是编译器的一个小技巧。如果你问 Java 中的集合是什么类型，它每次都会说是集合。
这意味着你无法使用很酷的技巧，比如创建一个 T AddNew() 方法，因为在 JVM 看来，T 始终是对象。
有道理。我大概有十年没碰它了（希望以后也不会再碰），但我记得它的边缘有一些毛刺。谢谢你的解释。
我听说甲骨文公司想解决这个问题，但我不知道这是否还在他们的路线图上。
他们可能还没想好如何对该功能进行掠夺性定价。
是的，Project Valhalla（瓦尔哈拉计划）已经存在了 8 年左右，但我不知道何时或是否会将其添加到 Java 中。Loom 项目最后确实有了结果，所以 Valhalla 项目也许也会有结果。
甲骨文不再明确维护 java。
这就是所谓的 “类型擦除”（type erasure），.net 1.0 团队为了在最后期限前完成发布，不得不明确决定不这么做。从根本上说，他们决定将泛型的发布时间推迟到 3.0（？），以便能够完全支持泛型，而不是像 Java 那样采用擦除黑客技术。MSIL 的定义本质上就支持泛型，.net 中的数组也一直支持泛型。有点意思。
从根本上说，他们决定把泛型的发布时间推迟到 3.0 版（？
2.0.
微软研究院及时推动了正确的方法，这也算是一种运气吧。
Java 有泛型。JVM 有诀窍。
没错。但 Java 支持泛型中的通配符，而 C# 不支持。https://docs.oracle.com/javase/tutorial/extra/generics/wildcards.html
我发现从 Linq 来的 Java 流在使用上很不方便。一旦一个流被终止（例如通过 ToList()），你就不能再使用它，必须从源头重新创建它。与 Linq 这种顺畅的生产力三文鱼相比，感觉就像一个笨拙的附加组件，在上游欢快地游来游去。
它们可能有点笨拙，但并不是一种新的语言特性。所有的 java 流都只是 java 语言中的代码，并没有为它们添加新的语法。因此，它们是在与 Linq 不同的条件下产生的。它们的功能没有那么强大，但也不需要在语言层面上做任何改动。
在 Java 中，泛型被编译掉了，所有列表等在运行时实际上都是 list<object>
这似乎不是个好主意 😀 尤其是对堆栈类型而言
在我看来，类型擦除是 Java 泛型的原罪。他们选择了 JVM 的向后兼容性，却牺牲了开发人员的可用性和类型的固有安全性（不得不使用辅助方法和转换）。我真的认为 MSFT 的决定是正确的：有了类型擦除，像 LINQ 这样的东西就变得难上加难了。
不会吧？我一定是忘得太多了，或者我一开始就不知道这些东西。
从 C# 来的 Java 泛型太让人头疼了，因为运行时会丢失类型。
真的吗？
尤其是包含在 Linq 中的 Expression<T> 部分。Linq中包含的Expression<T>部分，它在很多库和BCL中都有使用，因为它允许你基本上保存一个AST，这样库就可以对它进行解析和处理（例如，EF将其转换为SQL，测试库进行强类型反射等……）。
还有运行时编译，表达式非常棒！
不过，函数式语言和 Lisps 早在 80 年代就有了懒序列。
LINQ 主要基于 Smalltalk 和 Common Lisp 集合，受到后来 Haskell 工作的影响，参见 Erik Meyers 在 .NET 上的工作。
https://github.com/ahmetb/go-linq 已经有 3 年没有动过了，但在使用泛型之前有过一次不错的尝试，但现在我们有了泛型，所以谁知道呢？
对我来说，.Net 领先的地方不是语言特性或性能。.Net在这些方面一点也不差，而且仍然相当出色。
但在开发人员体验方面，与其他主流语言相比，.Net 在调试、配置和部署方面要容易得多，这在我看来是极其片面的。有些语言在这方面也做得很好，但这个生态系统在很多方面都让它变得轻而易举，我再也不能在使用其他平台时不时面无表情了。
最近我最喜欢遇到的情况是 ThePrimeagen（我很喜欢他）和另一位开发者在流媒体上讨论技术问题。现在他们都讨厌微软和与之相关的一切。这两个家伙津津乐道于 Rust（我也很喜欢 Rust）的后端框架如何 “自动 “将 JSON 转换为类型化对象…..。我喜欢
这样的 YouTube 对任何事情都很极端。无论是正面的还是负面的。我不会想太多。
我不这么认为。当微软还是业内最令人讨厌的公司时，你的第一份糟糕工作就是 C#，这完全在意料之中。我也要给你点赞
人们还停留在上世纪 90 年代，甚至没有注意到 Goog 和 Oracle。
(说真的，从昨天 Epic/Fortnite 的裁决中，我们可以看到 Goog 的一些真正的 MS 1990 年代玩法，那种 “不作恶 “的立场已经一去不复返了）。
谷歌 2020 就是微软 1990。微软 2020 就是谷歌 1990。
怎么了？
Google Play 商店的反市场竞争行为。
谷歌被曝强势迫使 OEM 厂商不与 Epic 合作，在 Android 设备上捆绑免 Google Play 的《堡垒之夜》。
ThePrimeagen 在流媒体上说，在他作为开发者的起步阶段，他曾使用过 C#，但他不喜欢它，他也不喜欢微软，就像社交媒体上绝大多数谈论软件开发的人一样，而不仅仅是优酷或流媒体上的人。
我喜欢 c#，但我仍然讨厌微软。
我从不说我恨微软，但有时我不同意他们的商业选择。
仍然喜欢 C#
(这来自一个普通的 Python 开发人员）。
我明白为什么人们会讨厌微软。特别是如果你是在 20 世纪 90 年代开始职业生涯的老开发人员。但我不明白 C# 背后的仇恨。尤其是现在。它是入门门槛最低的语言之一。我做过很多 Java 工作，我知道仅仅在本地机器上建立一个简单的 Java 项目就需要付出多少努力。尤其是网络应用程序。即使是像 spring boot 这样的东西，你也必须设置和安装大量的垃圾。有了 C#，我只需启动 rider 或 VS，就能在几分钟内试用一些概念验证应用程序。
这样的youtube用户对任何事情都很极端。
点击、点击、点击
愤怒诱饵 = 观看次数 = 钱
滑稽的是，微软是 Rust 的最大采用者之一，也是第二大企业支持者。
他们正试图用 Rust 重写来替换 Windows 中有问题的部分，以确保其安全性。我认为他们的目标是让 Rust 慢慢地一口一口地取代 Windows，使 Windows 更安全。
太棒了
等等，真的吗？
https://www.reddit.com/r/rust/comments/12yg3cp/microsoft_rewriting_core_windows_libraries_in_rust/?rdt=56750
在所有大型科技公司中，微软也是迄今为止对开源贡献最大的公司（无论是在工程师工时还是直接资金方面）。去他妈的微软，但他们是所有大公司中最不差钱的。
但甲骨文还不错吧？对不对？
很少有公司拥有如此庞大的 C/C++ 代码库，而这些代码库在未来数年内还需要继续使用，因此减少这些遗留问题将带来回报。
有道理。Rust 并不是 C# 的真正竞争对手，但在可靠的本地编译代码方面，它却在 C++ 的屁股上踢了一脚。
我认为微软长期以来一直在寻找 C++ 的替代品。
从我听到的一点消息来看，我认为微软是唯一一家在主流软件上采用 “铁锈 “技术的大型科技公司。Windows。
AWS 上有很多服务
但我听说 AWS 在正常运行方面遇到了很多麻烦
prime 真的很酷，但我完全不理解他对 c# 的憎恶。他还喜欢 ocaml，我想如果他学了 f# 一定会疯掉，但我想这是各取所需吧
当 ThePrimagen 在直播中不知道 Power BI 是什么的时候，对我来说就是一个信号，就好像。好吧，没人什么都懂。
我真羡慕他….
哈哈哈，对吧？他肯定在自己的小气泡里。
如果他们看到 F# 类型的提供商，他们会失去理智的
公平地说，当他看到 C# 代码时，他说他喜欢它，而且他的很多观点客观上都是正确的。
我觉得他对微软的憎恨多半是装腔作势，但他是一个精通 javascript/C/Rust 的人，所以他对这方面的知识可以信手拈来。
我不知道 ThePrimeagen 是谁，但用 Rust 做 ser/de 完全不需要后台框架。整个生态系统都是基于 serde 构建的。serde 最酷的地方在于它没有任何模板，而且适用于任何序列化格式，而不仅仅是 JSON。
rs
[派生（序列化、反序列化）] (derive(Serialize, Deserialize))
struct Foo { // …字段 …}“`
搞定。现在，你可以序列化和反序列化 TOML、YAML 和二进制格式，你说得出来。由于 serde 如此广泛，它可以与包括后端框架在内的几乎所有东西无缝协作：
rs fn my_route() -> Json<Foo> { let foo = /* Get a foo from the database */; Json(foo) }
能一站式处理所有序列化相关的内容（不仅仅是 JSON），这实在是太酷了。我认为 C# 生态系统中没有类似的东西（最近在 C# Discord 服务器上就这个问题进行了讨论）。
我希望 C# 从 Rust 中采用的另一个功能是文档功能。自动文档托管、丰富的 Markdown 语法、自动文档测试等。从 Rust 来，用 C# 写文档真的很痛苦。
这很酷。他特别喜欢的技术只是路由处理程序的派生宏。在 ASP.NET 中，控制器类方法中的所有参数都是由 JSON 自动映射的。显然，当你有运行时和反射时，这要容易得多。但这对我来说仍然很有趣。
听起来有点像 WCF 的 DataContract 类的概念–我想这些类只能处理 xml/soap、二进制和后来的 json（我想这应该可以扩展）。
他们删除了服务合同/数据合同的概念，这有点恼人–例如，现在如果你想从 rest 转换到 grpc，你就需要实现两个独立的合同/服务（仅供参考，WCF 仍然存在 https://github.com/CoreWCF/CoreWCF）。
系统运行时序列化
从第一版开始就有了。
这家伙太自以为是了。搞笑，什么都好，就是满嘴跑火车。
我尽量不看太多 YouTube 上的这些人物（Prime、Theo 等），让他们的观点在盐床中渗透。
Prime 讨厌微软，拒绝接受 C# 和 F#。但 Prime 喜欢 Typescript。但 Prime 讨厌 Typescript。
很多观点和反应都是他在 YouTube 上的 “品牌”，并不一定是他的 “专业意见”。正如他们所说，这些都是节目的一部分。
我不确定一个 40 多岁自称 ThePrimeagen 的人….。我不知道，这有点奇怪。我喜欢这家伙的 frontendmaster 视频，但他在 youtube twitch 上的所作所为令人讨厌。我完全同意你对 MS 的抨击，那会过时的。
他还不到 40 岁…
哎呀，他看起来像。
我是说他越来越像了，但这些评论也有点恶心。
你以失分为生？就像你靠失分赚钱一样？肯定是这样的….你是一个自称为 Rapzid 的中年人，在视频流中和一群孩子在聊天室里喋喋不休。我也觉得你是个傻瓜。话虽如此，我还是很喜欢他在《FE 大师》上的内容，虽然我觉得他有点怪，但还是挺不错的。
大多数人都是怪人。至少任何有趣的人都是。
这也是所有流媒体的写照。不过，也有一些年长的专业人士会从这些流媒体中获得娱乐，即使他们不是大多数观众，也不能代表模拟聊天。
我不知道参加任何流媒体聊天的人怎么会不觉得自己是个模拟者。这是一种与基本自尊相悖的恶心感觉。
现在的开发人员对我 1999 年在 ColdFusion 中做的事情津津乐道。
这是因为很多开发人员对 JS 和 Python 之外的东西一无所知，而且很多问题在 30 年前就已经有效解决了，这让他们大跌眼镜。
或者是 JS 重现了 PHP；)
VS 调试是我见过的最好的。在堆栈框架中移动非常容易。我从未见过与之相媲美的东西
我认为骑手也同样出色。
也许是我用得不够多，或者至少是最近才用，但我记得上次调试时遇到了问题。再说一遍，已经有一段时间了，所以你可能是对的。
“我记得曾读过一篇关于顶级 javascript ORM 的文章。Drizzle？人们意识到它实际上是在后台查询整个数据库，然后在其 rust 引擎中进行内存查询操作？”.
是 Prisma，不是 Drizzle。
但 Prisma 不会这样做。至少目前没有。
看看这个。不知道其中有多少内容是 100% 准确的，但似乎相当可信
他们最近添加了对 JOINS 的支持，但在此之前，它是通过基于 Rust 的查询引擎完成的，这导致了额外的请求。如果你想包含 2 个相关实体，这将是 2 个单独的查询请求，而不是使用 JOINS 的单个查询。
是的，这是我最不喜欢 Prisma 的地方–它会进行第二次 “WHERE Id IN “查询，而不是进行连接。这实在是太蠢了。
但引用的话听起来像是 Prisma 从表中获取所有记录，然后在应用程序中对它们进行过滤，但事实并非如此（至少到目前为止对我来说并非如此）。
dotnet后台很不错。前端就没那么好了。
当然，对于初学者来说，围绕 js 项目的工具可能很难配置，但一旦你做一些半复杂的事情，每个框架在这方面都很复杂。复杂是指 “该死的，这是我第一次尝试”，如果你已经掌握了复制/粘贴的知识/实例，一切都会变得简单。
我不知道你有什么经验，但 dotnet 是付费工作中使用最多的后端框架之一。
所以，人们并没有错过。
前端就没那么多了。
Windows Forms 和 WPF 在当时是非常可靠的。
如果他们能给我们一个现代外观的 Winforms，我会非常高兴的。
你可以在 WinForms 这头猪身上涂更多的口红，但我认为它有太多概念上的弱点。
不过，对于 WPF 而言，您可以获得 WinUI 的大部分功能：https://github.com/lepoco/wpfui，这让我不禁要问，为什么微软要两次重新发明这个 UI 框架（UWA/UWP，然后是 Windows App SDK），而且每次都没有明确的迁移路径。
不过，WinForms 是可行的。几乎所有其他框架（即使是 Avalonia，老实说我非常喜欢它）都有大量的怪癖，您需要克服这些怪癖才能获得一个非常简单的基本桌面用户界面。
能在表单上 “拖放 “控件实在是太神奇了，尤其是对于像我这样不是前端大师的人来说。
能在表单上 “拖放 “控件真是太棒了
没错。你可以很快上手。但我认为，这样做的最终代价是糟糕的架构。
在 WPF 中也可以拖放，还是我遗漏了什么？🤨🤨🤨
Blazor 真的开始让前端 dotnet 变得越来越棒了。
我写 blazor 已经有 3 年时间了，但我并不喜欢它。与事件的绑定要么中了，要么没中，要么中了再中，要么中了又神奇地解除绑定。我曾在各处添加去抖定时器，这对用户界面事件来说足够有效，但实施事件驱动设计却让我非常头疼。理论上我喜欢组件，但我遇到过多次组件生命周期失灵的情况。比如在同一个组件上调用了两次初始化回调。你永远不知道 OnInitializedAsync 和 OnAfterRenderAsync 哪个会先被调用。老实说，在太多的情况下，除了在 UI 代码中使用锁语句外，我找不到其他方法来完成工作，这让其他开发人员感到奇怪：这他妈有什么必要？这很好，但我宁愿使用 htmx。
我们一直在使用带有 blazor 的 Reactive.Net 来满足我们所有的事件处理需求，效果相当不错。虽然还没有使用 rxjs，但我们正在努力。
还有 ReactiveUI–我在 wpf 中使用过，但在 blazor 中也能正常工作。没有它，我真的无法想象如何编写 dotnetui。
绑定到一个事件是命中或未命中，或命中后再命中，或命中后神奇地自行解除绑定
这听起来更像是你正在做的事情出了问题。事件不会随机解除绑定，这将是一个大问题，会被立即标记并修复。
说起来容易。这是使用网络工作者 BlazorWorker 库的一个具体问题。我关注那个软件仓库并阅读代码的时间几乎和我编写 Blazor 的时间一样长。这其中肯定有问题，但在我眼里，阅读代码并关注 .net 每个版本都必须做出的更改，实在是让 .net 感到难堪。在他们能提供更多向后兼容性的稳定性（在相对较短的时间内）之前，我宁愿不使用它。
这是 BlazorWorker 项目的问题，您可以向其维护者提出任何问题。
这不是 Blazor 的问题
在我开发 Blazor 的三年多时间里，我从未遇到过事件绑定的问题，工作起来得心应手。
总是先执行 “OnInitializedAsyc”，然后再执行 “OnAfterrenderAsync”，如果不是这样，你的操作就大错特错了。
OnInitializedAsync 不会被调用两次，你只是以某种方式重新创建了该组件
请重新阅读 Blazor 文档，正确使用 Blazor 可以解决您的所有问题
OnInitializedAsync 不会被调用两次，你只是以某种方式重新创建了该组件。
这可能是因为在交互式渲染之前，组件已经预渲染过了。
在服务器上预演内容的 Blazor 应用程序会调用两次 OnInitializedAsync：
一次是在组件最初作为页面的一部分静态呈现时。
第二次是在浏览器渲染组件时。
组件初始化（OnInitialized{Async})
OnAfterRenderAsync 仅在交互式渲染后调用，而不是在预渲染后调用。
OnAfterRender 和 OnAfterRenderAsync 不会在服务器上的预渲染过程中被调用。这些方法是在预渲染后交互式渲染组件时调用的。应用程序预渲染时
组件在服务器上执行，在 HTTP 响应中生成一些静态 HTML 标记。在此阶段，OnAfterRender 和 OnAfterRenderAsync 不会被调用。
当 Blazor 脚本（blazor.{server|webassembly|web}.js）在浏览器中启动时，组件会以交互式呈现模式重新启动。组件重启后，会调用 OnAfterRender 和 OnAfterRenderAsync，因为应用程序不再处于预渲染阶段。
组件渲染后（OnAfterRender{Async}）。
如果您不想要预渲染和交互式渲染的复杂性，可以将 Blazor 配置为仅交互式渲染或仅预渲染（即静态渲染）。上述两个链接均来自 ASP.NET Core Razor 组件生命周期的官方文档。如果您正在使用 Blazor，我建议您阅读整个文档。
平心而论，这些都是使用 wasm 的结果，但没人能说服我，我所看到的都是假的。目前，blazor 可能已经解决了 OnInitializedAsync 在同一个组件实例上被调用两次的问题。但没有人会让我相信，这种情况没有发生过，或者说这只是某种记录在案的行为，除了在一个相对简单的布局中发生了这种情况之外，没有其他方法可以解释。
组件生命周期文档是我开始编写 blazor 时最先阅读的内容之一。但是告诉我，为什么我从来都不知道哪个方法会先完成，是 OnInitializedAsync 还是 OnAfterRenderAsync？生命周期可能会按顺序调用这两个方法，但它似乎不会等到其中一个完成后再调用另一个，这太愚蠢了
https://blazor-university.com/components/component-lifecycles/
在 Blazor 中开发了 2 年，大多数生命周期问题都源于非自愿地触发孩子/父母的重置。
需要说明的是，由于我使用它为客户制作托管 webassembly spa，所以我没有采用任何形式的高级状态管理。我将状态保存在服务器上。我偶尔会在多步骤向导中使用单例 “状态容器 “类，但仅此而已。
这就是问题所在。如果没有基于服务器的状态，这显然是不正确的。
捆绑包的大小还是太大了。在与其他非内部应用程序的前端框架竞争之前，他们需要缩小捆绑包的大小。
在 .NET 8 Blazor 中，他们有一个相当不错的解决方法。
在我看来，Blazor 在 3-4 年内将不复存在。就像 silverlight、maui、uwp、xamarin 等一样。
除非浏览器不复存在，否则 Blazor 不可能被杀死。最坏的情况是浏览器停止改进。
Silverlight 需要插件模式，因此很容易被淘汰。而其他浏览器则需要不断更新，以匹配 iOS 和 Android 的最新版本。
我认为 Blazor 比 Silverlight 机会更大。它已经可以在现代智能手机操作系统上运行。它的安装不依赖于专有插件。从概念上讲，它不会走自己的怪路（它实际上只是一个类似 React 的 SPA 框架，只不过运行的是 .NET）。
很难说 MAUI 会发生什么变化。
我从事开发工作已有 13 年。我的看法
这太糟糕了。用 X 来解决吧。
X很烂用 Y 来解决吧
Y 很烂，让我们试试这个（不知不觉回到 1）
= 每隔几年进行一次开发实践。
我还记得自己使用 Slim 和一些 jQuery 进行 Rails 开发时的服务器渲染视图。随着时间的推移，我见证了主要前端框架的崛起。我经历了 React 的多次演进、Angular 的全面重写，以及 Flux 模式的疯狂和状态管理方面发生的一切。
现在都快到 2024 年了，人们还在热衷于使用基本的、服务器渲染的 html 模板。我想我们一定是陷入了这样一个怪圈：忘记了过去为什么要这样做，然后最终又回到了原点。
对于为什么会出现这种情况，我的猜测是，每隔几年，就会有新的开发人员加入进来，他们缺乏历史背景，急于证明自己，他们试图用新的解决方案来解决问题，但不一定是更好的解决方案。这也就解释了为什么 JS 社区有如此多的变化，为什么有如此多的框架以不同的方式做着同样的事情，为什么现代前端开发似乎如此快速而频繁地经历着急剧的演变。
你能想象如果 Raact、Angular、Vue、Svelte 以及其他众多框架背后的思想家们团结在一起，共同提升一件事，那么今天的前端开发会是什么样子吗？
我们可能会得到相当于 .NET 的 JavaScript。
无论是新应用程序还是升级后的应用程序，企业都只能使用相同的技术栈。有些开发人员认为这很糟糕，但也许并非如此。甲骨文表格要么升级，要么转到 apex。.net 也是如此。Razor 或 angular 被广泛使用。
你有妄想症。开玩笑。
但是，.net 在某些方面是遥遥领先的，而在某些方面是远远落后的。
例如它落后的地方：
React 服务器组件与 blazor 完全不同，而且说实话，RSC 比 blazor 提供的要好得多。
.net中很难进行身份验证，而且很容易迷失其中。
我还没试过 .net 8 原生版本，但在 .net 8 之前，它们已经远远落后了。
与其他软件相比，.net 的跨平台图形用户界面非常糟糕。
不过，与其他产品相比，.net 大多是相当稳定和完善的。我更愿意从 .net 开始，而不是其他。因为开始使用 monorepo（解决方案）并部署它对我来说比其他环境要容易得多，也更容易理解。除了 dotnet，我无法使用其他任何后台程序，这并不是因为我没有尝试过。
对于前端……老实说，我宁愿坚持使用带有 ts 的现代 js 框架，因为它还不如那些框架完善。
.net中很难进行身份验证，而且很容易迷失方向。
我有这种感觉。每当我开始一个小项目或做其他事情时，我都会被它难住，最后就有点放弃了。我现在学会了使用 Azure B2C 或 Auth0 或其他服务来帮我处理。我感觉 net8 的情况越来越好，但我认为他们还有很长的路要走。
与其他语言相比如何？
您指的是认证还是授权？
我看了一些其他语言的教程，要么就像 Laravel 和 spring boot 那样，不管你想不想，它就在那里；要么就像 Go，与 dotnet 很相似，只是没有 ef core。
如果你在做一个小项目，为什么不直接使用默认的 Asp.Net Identity？
在第 8 版之前，尝试在 webAPI 中使用身份验证令人苦恼不已。
8 有什么变化？我一直只是在 .AddAuthorization() 中添加一个策略，然后在我的 Web API 控制器中加入 [Authorize(“ApiEndpoint”)]。
https://devblogs.microsoft.com/dotnet/whats-new-with-identity-in-dotnet-8/
如果你想或需要定制有关新端点的任何内容，你又回到了起点。
用户管理器（UserManager）和登录管理器（SignInManager）的文档几乎没有。
net8.0 中的身份验证简单了无数倍。它不是基于 OAuth 的，也没有试图这样做。对于中小型项目，它可以很好地工作。它的演示效果真的非常好。
但是……它需要托管您自己的用户数据库，这就带来了很多问题。
React 服务器组件在哪些方面远远领先于 Blazor？我对 Blazor 非常熟悉，但我已经很多年没碰 React 了，所以我真的很好奇。
在我的脑海中
– RSC 允许您将客户端和服务器相互混合。Blazor 不允许这样做。
– RSC 允许在静态组件中加入子组件。链接同上：Blazor 不允许这样做（仍可通过某种方式实现，但需要变通……）
– 自动交互模式不会在下载时将页面状态恢复为原样。它会等到用户浏览或刷新页面时才使用 wasm。例如，NextJS 会将服务器状态补给客户端。
– 即使使用预渲染，wasm 的启动速度仍然很慢，尤其是在低端设备上。即使在自动交互模式下也是如此。NextJS 在低端设备上的表现令人惊叹。
也许还有更多，但这只是我脑海中的印象。但除了最后一项，其他都不会让人失望，这取决于你的使用情况。但 Blazor 仍然落后。
对于我来说，我现在正在从 react 转向 Blazor，我在整个 websocket 事情上都很纠结。我有一些按钮只想在客户端工作，比如切换某个面板什么的，但需要服务器通过 websocket 进行往返。我可以把整个页面做成 wasm。但这样我就无法使用服务器交互模式。这非常尴尬。
有时连接中断，按钮也会突然停止响应。或者我看到默认的 Blazor 白色重新连接屏幕。
我不了解 websocket 架构。我还担心如果我们有成千上万的并发用户，它将如何扩展。
我明白你的苦衷。此外，如果您想要漂亮的 “加载器 “或防止同一操作上的多次点击。应该在客户端进行处理/阻止/指示，其余的可以传到服务器。
对了，别忘了苹果/ios 的 “问题”。即使将浏览器设为后台或切换标签页，连接也会完全中断（苹果从 2017 年开始就不关心这个问题了，websocket 漏洞百出）。
这对 Blazor 服务器来说是一个很好的阻碍，而作为开发人员或最终用户，你却没有能力强迫它工作。
对于网络内应用程序来说，这是一个不错的框架。但对于像拥有大量连接的网上商店这样的最终用户来说就不合适了。
呃–为什么你认为认证很难做到？
你说的是非 Web 应用程序吗？否则，只需在服务集合上调用 “addauthentication”（添加身份验证），配置 jwt/cookie 设置就可以了。
我看到的是 9 行代码，包括方法签名和大括号。
如果你想让你的应用程序在所有端点上都默认要求认证，请再添加 7 行代码。
本地 AOT 是如何落后的？能详细说明一下吗？
我要说的是，在这个子项目上，.NET 遥遥领先。如果换一个子系统，它就会落后很多。
EF 是一个漏洞百出的抽象概念。为了让它运行良好，你需要很好地理解它并很好地理解 SQL。我认为只需管理自己的 SQL 的观点是有道理的，尤其是考虑到调整 EF 通常需要您了解 SQL。
我认为在这个回音室里，这个帖子会得到很多支持，但事实并非如此。MVC 只是松散地基于近 20 年前的技术。大多数现代人都希望在网络上构建解耦的前端和后端。
你的 F5 例子就是另一个例子。但如果你认为 “我只需按下 F5 就能运行”……对我来说，这意味着你根本不知道你的服务将如何在 K8s 或 ci pipeline 中运行……这并不好。
如果您认为 “我只要按下 F5 就能运行”……对我来说，这意味着您根本不知道您的服务在 K8s 或 ci 管道中是如何运行的……这并不好。
在使用了 4-5 年的节点之后，我又开始使用 .NET（~20 年的老手），.NET 模板的不透明性让我很沮丧。只要从教程中复制粘贴，很多东西都 “能用”。如果你想从头开始，真正搞清楚事情是如何工作的以及为什么工作，那还是算了吧。
我的建议是：不要使用集成开发环境。使用 CLI。
这让 .NET 人员抓狂，因为工具的构建方式……是的，它就是能用，但这是因为它把该死的配置放在了 8 个不同的地方，而且从上下文来看，如何运行这些配置会产生巨大的差异，哦，尽管不需要它，但即使是 .NET 核心应用程序也会默认启动一个轻量级 IIS 服务器。
一旦你开始追踪所有东西的位置，当然……不难理解。但这也是一个让许多”.NET 开发人员 “感到束手无策的残缺拐杖，因为他们从来就不屑于去关心运行方面的问题。
你是说 kestrel 是 “轻量级 iis “吗？
不，我指的是作为轻量级 IIS 的 IIS express。许多默认项目模板，甚至是 .net core 应用程序，都会默认在启动配置中使用它。
啊，好吧。那么从技术上讲，是集成开发环境启动了它。特别是视觉工作室。Rider 不会，据我所知，VS Code 也不会。舰队也不会。
这就是为什么我认为你将 kestrel 称为轻量级 iis。
另外，我相信你知道这一点。但你可以改变正在启动的程序。所以说 “不要使用集成开发环境 “在我看来是个糟糕的建议。
我觉得你没有理解这次对话的背景。
我不认为你有兴趣进行对话，从你的历史记录来看，你简直就是在耍流氓。
但我愿意和你打一场球。什么上下文？我忽略了 OP 的哪部分内容和你的回应？
我可能会这么说，因为在与缺乏基本阅读理解能力的人打交道时，这很令人讨厌。不过，我会给你讲清楚的。
praetor 说：
在使用了 4-5 年的节点之后，我又开始使用 .NET（~20 年的老手），.NET 模板的不透明性让我很沮丧。只要从教程中复制粘贴，很多东西就 “能用”。
对此，我的回答是 “不要使用集成开发环境，使用 CLI”……这特别是指从模板生成项目。
原因是，如果你使用的是 VS 或 Rider，那么 “项目设置向导 “就会有很多默认选项，最终就会产生我认为 praetor 所指的不透明的 .NET 模板。
如果使用 CLI，您很可能会使用 dotnet new 等默认模板。然后你就会发现 “哦，该死……”。大多数项目都自带模板，我可以通过 CLI 安装这些模板。现在，你学会了如何有效使用 CLI，而不是依赖 IDE 这根拐杖。
通过这种方式，你可以更多地了解配置的来源、为什么重要等。参考：任何集成开发环境都会在某处创建配置，以运行 IIS Express 软件。通常是在 .idea 或 .vs 目录中。这可能与实际启动配置（可能引用 “使用 IIS”）位于不同的区域…这就是我说
……它把配置放在 8 个该死的地方
因为配置到处都是。如果你来自节点世界，就不会这样。你有 packages.json、.env 或 .envrc 文件。这些文件都在根目录下。
所以是的，我得说你忽略了对话的上下文，因为整个对话的重点就在于，从某些人的角度来看，这些东西都是神奇的，如果你依赖 VS 或 Rider，确实如此。
你居高临下的语气让我相信你对谈话的兴趣。
我认为你的大部分观点都大错特错。
让我们一次只谈一个。在 Linux 上运行 iis express 的 rider 怎么样？在不安装 visual studio 的情况下，使用 rider 在 windows 中运行 aspnet core 应用程序时，它是如何启动 iis express 的？
编辑：还有，应用程序的 dotnet cli 模板与 visual studio 创建的模板有何不同？
让我们一次只谈一个。在运行 iis express 的 Linux 上，rider 是如何运行的？
答：无法运行：不能用。不支持。但这并不妨碍它成为 .net 模板的默认配置，这也是对话的背景。
另外，应用程序的 dotnet cli 模板与 visual studio 创建的模板有何不同？
所有模板都有参数。我个人认为大多数 .NET 默认模板都是垃圾。我倾向于创建自己的模板。但同样，IDE 的默认值与 CLI 的默认值也是不同的。集成开发环境会默认一堆标志。
再说一遍，上下文是关键。重点不是讨论各种细微差别。重点是诊断为什么这么多人认为.NET模板本质上是不透明的。
你说得没错，我没兴趣与你交谈。你的回复继续无视原帖的上下文，而且你似乎只对争论语义感兴趣。
祝你愉快
我很喜欢用.net做后台。前端方面，我们正在研究 vue。
Vue 对于小型项目来说速度极快（大多数情况下甚至不需要 Webpack 和类似的垃圾生成器）。
但对于大型项目，我认为我还是更喜欢 React（但要说明的是，我还没有尝试过用组件 “正确 “地构建大型 Vue 项目）。
Vue 也能很好地处理大型项目。昨天，我统计了一下我们的组件（仅指组件，不包括存储和可组合组件等其他任何组件），现在已经有 900 个文件了。
这是个学习曲线，但一旦你会使用可组合组件、插槽、提供/注入、钩子、pinia 和所有其他有趣的功能或模块，就会觉得非常有趣。然后再在上面加上 Tailwind（正确使用一个月后，你就会爱上它，我保证），再加上 Typescript，你就成功了。
我认为这就是 Vue 的魅力所在：它的设计和意图非常明确，而且非常重视开发人员的体验。新人入职，甚至是没有 Vue 经验的人，都非常容易上手。但我们也使用 Nuxt（部分也作为后端使用！），它具有更多出色的开箱即用功能。
总之，它有一个很大的缺点：Volar/Linting 可能会变得很慢。超级慢。虽然很糟糕，但还算可以应付。
在我看来，.NET 用于后台是毋庸置疑的，而且我不认为它得到了应有的赞誉。前端似乎就不对了，而且当它要与 React、Vue、Svelte 等进行竞争时，我认为它并不是一个真正能够与之竞争的领域。
你试过 Blazor 吗？你对 C# 所了解的一切，但都在前端。它太神奇了。
Wasm 和网络套接字对于很多用户界面项目来说并不是一个超级好的解决方案。
C# 也有用户界面用例，但可以说是大量用户界面项目的最弱选择之一。
有什么能证明你的说法吗？WASM 和 WebSockets 可能是所有网络项目的未来。
我不是你回复的那个人，但就我个人而言，WASM 和 Web Sockets 既浪费带宽也浪费计算。与其他 js 框架相比，Blazor 的下载量要大得多，这对跳出率和收入都有很大影响。就服务器资源而言，保持网络套接字的活力也并不理想，即使对小型网站来说也是如此。
技术 Twitter 绝对是一个追逐影响力的粪坑。
.NET工具是最好的工具之一。在构建系统、调试、软件包管理、发布、CLI、并行安装、多目标等方面都花了很多心思。
是的，运行时和语言本身有问题，但工具就是好。
缺点是 Visual Studio 需要花钱。）
让我大跌眼镜的是，微软为 java 开发了一个免费、开源的 Java 扩展包，而 c# 的 vscode 插件却是闭源的，而且并非完全免费，最可悲的是，他们甚至一开始就想关闭 c# lsp 的源代码。
Visual Studio Community 是免费的，它能满足我的一切需求–为至少十几种不同的 AWS 服务进行 AWS 后端开发。我们支付了 VS Enterprise 许可证的费用，但我不需要（也不想要）企业版中那些毫无用处的垃圾，所以我告诉他们不要再浪费钱了。
缺点是 Visual Studio 要花钱:)
如果您可以为 Rider 付费，为什么还要为 Visual Studio 付费呢？
VS Code 是免费的。.net/c#开发设置非常简单
我喜欢 VS Code，但与 Rider（和 Visual Studio）相比，它还是初级产品。不过，我对它寄予厚望。
如果你指的是 C# Dev Kit 扩展，虽然它不太为人所知，但也需要许可证。它只是默认使用社区许可证，从技术上讲，它与 Visual Studio Community 有相同的限制–例如，你不能将它用于商业项目。
不过，VS Code 对 C# 来说完全是个屁
与 Visual Studio 相比，您更喜欢 Ryder 的哪些方面？
启动更快
反编译器
与 Visual Studio 相比，您更喜欢 Ryder 的哪些方面？
就在最近：Mac 版 VS 即将停产，所以剩下的选择只有 Rider 和 VSC。后者仍然不够好。
因此，对我来说，Rider 是目前唯一的选择。
VS 是免费的
除非你是小个子。
我身高约 6’4″，对我来说还是免费的
你提到了很多乱七八糟的东西，但关于前端的故事，我只想说，从理论上讲，Blazor是非常棒的，但现实情况是，它仍然非常小众，而且开箱即用也不是很简单。据我所知，目前还没有用Blazor编写的大型杀手级应用，除了Chris Sainty的书和微软提供的一些基本文档外，也没有很多很好的学习材料，而且也没有很多关于如何构建大型Blazor项目或如何处理状态管理等更复杂情况的意见指导。但微软过去在用户界面方面的成绩并不出色，不过如果Blazor Hybrid等产品能说明问题的话，Blazor绝对是他们可能会支持的产品。
此外，htmx 是一款不可知的软件，可帮助为页面添加交互性，在目标或使用案例方面与 Blazor 并无直接可比性。templ既能从.templ文件生成HTML代码，也能生成Go代码，因此你可以在SSR或静态页面中使用它。YouTube 视频中的堆栈只是将它们结合在一起，以实现全栈 Go 体验，但同样，你也可以使用 Django、Rails 等其他后端和模板引擎，轻松地将 htmx 插槽到其中。
关于后端，我认为 ASP.NET 一直都是非常不错的选择，但在云原生领域的很多关键方面却落后了，而这些问题在过去几个版本中已经得到了解决。不选择 C# 而选择 Go 的理由并不充分，但对于那些还没有融入 .NET 世界的人来说，选择 C# 的理由也不充分。显然，C#具有出色的性能和开发效率，但它也有很多新语言没有的包袱。
没错，在最近的一个项目中，我使用了 htmx+razor 来快速完成一个项目（不过事后看来，我应该直接使用 Vue，因为我后来也加入了 Vue）。
每次我被迫处理 c、java 和 js 项目时，我都忍不住希望 dotnet 构建系统和 cargo 能取代 make、gradle 和 npm……我的意思是，这些语言的发展时间比 c# 和 rust 长得多，为什么他们连构建系统都做不好呢？
除了工具，C# 是一门设计精良的语言，它能很好地完成工作。但有些东西还是落后了很多，所以除了后台和游戏，我不会使用它。
如果我们认为我们使用的任何技术都是万能的，那我们都是痴心妄想。
这篇文章与十年前的文章几乎如出一辙。当时的 C# 开发人员认为网络开发社区的其他成员都疯了，认为 Web 窗体是开发网络应用的最佳方式。
我喜欢 C#，也喜欢 .NET，但构建 Web UI 却不是 .NET 所擅长的。ASP.NET MVC 曾经风靡一时，直到 SPAs 变得炙手可热，ASP.NET 才再次落后于网络开发界的其他产品。
Blazor 是不错，我的一个应用程序就是 Blazor 应用程序，但它在构建 Web UI 方面远不如 React。React 在 5 年前就抛弃了基于类、充满生命周期方法的组件，这是有原因的，因为这种编写 Web UI 的方式既笨拙又笨重。与JSX相比，Razor本身就显得笨拙。
在后端，ASP.NET 是唯一能与其他网络框架相媲美（或更好）的地方。在 UI 方面，ASP.NET 远远落后于其他 Web 开发社区，过去是，现在是，将来也是。
EF 是最好的 ORM，而且只能在 C# 中实现，因为编译器可以将 lambdas 变成表达式树。
在前端，Next.js 胜过 .Net，因为服务器和客户端使用的是相同的渲染引擎。这不仅仅是旧式的 SSR。它是无缝过渡到 CSR 的 SSR。
调试这件事真的让我很头疼。有人说，如果你依赖调试器，你就是一个软弱的开发人员，或者你需要用日志来调试，因为这是生产调试的唯一方法。真他妈扯淡。
这和以前人们对集成开发环境的说法如出一辙。如果你不使用调试器，那你就做错了。在约翰-卡马克（John Carmack）最近的一次采访中（Lex Fridman IIRC），他说这就是元的哲学，他讨厌元，因为代码很复杂，你不可能把所有代码都记在脑子里，但调试器可以。对他来说，调试器是不可或缺的工具。人们认为自己是比约翰-卡马克（John Carmack）更优秀的开发者，这在我看来太疯狂了。
至于在 prod 中进行调试，其实永远都不应该到那一步。在预置时代，你会有一个支持案例，并与客户来回沟通。在云世界里，我们最终会推理遥测，并推论如果你有能力附加远程调试器，你就能以令人难以置信的速度解决问题，但可能会有不允许这样做的操作原因。我将其视为特权会话用例，但大多数运维人员对此反应迟缓，认为安全需要放慢开发速度。
这不是非此即彼的问题。调试器对于初期开发、测试等工作非常重要，但在生产过程中出现问题时就不能依赖调试器了。而生产中一定会发生问题。在生产环境中使用调试器的问题并不在于调试器是否存在，也不在于你是否能附加一个调试器，而是因为生产环境中 99% 的问题都不是在你积极观察并能设置断点之类的情况下发生的。
大多数生产问题都是 “每周随机一次，整个机群中的一个主机实例会出现峰值的巨大延迟 “之类的问题。你需要日志来调试这类问题。
用调试器调试是外科手术。使用日志调试则是解剖。你必须能够同时做到这两点。
几天前，我看了完全相同的视频，得出了完全相同的结论。我写了一条评论–他删掉了 😁。
我使用 Go 是因为它的编译时间和构建大小，但如果要构建 Web 应用程序，与 .NET 相比，它似乎是一种极不实用的工具。
我记得我读到过一个顶级 javascript ORM。Drizzle？人们意识到它实际上是在后台查询整个数据库，然后在其 rust 引擎中进行内存查询操作？
是 Prisma。听 js 人说 “ORM 不好 “总是很有趣。
至于 Drizzle：我不知道这是不是一个笑话
我同意后台。ASP.NET 拥有我所需要的一切，而 C# 则是一种非常棒的语言。
不过，我觉得我不能相信微软的 Blazor。我感觉如果采用率不高，他们就会放弃。
用于 API 的 ASP.NET + 用于前端的 VueJS 看起来很神奇！我可以在任何云中进行部署，而不会被供应商锁定。
我更喜欢 Angular + .NET。这似乎是 C# 工作机会中的首选组合。
我们是一家以 .NET 为主的公司，但我们仍然根据不同的使用情况使用完整的 Typescript（SPA + Node 或 SSR 混合体，如 Next）。但由于速度的变化，.NET 后端（+ 任何前端）越来越常见。如果不涉足.NET，我们的产出要高出很多（50%~）。因为我们都喜欢.NET，所以我们甚至想方设法找到留在.NET的理由。不要忘记 JS 生态系统的 DX/工具。
您的 Node 后端框架是什么？很好奇。
.net确实势头强劲。我不敢说.net 是最好的，但它在某些方面绝对是领先的，而且有很多优势。所有语言都在功能上相互促进，.net 肯定也是如此。
Javascript 中的 ORM 🤦♂️ 它们数量众多，但与 EF 相差甚远！
TypeORM – 总是名列前茅。但是：没有工作单元和大量错误。您根本无法在没有问题的情况下保存对象的层次结构…
BookshelfJS – 你也可以在列表中看到它。但它就是个垃圾。如果说 TypeORM 有一些问题，那么 Bookshelf 本身就是一个大问题。
所以，是的，我同意–ORM不好。在 Nodejs 的世界里。
我基本同意，在 NodeJS/TypeScript 生态系统中，没有什么能与 EF 相提并论，这主要是因为很多类型安全 ORM 很难由一两个人的团队来维护。
不过，Kysely https://kysely.dev/ 是最新的一款非常不错的产品。
它支持非常复杂的查询，并能准确推断类型。
作者会费心维护它多久？没人知道，所以添加这么大的依赖关系总是有风险的，但对于业余项目来说也许是这样。
当我们都死光光的时候，C 还会在这里
机器会用它来嘲笑我们这些灭绝者。
它不是最擅长开玩笑的，但指点江山还是没问题的。
哈斯克尔语太多了，我都快被淹没了！/s
你是说 Haskell 不流行？它不像其他语言（如 Python、C#、Java……）那样被广泛使用，但它是流行语言中许多功能特性的基础。你可以把 Haskell 想象成 20 年后的其他语言。
不，ML 是其中大部分的前身（包括对 Haskell 的大部分启发）。
不过，我不认为我们会从 Haskell 中获得那么多灵感，因为这些创新部分是在纯粹语言中工作的窍门，追求纯粹性似乎会导致很多问题，就像 90 年代追求 OO 给我们带来的问题一样（不过，从 Haskell 中汲取灵感来解决很多问题是个好主意，因为函数式的转换风格对代码的可理解性有很多好处）。
在这方面，F# 是 ML 有趣的后代。不过在企业环境中很难推广。
我的意思是无论本月流行的语言是什么。
你怎么确定 C# 不是本月流行语言？
是啊……新的 MS 似乎更倾向于采用其他占主导地位的生态系统，而不是建立自己的竞争对手（即 C# 的出现是因为 MS 害怕 Java……现在 MS 似乎真的在努力争取 Java 的支持）。老实说，Blazor 和 MAUI 的现状让我对 C# 的未来感到有些担忧。我现在开始用 react/nextjs 写新东西了。就目前而言，C# 是一种很棒的后端语言，但从长远来看，我担心它会被抛在后面。
不过，你把它比作 javascript，就像最近有人说的那样，”一辆绑着全尺寸内燃机的玩具车”。
C# 已经存在了 20 年，并将在未来 20 年继续存在。而其他大多数语言则不会。
其他语言大多不会。
举几个例子。我有一些收入不错的 COBOL 朋友。😁
一些收入不错的 COBOL 朋友。😁
好赚，但好学呢？我觉得 C# 的新增功能可以让我成为一名更好的工程师，并能将这些技能运用到其他现代语言中。
COBOL 能做到这一点吗？
但 C# 可以轻松转录到打卡机上吗？
打孔卡是五六十年代的二维码。
也许吧。两种语言都被编译成低级语言，可以在类似的硬件上运行，所以……😊
不过，我可不想眼睁睁地看着它被编译出来。我的孩子还小，晚上睡不着觉已经够多了。😁
好赚，但好学呢？
当您达到或超过领取养老金的年龄时，您更关心的是钱，而不是学习。😁
背景确实有帮助。只要技术比你长寿，你就应该充分利用这些遗产知识：)
有很多工具，但也有很多方法可以让你的脚中枪。
我认为这取决于成熟度和随之而来的发展水平。由于我的工作性质，我使用了很多工具和语言，我总是为人们热衷的某些技术感到悲哀。与使用.net 相比，很多新手都有不足之处。尤其是在后端和调试方面。
一项技术的好坏取决于人类对它的理解。如果你在 HTML 上创建了一个抽象概念，那么每个想使用它的开发人员都需要了解它。
在我的工作场所，我负责跟踪.net 开发人员的工作效率，很多时间都花在了理解和使用工具上。
我的个人观点我希望前端工作能专注于 HTML/CSS 和浏览器，只使用很少很少的脚本。
我想说，这就是通常的循环。我们在重复发明轮子;)
在职业生涯中，我只在 c# 代码库中工作过
所以你是在自欺欺人，这有什么好神秘的？几乎没有任何其他方面的经验，但仍然”.NET 遥遥领先”，呵呵。
.NET需要一个M:N并行运行时，在此之前，他们根本不可能 “领先”。
我是个机器人，bleep，bloop。有人从 reddit 上的另一个地方链接到了这个主题：
[/r/hackernews] 是 .NET 遥遥领先，还是我有幻觉？
[/r/hypeurls] Is .NET just miles ahead or am I delusional?
如果您点击了上述链接，请遵守 reddit 的规则，不要在其他主题中投票。(信息/联系方式)
我喜欢 C# 和其他语言，但不得不说，微软在不知不觉中巧妙地将 Azure 云和 Windows 推向了市场。
我在 Linux 上完全使用 Azure，但多年来一直存在一些 Bug，比如 LDAP 在 Linux 上不接受 unicode 字符。或者在没有 Windows GDI 的情况下，System.Graphics.Drawing 无法正常工作。或者是 SSO 实现依赖 Azure IdP 的方式，而没有使用 Auth0 等其他简单的 OIDC 方案。
但我必须说，C# 发展很快，速度很快，现在一般在任何地方都能运行，这与 WinForms 时代相比有了长足的进步。用 C# 创建后端轻而易举，而且随着最近的树形摇动单一二进制输出，运行时间变得更小更快。尽管 Linux 仍然是一个二等公民，但我对此感到非常惊讶。
我只在 C# 代码库中工作过
熟悉的就是 “直观”，不熟悉的就是 “难用”。
几百年来一直如此。
不仅仅是.NET，微软也比其他人领先很多年。
你的意思是除了Azure UX是他妈的垃圾之外，对吗？就像 AWS 和 GCP 一样，虽然它们也不怎么样，但不会像 Azure 那样让我眼睛流血。我也希望微软能放弃 ADevOps。GitHub 是一个更好的平台，我已经厌倦了与那些坚持使用 GitHub 的垃圾公司合作。
Azure 的用户体验比 AWS 好太多了。GitHub 属于 MS，用户界面比 ADO 差远了。最后，从 ADO 到 GitHub 的切换非常简单，虽然你在做 PR 的时候会怀念它，因为你读文件的时候很费劲。
在 Azure，如果你想管理订阅，只需进入 “配置文件 “选项卡，然后 “切换目录”……哦，对了，超级直观的用户体验。你所处的每个页面的布局都会发生变化。这是可怕的用户体验。老实说，GCP 做得最好，布局从不改变。AWS 可能会让人不知所措，但至少他们可以让你定义自己的布局，这也是需要权衡的。
—-
个人项目？当然，这没什么大不了的。让公司改用新工具？祝你好运
我知道这是个人喜好，所以这种争论没有意义。我从未错过 ADO。我总是站在栅栏的另一边。怀念 Gitlab 或 Team City 或 Github。ADO 看起来就像我在 2001 年设计用户体验时的样子。这很有趣，因为它是狗粮。许多低劣的 Blazor 项目都使用了同样的标准设计模板。(小部件在左侧，这些小部件的抽屉，项目设置放在一个奇怪的位置，完全超载，等等）。
而 Github 文档则将 ADO 文档吹得天花乱坠。尽管微软拥有 Github，但他们在不干涉业务运营方面做出了正确的选择。如果他们这样做了，就会立即失去所有非微软用户。
这正是微软人不愿听到的。这种狂热有点疯狂。如果 typescript 不是微软创造的，你们这些人绝对会对它大加挞伐。如果微软开始把他们的标签贴在更多的垃圾上，人们就会开始吃乌鸦了。
现在，这一切都源于这样一个事实：MS 生态系统之外的大多数人纯粹因为它是 MS 而攻击它。因此，我相信这更多的是对这一事实的回应。但是，当你无法让一家公司摆脱低劣的 Azure 应用程序服务，或者因为他们是一家自称为微软商店的公司而为 Insights 付出高昂的费用时，即使另一家供应商给他们提供了更好的交易，这也会彻底激怒他们。
现代开发的本质是框架/语言之间的相互学习。.NET8/C#的大量新功能都是在JS生态系统中实现的，反之亦然。举个例子，Blazor 一直在吹嘘的 “交互式孤岛 “肯定是由 Astro 和 NextJs 等工具首先实现的（至少在这个周期的迭代中是这样）。Minimal API 的设计意图是在语法上与 Express 服务器相似。
另外，HTMX 并不完全是一个标准或其他什么，它只是从行业标准 JS 的东西向左转了一大步。
从前端的角度来看，.NET 要想拥有 JS 生态系统目前所拥有的开发者体验，还有很长的路要走。当然，它已经越来越接近了，我也非常喜欢使用新的 Blazor 功能进行构建，但它还没有达到那个水平。
xUnit 现在有文档网站了吗？我上次查看时还没有。作者建议使用 intellisense 提示来探索 api。很难相信一个官方推荐的单元测试框架竟然没有在网页上列出 api 中的所有方法:)
对于从事企业工作的企业来说，是的。但我无法击败专业或小众语言，如用于 ML 的 Python。
对于 leetcode 风格的问题，它也很糟糕。启动程序的开销不如 Go 那样直观。除此之外，非.NET 用户会认为模板代码过于复杂。除此之外，.NET 的数据结构也不是最好的。像优先级队列（priority queues）这样的东西比它们应有的要新得多。
C# 和 dotnet 有其缺点：
1) 没有像 Java zgc 那样的低延迟 GC。可以做到，只是还没做到。
2) 没有在托管堆（内存区域？）可以实现，但尚未实现。
3）围绕性能的仪表化，例如，我希望能看到 jit 认为过大的可内联候选对象。
4）主构造函数–不知道为什么他们不能像 typescript 那样提供主构造函数。
5）GO 中的通道很不错，但不确定 C# 是否能从中获益，不过还是可以的。
6) 我想在没有类的情况下定义一个函数。我有很多类都只有一个实用功能（也许是我的问题）。
7) 我认为 GO 将错误（即负结果）与异常区分开来。如果能返回多个结果，而不需要昂贵的封装和模板，那就更好了（我知道 CLR 可以做到这一点）。
8) 异步/等待与绿色线程。我还没有选择哪一方。
9) Traits（又称 mixins）–C# 没有。
10) C# 随着时间的推移变得越来越胖，你可以用 3 种不同的方式初始化一个集合。如果能淘汰旧的，只留下新的就更好了。
除此之外，作为一名 C# 开发人员，我觉得 C# 非常适合工作，我对 C# 逐年取得的进步感到高兴。
绿线是怎么回事？我稍微研究了一下绿色线程（Goroutines），但没有发现明显的优势。我无法理解 async/await 有什么问题。我的意思是，我明白蓝线和红线功能的区别，但……谁在乎呢？这对我来说从来都不是问题。我不明白为什么人们会在意必须将函数标记为 async。
你知道现在有主构造函数了吧？我想你是指 TypeScript 有更好的语法吧？
是的，正是如此，只是感觉这个功能还没有完全完善。
TypeScript 有什么不同？
C# 也有通道，它们与 Go 中的通道有什么不同吗？
我特别喜欢去年整个网络圈对服务器端渲染的热捧。我在这方面已经有一段时间了，这无疑会让我感到好笑。
Golang 是 2009 年诞生的语言，JS 后端也是在 2009 年与 Nodejs 一起诞生的（我知道有一些 js 后端比 Golang 诞生得早，但没人把它们当回事）
我的朋友，他们甚至还没到法定年龄。当然，它们并不像 .net 那样成熟，如果你想看成熟度，可以看看成熟的生态系统：Ruby on Rails、PHP Laravel、Java Spring Boot、Python Django…
我使用过所有这些系统，它们提供的东西甚至远远超过了 asp.net。
每一种都有其强项和弱项。如果您想获得开发人员的经验和生态系统的成熟度，就不要看那些新来的孩子。
是的，我不认为这是个好论点。那是 14 年。这 14 年里，.net 就在那里，ruby 就在那里，django 就在那里。
它们并不是孤立存在的，这也是让我感到奇怪的主要原因。
我无法构建 EF core、Aspnetcore 或 C#。但有些人和公司可以，我希望他们能看看该领域的其他 10 家公司在做什么。特别是如果这些都是开源的，而且就在那里。他们可以直接复制粘贴。
我的意思是，如果将 .Net 与 Go 或 JS 相比，当然是 .Net 胜出，因为 .Net 的历史更悠久，开发工具的时间更长。
如果将其与 Java/Spring 或 python 进行比较，那么比较的范围就会变小，以至于无关紧要。
我喜欢 Java，而且用它工作了很多年，但是，现代的 .NET 比 Java 对容器更友好👀。
我使用 Java，在容器中运行 Java 没有任何问题。
任何事物都有适合的时间和地点，但任何事物都不适合任何事物。
.NET 是虚拟机。C# 是语言。
C# 确实发展得非常出色。40 多年来，我使用过很多编程语言，从功能角度来看，我最喜欢 C#。
我在做移动开发时确实喜欢 swift，但与 visual studio 相比，Xcode 显然太糟糕了。
我刚刚创建了我的第一个 Maui 应用程序，它是一个东西
我曾长期从事 C# 开发工作（2001 年开始使用 .NET Framework 测试版）。现在我的工作头衔不完全是 “开发人员”，但我仍然经常用 C# 编写代码。我同意 OP 的观点。不过，去年我写的 Python 和 JS/TS 比 C# 多。为什么呢？因为写 Python 脚本不需要用这些 AssemblyInfo.cs 创建 sln 和 csprj。而且，用 Expressjs 后端创建一个功能性 SPA，作为云函数运行，要比 dotnet 新 mvc 应用程序简单得多。特别是如果你是 Mac 用户的话。此外，当我使用任何编程语言编写代码时，我都会使用 VS Code。但对于 C# 代码，我知道 VS Code 和带有 ReSharper（或 Rider）的 Visual Studio 之间的区别。因此，我觉得 “我是应该启动 Rider（如果你想要最新的点阵图，它通常落后于 Visual Studio），还是换成我的 Windows 笔记本电脑（它的价格是 MacBook Pro 的两倍，但如果你不把它当作固定电脑使用，它的用户体验就很糟糕），还是使用 VS Code（它有一些微软提供的花哨扩展，但它们感觉不到 VS Code 和 ReSharper 之间的差距）”。因此，这就是我现在主要用 Python 编写代码的原因：它简单、简洁，即使使用 print() 进行调试，我也能更快地完成简单的工作。我仍然会在任何 “大 “项目中使用 C#，但我理解为什么人们讨厌整个 Windows 上的 visual-studio 体验，因为在中小型任务中使用 JS 或 Python 是如此简单。
AssemblyInfo.cs
这在.NET core 中已经不存在了。
很高兴听到这个消息。）听说在 dotnet 9 中，sln 文件也会变得更好。但只要比较一下使用 Minimal API（dotnet）和 FastAPI（Python）运行一个简单的 REST 端点所需的文件数量，我的观点就显而易见了。
此外，我还记得自己曾与微软的一位布道者一起参加过 “Silverlight 是我们的未来 “的网络研讨会。就在微软将其扼杀并专注于 HTML5 的不到一年前。.NET Core 和 C# 是伟大的技术。但像 Blazor 这样的东西，我真的不知道。我宁愿使用 React 或 Angular。
我的感觉正好相反。我正在尝试一些数字运算，还好 net 没有 fft。现在似乎有了一个可查询的 nugget，但比 python 和 labview 中的慢得多。
数字滤波器呢……缺乏
显示科学图形，如 matplotlib。不，可能有商业软件包，但我没有预算。
在数据分析方面，net 似乎落后了十年。我没有深入研究，但 tensorflow 如何？或者用于量子计算的 qiskit？