nodejs 毕竟蛋疼的是破坏性变更、不向后/向前兼容
本地开发建议用 nvm 切换各个 node 版本
对于一些不兼容所有包管理器的项目，可以用 corepack 解决 (例如你的 pnpm 是 10.x ，项目 A 只能在 pnpm 8.x 下跑，可以不改动本地包管理版本去解决)。不过 corepack 是个实验性功能，并不稳定，未来还可能从 nodejs 移除变成单独的项目。
线上部署用 docker 。

ror 最优秀的地方在于极致地实现约定大于配置，以及魔法般的 DSL 。
有什么好处？就是极致地少写代码。

不同人有不同的喜好，就像我追求的是接近完美的类型安全，多写代码无所谓，反正现在大部分活是 AI 干的。而类型安全让我几乎杜绝各种傻逼运行时错误，可以安心地睡觉。你要说人菜那我无话可说，我本来就是一名普通的程序员，一定会犯错误，我只能希望能少犯错误。Ruby 很优秀与 Ruby 不适合团队协作并不冲突。

@ninjaJ tauri2.0 稳定版对移动端的支持依旧非常差，很多人连构建一个安卓/IOS 的 helloworld 都会失败。rust/js 对移动端没有多少可用的 api ，很多功能只能写原生代码，web 端和移动端复用逻辑非常困难。一堆构建失败的 issue 都没有解决，碰上了毫无办法。

@cloudzhou JavaScript 不值得投入，TypeScript 才值得投入，无类型的脚本语言只适合一个人编写，在团队协作上表现太差了，永远无法知道某个人在某个地方施放了什么恐怖的魔法。

大部分情况下 flutter 性能更佳，写前端更费劲点，Dart 表达画面的能力被 CSS 吊打； RN 性能稍差，前端部分更好实现，但是样式在不同平台不一致。硬要比就是半斤八两，确实很难抉择。uniapp 也不是不行，除此之外还有 KMM/KMP 也可以看看。
尝试过 Tauri mobile ，完全生产不可用，只能作为内部工具使用。
如果你们有 react 的历史包袱，或者更注重开发效率，那就选 RN ，如果 java 仔多，或者愿意仔细打磨产品就 flutter 。
不过当下原生或许是个更佳选择。

@hellodigua #3 确实，我几个月前离职想找纯前端的岗位，但是 boss 找了一圈没有一个自研的纯前端岗位，只能继续玩后端。假如一个项目需要 6 后端+4 前端，在 AI 时代可以砍掉 3 个前端 2 个后端保持差不多的开发效率，甚至因为精简人员减少了代码审阅成本效率反而提升不少。前端的护城河太浅了，那点东西玩不出不可替代性，等 web 前端开得差不多接下来就是客户端，笑到最后的是嵌入式。

并没有 xss 漏洞
https://maps.google.com/url?q=javascript:alert(1)
中间提示页就是用来解决这个问题的

nestjs 跟 java 的 spring 差不多，该有的功能都有了，适合特别喜欢依赖注入的 java/angular 人
nestjs 做的事比 fastify/express 这些 http 框架多一些，某些场景下它们会一起出现，如果是中小型项目直接用 Fastify/Express/egg 也行
我自己用 hono

写过 java 、kotlin 、c#、rust 、typescript ，使用过 30 款以上的 orm (mybatis, mybatis-plus, hibernate, jpa, ktorm, jooq, exposed, dapper, typeorm, prisma, sequelize 等等等等)，对我个人来说 typescript+drizzle 是目前的最优解。
因为近年来全面转向了 typescript ，nodejs 的全部 web 框架也都玩了一遍，我最喜欢 honojs ，elysiajs 也很好，不过不建议没有其他 web 框架经验的新手使用，因为在某些方面太过原始了，空白处都得从零编写。

很明显 AI 是去查百度，然后关键词被广告给污染了

如果优先考虑首屏渲染、打包体积，网站本身没有多少交互，就选 astro 。如果官网未来功能会比较复杂，那就选 nextjs 。

如果是 vue-i18n ，我试过三种做法

一：单文件自定义块
```
<i18n>
{
"zh-CN": {
"a": "xxx"
},
"en-US": {
"a": "yyy"
}
}
</i18n>
```
优点是可以快速搞定，AI 工具一直 Tab 就行了，大部分时间花在看 vue-i18n 文档，缺点是零散在几十几百个 vue 文件里，适合那种特别老的项目，不想额外管理 i18n 文件，且页面和文字几乎不会再改动。

二：json 文件
重构 i18n 确实烦人，但是如果还想正常迭代项目只能重构。将所有中文文本抽离出来，大致分类一下，再让 AI 一次性翻译完英文，然后手动一个个去替换原始文本 t('xxx.yyy')。我建议二层嵌套就行，顶多三层嵌套。

三：ts 文件
事先声明我这属于瞎折腾，用 json 方案就行了。
i18n-ally 和 vue-i18n 在 ts 文件上都有一些坑，搞了好久总算能用了，但是跟 json 方案比差不了多少。
这是我的 i18n-ally 的 vscode 配置文件
"i18n-ally.enabledFrameworks": ["vue"],
"i18n-ally.enabledParsers": ["ts"],
"i18n-ally.parsers.typescript.compilerOptions": {
"moduleResolution": "node"
}
这样就能正常识别 ts 文件

