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 全栈。
直接不分前后端，能省不少麻烦。

不管是可读性、维护成本、性能、SEO ，Remix 都完胜 Server Component：
https://remix.run/blog/react-server-components

个人完全不能理解 Server Component 有什么用。
原本大部分 SSR 的前端应用是为了支持 SEO ，结果 Server Component 都不支持 SEO ，那要 Server Component 有什么用？

另外就是 Server Component 强行整了两套不同的规则和写法。
隔壁 Nuxt.js( https://nuxt.com/docs/getting-started/data-fetching#usefetch ) 整的多好：直接在组件内 await fetch 。

MongoDB 有什么不好，为什么不全放 MongoDB ？还望不吝赐教.

@ksmiloLove 2023 可以试试 tRPC( https://trpc.io/ )，比 GraphQL 要省事儿的多，代价则是牺牲了灵活性。

对于 Nest.js 应用来说，可以使用 [Code first] 的开发模式，只需增加少量代码即可切换到 GraphQL 。
Nest.js 内置了对 GraphQL 的一流支持，开箱即用： https://docs.nestjs.com/graphql/quick-start
配合 CodeGen( https://the-guild.dev/graphql/codegen )，客户端强类型 API 拿来就用。
用过 GraphQL 再也不会想回到 REST： https://www.apollographql.com/blog/graphql/basics/graphql-vs-rest/

都用 nestjs 了，直接 上 GraphQL 岂不美哉。GraphQL 出参不仅能过滤字段，还附赠强类型 API 文档，配合 CodeGen 客户端类型也省的写了。