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 。

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

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

在进电影院之前，受豆瓣评分的影响，对《浪浪山》抱有非常高的期待，看了几分钟就大失所望了。

画面上是合格的，但距离同期顶尖国漫 2D 有差距。

剧情上我完全不理解，主角四妖在选择赛道之前完全没有做调研，就开始了注定没有结果的取经路。
主角们完全不懂佛法，不明白取经是为了修行和普度众生，他们只知道孙悟空厉害，取经后能长生。

角色塑造方面，我感觉编导只想要角色的经历与观众的经历有呼应以方便观众带入，对角色塑造并不用心：
小猪妖在黄眉面前侃侃而谈，有这个嘴皮子本事在浪浪山那么多年还单干？在大王洞混了一天就被赶出门？
主角们的目标飘忽不定，我记得至少经历了如下变化：吃唐僧 -> 取经 -> 吃唐僧 -> 救小孩｜做自己。
最让我震惊的是主角们的道德底线：鸡鸭吃得、唐僧吃得、小孩吃不得。怎么唐僧低小孩一等呗？唐僧不是人呗？

最终黄眉还是问出了我最想问导演的问题：“你到底想要什么？”
猪妖说：“我想活成自己喜欢的样子！”给我整无语了。
你喜欢的样子就是活成取经团的影子？你喜欢冒名顶替？你喜欢在阴影里享受别人在阳光拼来的名声与成就？你喜欢百姓赞颂你的时候欢呼别人的名字？你喜欢一路躲着正主取经团走？

主角四妖从头到尾没有自己坚定的立场和目标，这样的妖注定一事无成。
如果主创们想要表达「世界就是个草台班子」，那么主创们成功了，这部电影里的每一个主角从始至终都非常碌碌无为。

真的好看，国漫 2D 顶尖水平。
画面、剧情、人物塑造各方面都挑不出毛病。

我反而认为西历（格里高利历）更乱，体现在不尊重天象上。

农历完全尊重天体运行：
以地球公转周期确定“年”，看影子长短知节气，从节气可以算出月份；
以月球公转周期确定“月”，看月相知日期；
为了弥补地月公转周期的余数，加入闰月；

反观西历：
西历的年的起点 1 月 1 日是人为强行规定的；而农历的正月初一可以从天象中算出；
月份长短是人为强行规定的，与实际月球运转周期完全不同；
置闰规则有偏差，现行的西历大概每三千年会有一天的偏差；

另外对楼主一些观点的回复：

> 完全没意识到 24 节气其实是由公历决定的，春秋分夏冬至在公历上一直都是 3/6/9/12 月的 20-22 号。
当然，因为 24 节气和西历都是按地球公转来决定的。

> 闰月和节气对普通人来说完全没有操作性。
身处西历的环境中，农历当然没有实操性。但对于下地干活的农民来说，反而是西历没有实操性。说到底这是因为近代以来，西方工业化较早，西方文化传入中国的结果。假如孙中山没有确立西历的地位，从官方到民间现在用的就仍然是农历。完全使用农历，我们甚至可以使用七十二候取代星期的概念，做三休二。

建议用 JQuery 。用 VUE 的不会纠结这个问题。