这是我的 i18n/index.ts 文件
import zhCN from './locales/zh-CN'
import enUS from './locales/en-US'

const messages: Record<I18n.Language, I18n.LocaleMessage> = {
'zh-CN': zhCN,
'en-US': enUS,
}

const i18n = createI18n({
locale: getStorage(StorageKeyEnum.language, 'zh-CN'),
fallbackLocale: 'en',
messages,
legacy: false,
})

export function setupI18n(app: App) {
app.use(i18n)
}

export function setLocale(locale: I18n.Language) {
i18n.global.locale.value = locale
}

export const t = i18n.global.t

LocaleMessage 是我的翻译文本类型
大概这样
type LocaleMessage = {
icon: {
...
}
route: {
...
}
tab: {
...
}
table: {
...
}
}

然后可以递归得到所有 key 的联合类型
type GetI18nKey<T, K extends keyof T = keyof T> =
K extends string ?
T[K] extends Record<string, unknown> ?
`${K}.${GetI18nKey<T[K]>}`
: K
: never

type I18nKey = GetI18nKey<LocaleMessage>

type RouteKey = GetI18nKey<LocaleMessage, 'route'>
type TableKey = GetI18nKey<LocaleMessage, 'table'>

在你需要硬编码比如路由元信息等地方用 I18nKey 类型进行限定就能完全消除硬编码
https://i.imgur.com/SUHCLUG.jpeg
https://i.imgur.com/PeuE0GI.jpeg

全用 post 。
现实是复杂的，RESTful 的表达能力不足以覆盖所有 case ，强行使用统一约定会让一些简单的东西变得难以理解。
2#说 `全用 POST ，那么安全审核无法直接区分这个 POST 是“新增”还是“删除”，只能靠解析 URL 或 Body ，这样更复杂印象性能且容易漏。`
为什么要区分是新增还是删除，而且一个接口本来就可以删除一些 A ，新增一些 B ，修改一些 C 。
真正的安全策略应该基于权限规则和业务逻辑，不应该简单地基于约定式的 Method ，它本质上和 /add /edit /del /info /page 一模一样，能严格遵守 RESTful 标准的人，同样能遵守自定义的语义要求。
我一直觉得接口的语义化完全没必要，一个硬编码玩出花来有什么意义，只要把代码给组织好就足够了。

语言的语法是用来增强表达的能力，你这个设计不太好，增加了阅读/编写的复杂度，但是收益无法抵消额外开销，在我看来是负优化，想在 java 里搞奇技淫巧的应该直接转 kotlin/scala ，别指望能在垃圾语言上屎上雕花，只能屎上雕屎。
命名参数这玩意，是为了把参数从水平转成垂直，就像浏览器的普通标签页 vs 垂直标签页，语法上想实现这种功能，一定要支持默认参数/可选参数，所以 java 只能洗洗睡了。
而且命名参数也不是最好的设计，js 不支持命名参数，但是 es6 的参数解构远比命名参数好用。

@llej node 实现 ts 类型严谨具体是指什么，是前端调用了不存在的接口就类型报错吗，调用对应接口拿到入参类型和返回类型？
你可以看一下 tPRC ，或者 hono 的 RPC ，虽然重构的工作量可能会很大。
hono 的 RPC 是后端导出一个或者多个路由实例类型给前端使用，客户端底层是基于 fetch 实现，前端调用这个接口就像直接调用后端接口方法一样，带来的收益是无需专门为接口类型定义一堆的类型到处混乱地引用，因为接口本身已经有类型了。
在你这个场景下，可以每个模块都导出一个路由实例，最后在基座包组装所有路由，再把类型导入到前端，最终得到包含所有接口路径、入参、返回类型的一个 http 客户端，前端只需要调用这个客户端就行，不存在的接口或者入参不对都会报错。你也可以让一部分路由只给同个顶级包下的前端模块引用，这样就实现了或许会用到的接口 public/private 修饰功能。

@williamx #84
如果接受了“谁能力强谁改”这种做法，那整个团队的平均水平就会由水平最差的那个人决定，这也同时严重影响了开发舒适度和个人前景。
正确做法是让能力不足的人滚蛋，换个能正常写代码的人进来。
说实话这就他妈一行小学生水平破代码的事，写不出来的还他妈能叫程序员？
data.map(({ x, ...rest }) => ({ ...rest, x: x.join(',') }))
就算是树结构也就 10 行的事。
type Data = { x: number[]; children?: Data[] }
type Data1 = { x: string; children?: Data1[] }
const res: Data[] = []
const recursive = (nodes: Data[]): Data1[] =>
nodes.map(({ x, children, ...rest }) => ({
...rest,
x: x.join(','),
...(children && { children: recursive(children) }),
}))
const data = recursive(res)
而且这跟简单还是困难无关，这就是前端必须要做的事情，写 100 行也好 1000 行也好就应该在前端处理。那个用字符串绑定的弱智组件也应该换个给地球人使用的正常组件。

@dssxzuxc #27 但是->或者

@Greendays #22 你说得对，可能后端不知道是偷懒还是设计上的限制依然需要所有 tags ，然后卡住了。试了几个 tag 数量很多的 repo ，加载都非常慢，而且每点一页都要等很久，好奇是写了什么屎山代码，但是不得不这么做没办法实现真正的分页，只能做假分页。