@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

@fordoo #18

jwt 的出现就是为了无状态、不访问 db 。既然业务需求不能无状态，不如直接把 jwt 的签名、验证这一套省略了。用最简单的最直观的 session 模式。

vs code 设置里搜索：Http: Proxy
填上: https://127.0.0.1:7890

参考： https://v2ex.com/t/844018

https://nextui.org/

这才是面向 C 端的组件库，细节丰富，动画效果十分丝滑。
另外还天然集成 tailwind ，能够完全自定义。

让设计师把图扔到 Figma 或者蓝湖 或者 MasterGO 或者即时设计 上，前端根据需要自主选择导出的格式和尺寸

要出活快的话，Nuxt.js + tRPC 全栈。
直接不分前后端，能省不少麻烦。