在我看来 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 定义接口就是在浪费时间。

为什么不上 TypeScript ？ ts 语法和 Java 、C#很接近啊，我管 ts 叫 C# lite 。

Rspack 真的很香。
之前 nodejs 服务打包都是用的 Webpack ，但是 Webpack 编译太慢，开发时不得不用 ts-node 、tsx 这类即时运行的工具跑 nodejs 应用。生产时为了减少应用体积，会对项目进行 Webpack 打包，将项目编译成单个 js 文件，然而这导致项目部署时经常报依赖错误🥲。
换了 Rspack 之后，得益于 Rspack 飞快的编译速度，开发时能够直接 "rspack build --watch && node --watch dist/index.js"运行编译产物，开发和生产环境的终于能够保持一致。
也试了 esbuild 、swc 、vite ，但是都对 node.js 的编译打包支持不太好，难以正确处理所有依赖(尤其是 .node 文件)。

你说的对，在 2023 年 useReducer 和 Redux 可以说是最落后的状态管理方案了。

现在有好的多的状态管理解决方案：
喜欢 Redux 这种单向数据流思维的可以用： https://github.com/pmndrs/zustand
喜欢 React Hook 函数式思维的可以用： https://github.com/pmndrs/jotai
喜欢 vue3 reactive 的可以用： https://github.com/pmndrs/valtio

早期 React 状态管理大家都是摸着石头过河，难免会走出 useReducer 和 Redux 的弯路。

我理解 build 是把源代码编译成可直接运行的代码，比如把 ts 编译成 js ，把 ESNext 编译成 ES5 ，把 js 编译成字节码。
常用的工具有：
https://github.com/microsoft/TypeScript
https://github.com/babel/babel
https://github.com/swc-project/swc
https://github.com/bytenode/bytenode

打包(bundle | pack)根据不同的项目类型有不同的操作。

对于通用模块项目(npm package)，打包需要将源代码编译成 esm 模块以及 cjs 模块，有时还需要输出 .d.ts 类型声明文件。
常用的工具有：
https://github.com/rollup/rollup
https://github.com/evanw/esbuild
https://github.com/unjs/unbuild
https://github.com/egoist/tsup
https://github.com/developit/microbundle

对于应用项目(app)，打包需要将源代码以及依赖资源(cs, json, 图片, 甚至 node 本身) 构建成静态文件或者可执行文件，目的是减少 app 体积、方便部署。
常用的工具有：
https://github.com/evanw/esbuild
https://github.com/vitejs/vite
https://github.com/webpack/webpack
https://github.com/web-infra-dev/rspack
https://github.com/nexe/nexe
https://github.com/vercel/pkg