5
.net 那边有了 blazor， Java 这边会出类似的东西吗
source link: https://www.v2ex.com/t/798779
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
第 1 条附言 · 1 天前
除去语言大战的），好像大家更多关注的都是wasm啊，实际上blazor有server模式的，而且现在用的更多好像都是server模式
51 条回复 • 2021-08-31 13:49:45 +08:00
thtznet 1 天前 
1
.Net 有微软，Java 有啥？甲骨文？算了算，不要想了。
不是我吹冷风，这种大踏步的变格，没有实例雄厚的主导厂商基本是没有可能做出来的，即便做出来，易用性也差得很，所谓开源，在离开了大厂商的情况下，以目前的业态来说，只能做一些小格局的东西，业界形态的大踏步的推进没有巨头基本是不可能的事。
虽然现在 Java 还是如日中天，但是按目前甲骨文的这个德性，.Net 生态慢慢追平 Java 是时间问题，当然这个时间会很厂，中间微软要给力，甲骨文要继续作死。
不是我吹冷风，这种大踏步的变格，没有实例雄厚的主导厂商基本是没有可能做出来的，即便做出来，易用性也差得很，所谓开源，在离开了大厂商的情况下，以目前的业态来说，只能做一些小格局的东西，业界形态的大踏步的推进没有巨头基本是不可能的事。
虽然现在 Java 还是如日中天，但是按目前甲骨文的这个德性，.Net 生态慢慢追平 Java 是时间问题，当然这个时间会很厂，中间微软要给力，甲骨文要继续作死。
huang119412 1 天前 5
@thtznet 无知者无畏，连微软的孝子都有，微软做的恶罄竹难书，到现在还有很多开源社区不愿意和微软扯上关系。Oracle 做了什么？安卓的 Java API 是法律问题，连美国大法官们都在争论不休，你操个什么心。真的难以想象，连微软都能洗白。
h82258652 1 天前
虽然我也在做 .net 相关的，但是也不看好 blazor 。webassembly 模式老浏览器跑不动，而且 GC 要几 M 。websocket 模式量大了会拖垮服务器。注定 ToC 场景不适合。
那也就只能做做 ToB 的，但是除了小公司，一般公司都会有前端开发，那又用不上了。小公司也不会用到这么新的玩意。
之前想来想去，也就两个地方适合，一个是搭配 electron 开发本地 app，一个是开发 chrome 插件，毕竟这两个性能要求不算高，带一个 GC 也不算大多少。
那也就只能做做 ToB 的，但是除了小公司，一般公司都会有前端开发，那又用不上了。小公司也不会用到这么新的玩意。
之前想来想去，也就两个地方适合，一个是搭配 electron 开发本地 app，一个是开发 chrome 插件，毕竟这两个性能要求不算高，带一个 GC 也不算大多少。
thtznet 1 天前 3
Blazor 不一定会更变什么风潮，但是按目前 .Net 的更新速度和变革速度，Java 再慢慢脱节。楼上诸公认清现实，语言只是工具，哪个好用用哪个，没那么多政治正确。
各位去问问看给各位家里装修的木工，会不会因为博世工具政治不正确去选博达工具？干活的人是务实的，务实！
各位去问问看给各位家里装修的木工，会不会因为博世工具政治不正确去选博达工具？干活的人是务实的，务实！
MakHoCheung 1 天前
就是用 c# 写前端吗，java 的话好早之前不是有 gwt 吗，虽然很拉垮。jvm 系的话，未来会有 javafx for web 和 compose for web，现在的话有 flutter 。感觉最终还是回归 js 。
Rwing 1 天前
blazor 归根到底还是 webassembly，其他很多语言也都有 webassembly 的方案。
虽然看起来 webassembly 是前端的最终归宿，但是要考虑语言的惯性和更新换代的成本，所以 5 年内 webassembly 都没可能超越 js 在前端的地位，至于说 5 年后，谁知道呢，前端本来就千变万化。
至于说.net 为什么要上 webassembly，我认为是.net 一直都有很好的客户端基因，例如 winform/wpf/winui 等等，所以自然而然的做一个 webassembly 没什么问题。
综上，.net 如果只靠 blazor 就想夺回市场，那是不可能的，与 java 无关，与 webassembly 有关。
虽然看起来 webassembly 是前端的最终归宿，但是要考虑语言的惯性和更新换代的成本，所以 5 年内 webassembly 都没可能超越 js 在前端的地位，至于说 5 年后，谁知道呢，前端本来就千变万化。
至于说.net 为什么要上 webassembly，我认为是.net 一直都有很好的客户端基因，例如 winform/wpf/winui 等等，所以自然而然的做一个 webassembly 没什么问题。
综上，.net 如果只靠 blazor 就想夺回市场，那是不可能的，与 java 无关，与 webassembly 有关。
Fule 1 天前 1
至少最低程度上这东西有解决我实在是不想写太复杂 JavaScript 的东西的潜力。而且，这个项目最初感觉还是以“兴趣”和“探索可能性”的目的而创建的，我也很意外竟然如此之快就挂到了正式集成并发布的阶段。如果是面向全互联网用户的产品，我不好说，但是如果是用于用户可控的企业内产品的话，倒可能是一种潜在可行的方案。目前认为最便利的地方之一是一些 POCO 的类型定义可以直接共享而不需要 C# <-> JSON 之间的转换。
yannxia 1 天前
@love 这个也是实事求是···现在都是公司级开源，或者由公司牵头成立基金会的模式，不过 Oracle 在 Java 上还算是投入了，现在存粹小公司开源的确不怎么敢用，有钱才有人维护。
aguesuka 1 天前
@Rwing
WebAssembly 模式: Kotlin 原生, Java 使用第三方库如 TeaVM.
服务端模式: GWT 框架.
ps. 我现在的项目就用到了 GWT, 它是我现在的噩梦, 我的感受就是不基于几篇经典的论文发明的框架注定走不远.
WebAssembly 模式: Kotlin 原生, Java 使用第三方库如 TeaVM.
服务端模式: GWT 框架.
ps. 我现在的项目就用到了 GWT, 它是我现在的噩梦, 我的感受就是不基于几篇经典的论文发明的框架注定走不远.
Rwing 1 天前
没想到 V2EX 的无脑黑也这么说，我还以为程序员都有自己的脑子自己的思考呢……
一个公司的产品的改名自然有他的原因，各大科技公司都不少，例如 google 的
https://www.landian.vip/archives/73733.html
同样的，各大公司的死掉的产品也是大把大把，例如 google 的
https://www.zhihu.com/question/19550227
其次，题主问的是 java 会有这边东西吗，各位无脑黑微软是不是跑题了呢？
最后，各位如果自认是优秀的工程师，那么发言的时候还是带点脑子好
一个公司的产品的改名自然有他的原因，各大科技公司都不少，例如 google 的
https://www.landian.vip/archives/73733.html
同样的，各大公司的死掉的产品也是大把大把，例如 google 的
https://www.zhihu.com/question/19550227
其次，题主问的是 java 会有这边东西吗，各位无脑黑微软是不是跑题了呢？
最后，各位如果自认是优秀的工程师，那么发言的时候还是带点脑子好
x940727 1 天前
Java 在脱节是 Java 在脱节还是 Javaer 在脱节，这个要分清楚，目前来看 Java 是属于目前来说开源阵营最锐意进取的语言之一了，无论是 GraalVM 还是 Native Stack 都是在努力拥抱前沿生态，包括 Spring 也是，但是 Javaer 就不一样了，用着 Java8 写 Java6，连 Java9 摸都没摸过，这你不能怪 Java 不行吧？如果怪你就只能怪 Java8 太强了，性能足够，语法也足够，Spring 也挺好使。
namelosw 1 天前 2
类似 Blazor 的东西有一天会火起来的，毕竟 WASM 是方向，然后其他语言会跟进，最后 Java 社区会跟进。因为现在来说 Java 社区不够「酷」，所以这些开拓进取的事情 Java 社区做得比较少，大多都是企业级场景有需要才会推进。
另外个人感觉 Blazor server 感觉还比较实验性，没有 Phoenix Liveview 的实现方式那么 production ready 。
Stateful WebSocket 真正的困难在于性能和部署模型。比如每个用户都有一个独立的 counter 对象，每个有自己的状态：第一个问题是这个框架怎么自动把不同用户的 counter 均匀的分散在所有的 server 上，这样才能横向扩展支持大量用户。第二个问题是用户从 load balancer 过来，每次请求的 server 可能不一样，怎么即不靠 sticky session，又能让每次用户可以和自己的 counter 互动。
Phoenix Liveview 的方式是靠 Erlang process group 构成全联通网络，不仅能支撑大量连接，还不需要 sticky session，看起来是比较合理的方式。这种方式不流行是因为这个实现方式主要依赖 Erlang 独特的虚拟机模型，其他语言的技术栈很难模仿。
我之前看的时候 Blazor server 似乎必须单机 / sticky session / 用 Azure SignalR，不知道现在还是不是这样，如果还是的话横向扩展性明显有问题。不过我感觉如果解决这个需要动上层 API 或者修改 C# / CLR，都是很大的工程，而且会影响到框架的用户。
另外个人感觉 Blazor server 感觉还比较实验性，没有 Phoenix Liveview 的实现方式那么 production ready 。
Stateful WebSocket 真正的困难在于性能和部署模型。比如每个用户都有一个独立的 counter 对象，每个有自己的状态：第一个问题是这个框架怎么自动把不同用户的 counter 均匀的分散在所有的 server 上，这样才能横向扩展支持大量用户。第二个问题是用户从 load balancer 过来，每次请求的 server 可能不一样，怎么即不靠 sticky session，又能让每次用户可以和自己的 counter 互动。
Phoenix Liveview 的方式是靠 Erlang process group 构成全联通网络，不仅能支撑大量连接，还不需要 sticky session，看起来是比较合理的方式。这种方式不流行是因为这个实现方式主要依赖 Erlang 独特的虚拟机模型，其他语言的技术栈很难模仿。
我之前看的时候 Blazor server 似乎必须单机 / sticky session / 用 Azure SignalR，不知道现在还是不是这样，如果还是的话横向扩展性明显有问题。不过我感觉如果解决这个需要动上层 API 或者修改 C# / CLR，都是很大的工程，而且会影响到框架的用户。
thtznet 1 天前 4
@cassyfar 这个世界不是只有 抖音、微信、知乎、美团、携程的，这个世界还有山崎马扎克、西门子、博世、通快、ASML 、台塑、英特尔、金田豪迈、GE 、FAG 、波音等行业巨头，计算机软件已经深入各行各业，工业界的应用深度比消费界大得不知道哪里去了，只是不常在媒体上蹦跶罢了。
namelosw 1 天前
@Itoktsnhc 是，但是又少了 Blazor 那层。不知道微软为啥没搞 Blazor + Orleans 的技术栈。
可能是比起 Blazor Orleans 更非主流一点…… 而 Blazor 微软希望有天能当主流技术用。 微软不可能把 CLR 改成 Erlang BEAM，Orleans 实现只能靠很多 code gen 。
可能是比起 Blazor Orleans 更非主流一点…… 而 Blazor 微软希望有天能当主流技术用。 微软不可能把 CLR 改成 Erlang BEAM，Orleans 实现只能靠很多 code gen 。
Fule 1 天前
@Jooooooooo 楼上，确实。我都是招 Java 初级程序员然后“改造”成 .NET 程序员，现在他们都说 .NET 真香，哈哈~~ 好吧，你们可以说我欺负他们没见过大世面~~ 原本我也打算脱离 .NET 了，巧合的是，也是那段时间他们推出了（现在叫） .NET 5，我是从 Beta 4 阶段开始接触的，还给 EF 团队提交过几次功能性 PR，因为那时候我们已经开始尝试用它做实验性项目探索了，缺了的功能只能尽力自己去补，然后做 PR 反推给 M$，还好那时候的代码还没有如今极致之复杂。我觉得微软算是转型比较成功的巨型企业了吧。
agagega 1 天前 via iPhone
我不讨厌微软，它家软件产品挺多都挺好用的。但知乎那帮微软水军是真恶心。果粉也就吹苹果多牛多高端，软蛆吵架的时候特爱整出键政那一套。不过现在知乎花粉多起来之后，式微了。
cassyfar 20 小时 56 分钟前
sunbreak 17 小时 52 分钟前
Compose for Web 可以试试看： https://compose-web.ui.pages.jetbrains.team/
Compose 整体来自 Android Jetpack Compose，JetBrain 迁移到 Desktop 和 Web 了
- Compose for Desktop 使用的是兼容 Swing/JavaFx 的 Skija： https://github.com/JetBrains/skija，和 Flutter for Desktop 思路类似
- Compose for Web 没看具体实现，如果和 Flutter for Web 思路一样，那么也是用 WebGL 版本 Skia
Compose 整体来自 Android Jetpack Compose，JetBrain 迁移到 Desktop 和 Web 了
- Compose for Desktop 使用的是兼容 Swing/JavaFx 的 Skija： https://github.com/JetBrains/skija，和 Flutter for Desktop 思路类似
- Compose for Web 没看具体实现，如果和 Flutter for Web 思路一样，那么也是用 WebGL 版本 Skia
Narcissu5 14 小时 30 分钟前
一楼真的既不懂 c#，也不懂 java
c#的变革为什么可以很激烈，因为 CLR 上面基本没有生态这种东西，基本都是微软自家的东西，微软说变就变了。但是一旦入坑，你就会发现没有生态，特别是没有经过生产检验的生态是多么的无助
c#的变革为什么可以很激烈，因为 CLR 上面基本没有生态这种东西，基本都是微软自家的东西，微软说变就变了。但是一旦入坑，你就会发现没有生态，特别是没有经过生产检验的生态是多么的无助
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK