新年快乐！发发发！

@jaydenWang #42
https://valtio.dev/docs/guides/computed-properties

已经用了好几年 Valtio 了。Valtio 和 Zustand 是同一个作者写的。
Valtio 简洁到几乎只有 `proxy()`, `useSnapshot()` 两个函数。
同样是用 class 组织数据 (State) 、计算 (Computed) 和 行为 (Action)。
楼主的 Zenith 相比 Valtio 看不到优势。

https://valtio.dev/docs/how-tos/how-to-organize-actions

React 是没有 SFC 的，useEffect 是不长眼的，Hooks 的闭包是不通的！全世界这么多开发者写了这么一个 UI 库，怎么写的？我们把状态管理都运到 Zustand 怎么运的？怎么跟 memo 组件沟通的？怎么去跟 Fiber 协调的？天上地下依赖数组无限循环……怎么去做的这些事情？这个经验是无价的。

我写过 CSS in JS 你写过吗？我服务器让 CVE-2025-55182 挖过矿你挖过吗？我差点被 stale closure 坑死过你死过吗？复杂页面我把 prop drilling 干了你干过吗？ NPM 的 Hooks 我吃遍了你吃过吗？我能 Server Component 调 SQL 你会吗？我干了两件之前前端没人干的事，你干了吗？

> AI 是否有可能成为一种突破人类认知边界的工具？

AI 早已经是突破人类认知边界的工具，2024 的诺贝尔奖都颁给 AI 了。

> AI 是否有可能在没有人类明确指引的情况下，发现真实物理世界中的新现象，并总结出与之对应的物理定律或数学公式？

目前的 AI 只是工具，工具是没有目的的，还是需要人类的指令才能知道工作方法。以后 AGI 出来之后 AI 也许会有自己的目的。

> 这个世界本身就是可被完全计算的，只是其中绝大多数规律尚未被我们发现？

我相信是的，我完全相信「决定论」，我是「拉普拉斯妖」虔诚的信徒。

> 我们是否生活在一个类似“虚拟世界”的现实之中？

庄子、埃隆马斯克、萨姆奥特曼、基努里维斯和我都知道这个事实。

我是 2023 年第一批用 langchain.js 的，深受其害。

各种过度封装、过度设计。各种功能比如 Embeddings 、流式输出都有自己独创的一套写法。
一些 langchain 没有提供但是 API 提供的功能（比如 stream.include_usage ）就要绕一大圈来实现。

后来换到 openai sdk 后轻松多了。

2026 年 AI 能力很强了，20 岁开始做前端也不靠谱。

我都是写 reactive + class 的。
class 简直是天然的 store ，状态和方法一目了然。

```ts
import { reactive } from 'vue'

class ClientStore {
name = 'Alice'

get greeting() {
return `Hello ${this.name}`
}

updateName(newName: string) {
this.name = newName
}
}

export const client = reactive(new ClientStore())
```

我觉得有点本末倒置了，正常来说是 AI 生成代码再由人工审核。

我被 coderabbitai 审查过代码。个人感受就是被不熟悉业务的教条主义派指指点点。ai 会抱着各种设计模式、SOLID 原则对你的代码指手画脚、没有问题创造问题。

从 Remix 用到 React Router v7 ，非常好，生产环境跑得很稳。

小项目用过 Next.js ，跟 React Router v7 比完全是倒退：
- Next 用 "use server", "use client" 区分服务端组件和客户端组件，React Router v7 用 .server.jsx 和 .client.jsx 区分服务端组件和客户端组件，React Router 正常太多了；
- Next 的打包器 Turbopack 比 Vite 慢太多了，开发体验严重倒退；
- Remix 提出的 loader 比 RSC 好用一百倍，获取数据纯函数就行了，RSC 非得和视图耦合在一起，RSC 还有一堆限制，完全不是正常的 React 组件；

我选 tsx： https://tsx.is/

React Native 和 Flutter 各有各的优势，生态都算得上完善。

RN 的优势是使用 React + js/ts 开发，使用原生渲染。性能基本上没问题，一般页面确实像 native 一样流畅。
TypeScript + React 生态太好了，Zustand + nativewind 领先 Flutter 两个大版本。
使用 Expo 搭环境开发体验也很优秀。还有后悔药热更新。
RN 的劣势是多端 UI 不一致，一个样式你在 iOS 上调的很好看了到 Android 上就崩了，得仿佛来回调，增加了许多开发成本。