推荐 orpc( https://orpc.unnoq.com/ ) ：你只管写代码，orpc 会直接根据 zod 、valibot 类型生成 OpenAPI 文档。
更推荐 GQLoom ( https://gqloom.dev/ ) : 你只管写代码，GQLoom 会直接根据 zod 类型、valibot 类型、drizzle 表定义 、Prisma 模型定义生成 GraphQL 文档。

react 生态太好了，太多成熟的组件库可以用，比自己手写 html 好看太多了：
https://www.heroui.com/
https://ui.shadcn.com/
https://ui.aceternity.com/

React 、Vue 的框架都挺不错的，都是全家桶解决方法，看你喜欢哪个。下面是我个人的喜好和推荐：

可选框架：
- Next.js: 时下最流行的框架，生态丰富，功能齐全，但是使用 Turbopack 作为打包器，比 Vite 慢太多了，另外还有今年饱受争议的 React Server Component ，如果你喜欢 PHP 你可能会喜欢 React Server Component ；
- React Router V7 | Remix: React 全栈框架，架构设计比 Next.js 更干净，内置 Loader 、性能好过 Next.js ，对 APP 整体的掌控比 Next.js 更细致，使用 Vite 作为打包器开发体验良好；
- Nuxt.js: Vue 全栈框架，内置 Vue 全家桶，Vue 的开发体验其实一直比 React 要好，而且没有 React Hooks 的一堆坑，使用 Vite 作为打包器开发体验良好；

UI 与界面：
- shadcn/ui ( https://ui.shadcn.com/): 漂亮的可定制的 UI ，使用 Tailwind ，功能完善
- HeroUI ( https://www.heroui.com/ ): 超高颜值 UI ，使用 Tailwind ，组件齐全，开箱即用；

API 接口：
如果你使用了 Next.js 、React Router V7 、Nuxt.js ，你也许不需要额外的后端框架，直接用对应框架的后端功能就能解决大部分问题。
但是如果你想要给接口上工程化工具保证接口的强度和可靠性，那么我推荐：
- tRPC ( https://trpc.io/ ): 端对端类型安全接口，使用 TypeScript 确保接口可靠性；
- oRPC ( https://orpc.unnoq.com/ ): 端对端类型安全接口，以及 OpenAPI ，方便沟通、测试和回顾；
- GQLoom ( https://gqloom.dev/ ): 端对端类型安全接口，以及 GraphQL ，方便沟通、测试、回顾和 AI 阅读，与 Drizzle 、Prisma 深度集成，在几分钟之内构建完整的 CRUD 服务，（利益相关：我是 GQLoom 作者）；
- 不推荐 NestJS: NestJS 显示是设计过度了，TypeScript 没有 Java 那么多条条框框，TypeScript 装饰器由于其类型不健全也是逐年式微；

数据库操作：
- Prisma ( https://www.prisma.io/ ): 流行的 TypeScript ORM ，封装到位，对 SQL 的抽象程度比较高，适合写业务；
- Drizzle ( https://orm.drizzle.team/ ): 新兴的 TypeScript ORM ，性能出众，对 SQL 非常还原，适合熟悉 SQL 的选手；
- 不推荐 TypeORM: 近年维护不积极、类型不安全、空不安全

另外你可能需要了解：OpenAI 从 Next.js 转向了 Remix | React Router
https://www.youtube.com/watch?v=hHWgGfZpk00

分析一下我的思路：

1. 将数据库以 GraphQL 的形式暴露 API ，使用 Hasura 或 Graphile
2. 将 GraphQL 通过 MCP 连接到 AI ，使用 https://github.com/blurrah/mcp-graphql

楼主已经领悟到了响应式的真谛。
但倘若我拿出纯 TypeScript 响应式代码而且可以在 Vue3 、React + Valtio 、NestJS 、MikroORM 等几乎所有框架中无缝运行，阁下又该如何应对呢？

https://www.typescriptlang.org/play/?#code/MYGwhgzhAEAiD2BbAlgO3tA3gKGtY8qEALgE4Cuwx8pAFAA7kBGIyw0T8YpAJgIwAuaCVJoA5gEosAX2y5oYgKbEOXXgCZaUnHjyll5UqmgADACSZiAC2QQAdJ279p0dSfmz5SlY94BmLSx5PQMjUwtrWwc1HnUXP3c8WU8CIhUeJDQMAF5oVEUAdzhM9FoAckYIKzKJOVSIeBBFOxB4MXLffiEygBpoDJR0aKc+WvrG5tb2ss71br6BrOGNMcIGppa2jpi-ef6S+GWePwkgA

借楼提问：go 语言生成 OpenAPI ｜ Swagger 文档的最佳实践是怎样的？或者大家平常跟前端沟通都是手写文档的？

目前的 AI 还是在背答案，没法处理没见过的场景。
我让 Trae + Claude 搭一个 React-Router v7 + tailwind v4 的项目，AI 完全搭不出来。
leetcode 每日一题 中等以上的题 AI 写的代码有几题能过？
这两天爆火的 https://github.com/microsoft/typescript-go 能让 AI 写吗？
什么时候 AI 能写出 typescript-rust ?

我认为 AI 是数学、统计学的终极工具。现在的 AI 学习了海量的代码，并且有非常强的泛化能力。
从能力上看，现在的 AI 大部分是实习生|初级水平，能够识别和理解常见的技术问题，但需要依赖上级工程师（人类）的指导和帮助，问题解决的过程可能较慢，且容易出现反复。

再卷技术还有很大意义吗？有的，兄弟，有的，你需要成为中高级程序员才能更好地指挥 AI 帮你干活。

"90% of code will be written by AI in the next 3 months"
毫无疑问的是，AI 将为行业带来巨大的生产力的提升。现在 AI 给我的感觉是手底下多 3 个 实习生，我可以把重心放到更难的工作上，把脏活累活交给 AI 。

生产力的大幅提升对社会来说无疑是好事。
但对于我们这些从业者来说更多的是焦虑，也许我们会成为新一代无处可去的纺织工人，也许现在的 AI 已经到头了。
或许以后开发成本低了 个人就可以独立开发做出 WPS, Chrome, 黑神话悟空，这未尝不是好事？