推荐一下 Nats 这个消息中间件。
Nats 是一款分布式消息平台，内置负载均衡、服务注册、消息队列等功能，很适合用来做微服务间通讯。

https://nats.io/
https://github.com/nats-io/nats.go/blob/main/micro/README.md

@ltq918 #39

Skia 版本的 Flutter 性能差用户体验不佳是众多开发者有目共睹的 ( https://github.com/flutter/flutter/projects/188 ) 。官方在文档里甚至专门提到了： https://docs.flutter.dev/perf/shader , https://flutter.cn/docs/perf/shader

Flutter 刚出那会儿手机的屏幕分辨率只有 60HZ ，因此 Flutter 的目标一直是 提供 60fps 的性能( https://docs.flutter.dev/perf/ui-performance )。然而这两年手机 120HZ 高帧率逐渐普及，Flutter 卡顿的缺点自然就被放大了。

Impeller 引擎目前在 iOS 上已经投入生产，Android 进度目前是 80% ( https://github.com/flutter/flutter/milestone/76 )，估计 Android 版本的 Impeller 能在明年正式投入生产。估计届时 Flutter 关于性能的 issue 会大大减少。

我对 Flutter 的前景还是很乐观的。谷歌地球使用 Flutter 已经有一段时间了，在 Web 上除了首屏加载时间慢其他体验还是很流畅的。

1. 语言
TypeScript + jsx 完胜 Dart

2. 性能
React Native 在各个系统上均使用原生渲染；
Flutter 现阶段在 iOS 上使用 Impeller 渲染引擎，在 Android 上使用 Skia 引擎；
Skia 版本的 Flutter 在滑动、翻页时存在明显卡顿，动画反馈也会延迟几帧，Impeller 版本的 Flutter
有的文章认为 Flutter 性能好于 React Native ，实际上是在说 dart 的性能好于 js 。然而 React Native 目前使用 jsi 与原生进程通信，性能与早期版本相比有大幅度改进，js 代码的执行速度已经不是瓶颈。
在现在这个时间点来看，React Native 的性能/动画流畅度/用户体验是好于 Flutter 的，但是 Flutter 的 Impeller 引擎完善之后估计会追平 React Native 。

3. 开发体验
Flutter 的环境搭建很方便，React Native 使用 expo 开发也很方便，React Native 使用 react-native-cli 的话搭环境会很麻烦。

4. 生态
RN 坐拥 npm 生态，虽然包质量稂莠不齐，但是 npm 的生态比 dart 繁荣得多。
全面使用 React Native 的 APP 很多：Discord 、Mattermost 、京东、https://reactnative.dev/showcase
全面使用 Flutter 的 APP 寥寥而已：哔哩哔哩漫画、彩云小梦，不得不再提一下这两个 APP 在动画流畅度方面是存在很大问题的。


在我个人看来 Flutter 相比 React Native 是没有优势的，作为用户来说 Flutter 开发的 APP 体验是倒退的。
除了 React Native 环境搭不好的情况，现阶段还是推荐 React Native 。

“flutter 比 react native 性能要好”，这个结论是怎么得出来的？

flutter 成也自绘自绘。自绘的好处是能对 UI 精准把控，坏处则是性能比不过原生。
Flutter 刚出那会儿手机还流行 60FPS ，性能劣势还不明显。近些年手机逐渐逐渐普及 120FPS 高帧率，Flutter 的卡顿就被放大了。

我用过的 Flutter 应用就没有流畅的，包括《哔哩哔哩漫画》、《彩云小梦》。
所有 Flutter 应用不可避免地存在渲染卡顿、不跟手的问题。这是 Skia 绘图引擎的缺陷，Flutter 团队为此不得不自研 Impeller 引擎。Impeller 目前还在开发，不知道什么时候能完成，也不知道 Impeller 相较于 Skia 有多大提升、离 Native 有多大差距。
反观 React Native ，使用 Native 渲染，动画效果、滑动流畅度都达到了原生的水准。js 的性能确实比不过 dart ，但是 js 也不慢，不会有使用体验上的下降。

在我看来 Java 缺少好用的 ORM 。就这一点足以否决 Java 作为互联网项目的后端。
C# 有 EF Core 、Ruby 有 Active Record 、php 有 Eloquent 、TypeScript 有 MikroORM 、kotlin 有 Ktorm ，连 Rust 这样的编译型语言都有 SeaORM 。
别的语言已经用 OOP 语法完成 CURD 业务了，Java 还在用 MyBaits 手写拼接 SQL 。

都说 Java 生态好，可是连最基础的 ORM 都没有好用的。在我看来真正生态繁荣的是 Node.js 背后的 npm 生态，当然 npm 过于繁荣、各种包库卷出花来，质量更是良莠不齐...

说的好，但是我选择 strapi: https://strapi.io/

nodejs+react 还有一个好处是可以很轻易实现前后端类型安全： https://trpc.io/

省去了前后端沟通的时间，只要后端写了强类型的接口，前端就可以愉快地调用了。

我已经搞了很久 nodejs react 全栈了。
结论是 nodejs 作为后端来说是很不错的。

首先 nodejs 的 io 模型性能极好，正常 curd 业务的处理速度不比 Java/Go 差。真有 CPU 密集场景，那也可以直接调用 C++/Rust : https://napi.rs/

更重要的是 node.js 的 crud 开发体验要比 Java/Go 好得多，nodejs 生态下有 Prisma 、MikroORM 、TypeORM 这些兼顾类型安全、开发效率的 ORM 。据我所知 Java/Go 生态下是没有可以媲美的 ORM 类库的。

还有就是 js/ts 的语言特性。js 这门语言很烂，一般都会选择上 ts 。ts 的面向对象语法和 C#/Java 很贴近，时下火热的 nestjs 就一股 spring 味。

正常语言调用函数一般只需要 1 行，而 go 语言需要 4 行，也算是一种繁琐吧。

不是什么新鲜的技术 ，别大惊小怪的
三四年前阿里就有 imgcook 了： https://www.imgcook.com/

这类机器生成的代码一般缺少交互逻辑，可维护性也不好。很难在真实项目中使用。

前端复杂就复杂在交互逻辑，比如点击按钮、输入框内容判断
要是纯静态的页面，Figma 、MasterGo 、蓝湖这类设计工具生成代码也很容易。

@kidlj #13
ent 是这么更新的：
n, err := client.Blog.
Update().
Where(
blog.Url("http://example.com"),
).
SetUrl("http://example.com/blog").
SetTitle("The Last Theorem").
SetAuthor("Clarke").
Save(ctx)

ent 比 gorm 要严谨得多，而代价则是啰嗦的指令式调用，极大损失了灵活性。

与 ent 相比，同样使用代码生成的 node.js 的 prisma 是这么更新的:
const bolg = await prisma.blog.update({
where: {
url: "[email protected]",
},
data: {
url: "Viola the Magnificent",
title: "The Last Theorem",
author: "Clarke",
},
});
prisma 将查询参数和更新数据全都赛进 update() 中，更容易实现动态参数。

跟 C# 的 EF Core 比，MyBatis 最多算一个 SQL Builder 。
好的 ORM 应该尽可能减少 SQL 的书写，尽量自动化，尽量贴近语言原生语法。
看过 C# 的 Entity Framework 、Ruby 的 Active Record 、php 的 Eloquent 、Typescript 的 MikroORM 、kotlin 的 Ktorm
才知道什么是好用的 ORM 。相比之下 Java 、go 生态下缺少好用的 ORM 框架。

优雅的 ORM (EF Core)是这么更新的：
using (var context = new BloggingContext())
{
var blog = context.Blogs.Single(b => b.Url == "http://example.com");
blog.Url = "http://example.com/blog";
context.SaveChanges();
}
使用 C# LINQ 表达式写查询，直接修改 blog.URL 的值再保存修改，真正的面向对象、真正的自动化，开发人员甚至不需要深入了解 SQL ，极大减轻了开发时的负担；

GORM 是这么更新的：
db.Model(Blog{}).Where("Url = ?", "http://example.com").Updates(Blog{Url: "http://example.com/blog"})
在 gorm 自身的语法 "db.Model().Where().Updates()"之中混入半句 sql "url = ? "，这就要求开发人员既要会 sql 也要熟悉 gorm 额外的语句，开发时的性质负担并没有减少；

死亡真的很可怕，一旦死亡之后，这世间的一切美好都和我再无关系。
死了以后，我不能再有一个悠闲的周末，我不能再打开一次 steam 在电脑前坐两天，我不能再去街尾的面馆点一碗拉面，我不能再去肯德基点一份吮指原味鸡。

哪怕死后会有后人祭奠，哪怕名垂青史，这一切和我也再无关系。

然而死和生是一样的频繁，死亡以后和出生之前其实是一样的。我可能无法想象 2077 年的我身处何方，正如我无法想想 1977 年的我身处何方。

我只能选择去相信轮回，相信一缕意识来这世间不是偶然，相信“我”会再次降临世间。

同意楼主，这个 Nue 看起来像是自嗨项目。

React 提出了组件概念和声明式 UI ，
Vue 使得数据与视图绑定更简便，开发体验大大提升，
Solid 解决了 React 性能的问题，
Svelte 不仅通过编译时极大提升性能，API 设计甚至比 Vue 更简单，

而 Nue 目前看来没有任何亮点

Node.js 很好，生态繁荣，又有 TypeScript 这样的工程化语言。

单说 ORM 这一个场景，Node.js 的 TypeORM 、Prisma 、MikroORM 的简便和易用是 Java /go 的 ORM 无法比拟的。

至于 go 语言，个人觉得 go 是一个 Better C ，适不适合写后端业务是颇具争议的：
[说 Go 语言写不了业务逻辑的请进] https://www.v2ex.com/t/871389
[Go 写业务真的是好的选择吗] https://www.v2ex.com/t/912958
[看到 Go 与 MongoDB 的交互方式，我想放弃 Go 了] https://www.v2ex.com/t/810126
[我也打算逐步放弃 Go 语言] https://www.v2ex.com/t/967244

谢谢楼主，支持一下

当然是 node 全栈，前后端通讯使用 trpc: https://trpc.io/
来感受前后端类型安全的快乐，从此觉得在 go ，php ，java 定义接口就是在浪费时间。