现代化 nodejs 已经没这么大了，我打开包含前后端的全栈项目看了下，60 多个依赖包，总大小 358M ，去掉 typescript 还能再少一半。
nodejs 体积庞大的基本都是陈年屎山，而且大概率换个电脑就跑不起来。

@mrlmh00 #13 研究了一下
https://github.com/shuding/nstr/blob/main/src/index.ts#L64-L77
进位失败是因为
451.78+0.01 = 451.78999999999996
而不是期望的 451.79
需要一个更稳健的进位方法来解决这个问题

@chesha1 #10 我觉得我在 4#的例子已经很有说服力了，在你想展示几个浮点数的计算结果时，你希望写的是
new Decimal(a).plus(new Decimal(b).times(new Decimal(c))).minus(new Decimal(d))
还是
nstr(a+b*c-d)

毕竟 chatgpt 手上没有计算器，也无法调用资源去进行运算，chatgpt 只是一个文本生成大模型，如果训练材料里有正确答案，那大概率可以输出正确答案，没有的话只能瞎猜了。
我之前的做法是封装一个 js 沙盒计算接口，让 chatgpt 生成输入条件，遇到数字处理基本都能解决。而后来这种类似操作有个专门的名词，叫 function call ，用于处理大模型不擅长的地方，例如计算、联网搜索等等，至于为什么 chatgpt 免费版没有这功能，你的标题已经说了，免费用户不是用户。
另外我刚问了 chatgpt ，计算是对的，当出现"思考"动作就会去调用计算程序，只是免费的有额度，瞎几把乱算是完全正常的。

@mrlmh00 #7
这个库只是用来处理 0.1+0.2=0.30000000000000004 这种问题的，让简单的浮点计算适合人类阅读
产生这种问题的浮点数都有个共同的特点：一连串的 0 或者 9 ，所以这个库就检测 0/9 连续出现的次数，超过判断条件后截断全部 0/9 最后简单处理一下进位
需要多位小数严谨计算的应该用 decimal.js, bignumber.js
这个库我觉得已经说得很清楚了，nstr ，就是数字转字符串，字符串是用来看的不是计算的，不需要严谨小数点计算的前端纯展示场景非常非常多

确实 looks good, 源码才 113 行，实现方法很巧妙。

console.log(new Decimal('0.1').plus(new Decimal('0.2')).toString())
vs
console.log(nstr(0.1+0.2))

因为设计使然，超过 4 位(可自行设定)的 9 和 0 会被认为是噪音然后截断处理，不适用多位小数严格计算场景，其他场景都不错。

@wangtian2020 #22 这就得问 noble 为什么不采用预编译或者 rs-napi 或者 wasm 而使用 node-gyp 去现场编译了，当然大部分项目是因为历史包袱甩不掉，还能更新就已经很不错了。node-gyp 依赖 python 运行时环境，本机上找到什么版本就用什么，毕竟重新下载一个指定的 python 版本去构建太蛋疼了，真要这样说不定有些项目 npm install 吭哧吭哧下好几个不同版本 python 下来，而 python 运行时对基础环境有要求，node-gyp 对 python 版本有要求，Node.js -> node-gyp -> Python -> C++ 编译器 -> 核心系统库 -> 目标产物，这是一个十分不稳定且脆弱的流程，无论发生什么都可以算预期行为。
真要说起来这也是 nodejs 的锅，因为原生模块性能比 js 好，那注重性能的都会去写原生，但是 c++产物无法跨平台运行，你在 A 平台写好了，别的平台也想用但没有精力去适配，就有了 gyp ，就有了封装专注 nodejs 的 node-gyp ，就有了 node-sass 等包带来的一地鸡毛。

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