Flutter 的优势是自绘视图，也就是多端 UI 完全一致。之前使用 Skia 绘图引擎的时候与原生应用｜ React Native 在体验上较大差距； Impeller 全面应用之后 我自己体验下来流畅度是胜过 RN 、与原生应用伯仲之间的。
劣势是使用 Dart 作为开发语言，落后主流 UI 框架 一个大版本。别人 SwiftUI 、Kotlin Compose 、React 、Vue 写一个 Counter 组件多清晰简洁； Dart 、Flutter 非得整两个 class （ StatefulWidget + State ） 是有什么大病？
别人 Swift 、Kotlin 尾随 lambda 都多少年了、React JSX 都多少年了？你 Dart 2025 年还在嵌套地狱、答案抄都不会抄？
更别说状态管理了，Zustand 、Jotai 、Valtio 随便拎一个出来都领先 Riverpod 、BLoC 一个大版本。

选型建议：具体到开发团队，更熟悉 web 、js 生态的团队选 React Native ，更熟悉原生开发、安卓开发的团队选 Flutter 。具体到应用：自绘视图和复杂视图多的应用选 Flutter ，比如谷歌地球、高德地图；使用原生组件多的应用选 RN ，比如新闻、视频、聊天。

最后是幻想时间：希望 Flutter 尽早抛弃 Dart 改换 TypeScript + JSX 或 Kotlin ，这样生态、性能、多端一致性、开发体验一应俱全。

TypeScript 非常适合写业务。

Kysely, Drizzle 能无痛写出又灵活又类型安全的 SQL:
```ts
const persOns= await db.selectFrom('person').select(['id', 'age']).execute()
// persons: {id: number; age: number | null}[]
```
据我所知仅此 TypeScript 一家了。

@jchnxu #59

Drizzle, Kysely 和 上一代 ORM 的根本差别是，Drizzle, Kysely 希望在 TypeScript 尽可能舒服地写 SQL ，并提供 TypeScript 的一切功能（类型安全、智能提示）。
Prisma, TypeORM 设计一堆 Repository API: find, create, save... ；而 Drizzle, Kysely 选择完全还原 SQL: selece, insert...。
对于熟悉 SQL 的选手来说，使用 Drizzle, Kysely 读写数据库就像呼吸一样简单；而使用 Prisma, TypeORM 则需要反复查阅文档，不停学习 ORM 自创的 Repository API ，同时把握不住 Repository API 生成的 SQL 语句，对于复杂查询可能最终还是需要放弃 Repository API 使用 Raw SQL 。

https://www.youtube.com/watch?v=cTu9-C2rd-0

@bowencool #74
可以看一下 kysely-codegen ，直接从数据库把表结构以 TypeScript 类型定义的形式拉下来。

https://github.com/RobinBlomberg/kysely-codegen

@accelerator1 #63
Sequelize 研发的时间过于早了，Sequelize 刚开始发布的时候 TypeScript 还没有知名度。时至今日 Sequelize 对 TypeScript 的支持算不上好。我觉得将 Sequelize 是为 `TypeScript ORM` 是有点牵强的。
另外 Sequelize 在各个 benchmarks 中性能稳定垫底： https://orchid-orm.netlify.app/guide/benchmarks.html

我给 TypeScript ORM 排个名：

Drizzle > Kysely > Orchid ORM >> MikroORM > Prisma > TypeORM

Drizzle 、Kysely 已经是版本答案了：没有太花哨的功能，只需要写 SQL ，ORM | SQL Builder 将给你类型安全的查询结果。
Kysely 只是一个 SQL Builder ，类型安全方面做得也是最好的； Drizzle 在 SQL Builder 的基础上加了表结构定义，能满足表迁移的许多工作，因此把 Drizzle 排在 Kysely 前面。
Orchid ORM 非常小众，除了 SQL Builder 和表结构定义还加了许多 EntityManager | Repository 的糖，但主要还是以 SQL Builder 为主。

再之后就是传统的围绕 Entity 的 ORM 。这一类 ORM 都内置了丰富的 EntityManager | Repository 的功能，SQL Builder 功能只是作为兜底方案。这类 ORM 的通病是 Repository API 无法满足所有的 SQL 写法，到头来还是得写 SQL 。
这其中功能做的最全的是 MikroORM ，隐式事务、实体事件监听、过滤器、Migrations 、Seeding ，也内置了 Knex 作为 SQL Builder 。
Prisma 的主要槽点是：使用自己发明的 Prisma Schema 用于定义表结构、使用自己发明的 Repository API 用于读写数据库，后果是增加了学习成本，隐藏了许多细节碰到问题了不太容易排查；
TypeORM 毫无疑问垫底，连最基础的空安全和类型安全都不好。隔壁 MikroORM 6.5 已经在用 `defineEntity` 尝试摆脱了对 Decorators 的依赖。TypeORM 前两年都没怎么维护，今年有了新的团队接手才开始处理积攒了几年的 issue 。

虚无主义的回答：生命没有意义，宇宙没有意义，意义本身没有意义。

存在主义的回答：出生就是意义，求学就是意义，工作就是意义... 你就是意义本身。