vs code 能无痛远程开发，本地连环境都不用装，Goland 不能

你可能需要使用 zustand 或者 valtio 等状态管理库。

我个人是喜欢用 class 封装成 controller 的，然后在组件内使用 valtio 的 proxy 和 useSnapshot 来使用。

```ts
class BookController {
books: Record<string, Book> = {}

async getBooks() {
const books = await fetchBooks()
books.forEach((book) => {
this.books[book.id] = book
})
}

async createBook(book: Book) {
// ...
}
async updateBook(id: string, book: Book) {
// ...
}
}
```

在组件内使用：

```tsx
import { proxy, useSnapshot } from 'valtio'

const YourComponent = () => {
const controller = useMemo(() => proxy(new BookController()), [])
const { books } = useSnapshot(controller)

useEffect(() => {
controller.getBooks()
}, [controller])

const allBooks = Object.values(books)
const oneBook = books['bookId']

return (
<div>
{allBooks.map((book) => (
<div key={book.id}>{book.name}</div>
))}
<button onClick={() => controller.createBook(yourBook)}>创建</button>
</div>
)
}
```

valtio: https://github.com/pmndrs/valtio
zustand: https://github.com/pmndrs/zustand

Flutter 是个知名度很大但实际上并不怎么流行的框架。
我用 LibChecker 检查我手机上的 APP 有很多使用了 Flutter 的 SDK 。但实际上全面使用 Flutter 的只有《哔哩哔哩漫画》，有些 APP 部分页面使用 Flutter：《咸鱼》《飞猪》，更多是使用了 Flutter 的 SDK 但我找不到哪个页面是用 Flutter 写的：《微信》《微博》《豆瓣》《优酷》。
Flutter 视图是完全自绘的，交互体验上和 native 有很多不同，因此可以很容易判断哪个页面是不是用 Flutter 渲染的。比如在 Flutter 页面上双指滚动就能双倍滚动。

Flutter 成也自绘败也自绘。自绘的好处是可以在所有平台上获得一致的视图。坏处则是比不过原生的动画流畅性和交互体验，这方面有太多的 issues 了：动画反馈会延迟 1~3 帧，无法使用 Android 12 的滚动回弹动画，滑动和翻页时有明显的掉帧，严重的着色器编译时卡顿( https://docs.flutter.dev/perf/shader ) 。

总的来说 Flutter 开发的页面用户体验相比原生是明显倒退的，这可能也是为什么大厂不全面使用 Flutter 的原因。希望 Impeller 引擎完善之后能改进性能问题。

说到 Flutter 就不得不提老对手 React Native 。
RN 这两年在性能上做了诸多努力：0.68 支持 Fabric 渲染器架构，使用 jsi 与原生进程通讯，使得 js 与原生进程的通讯不再成为性能瓶颈； 0.70 使用 Hermes 作为默认 js 引擎，性能提升 51% - 63% ( https://reactnative.dev/blog/2022/07/08/hermes-as-the-default ) 。
另外 React Native 始终使用原生渲染，没有上面说的 Flutter 的一大堆问题。
假如原生的用户体验是 100 分，那么 RN 的上限就是 100 分，Skia 引擎的 Flutter 的上限是 90 分，希望 Impeller 引擎的 Flutter 的上限能达到 95 分以上。

再说 Dart 语言：我觉得本身 Dart 是门很不错的语言，奈何它的对手太强了，compose 的 kotlin 、RN 的 ts + jsx 、MAUI 的 C#。在一众优秀语言里 Dart 反而是平庸的。
Flutter 的状态管理方案也很难评，Flutter 生态里没有可以媲美 vue3 、或者 React 的 zustand 、jotai 、valtio 的状态管理库。Riverpod 略显啰嗦，GetX 相当于买了个冰箱送了个油烟机。

在现下总的来看：MAUI 和 Compose Multiplatform 还 too young ，担心踩坑没人管，那么还是得看 React Native 和 Flutter 。RN 在性能上不输 Flutter ；语言层面 TypeScript + jsx 优于 Dart ；生态上 npm 比 dart 繁荣得多，微软、Shopify 、京东、美团、Discord 、小米 都在大规模使用 React Native 。
结论是推荐 React Native 。

借楼吐槽一下 gRPC ，用着是真的麻烦：
1. 每次新加函数都要编写 .proto 文件，再重新代码生成；
2. protobuf 语法也很繁琐，在语言里序列号反序列化也麻烦；
3. 没有内置的负载均衡方案，需要另外实现或者网络配置；

马上 2024 年了，推荐使用 NATS 作为远程调用的方案：
✅使用 json ，简单高效
✅云原生、轻松水平扩展、高性能，服务与 NATS 之间始终保持连接，省去了反复建立 TCP 连接的开销
✅内置负载均衡、服务发现
✅可选的消息队列、键值存储

https://nats.io/
https://github.com/nats-io/nats.go/blob/main/micro/README.md

Protocol Buffers 是强类型的，能让通讯双方明确数据结构和类型，proto 文件本身具有文档的功能。
json 只是单纯的无类型数据，按 message Person { string params = 1; } 这么写过两个礼拜你自己都不知道 params 里有什么。

推荐一下 Nats 这个消息中间件。
Nats 是一款分布式消息平台，内置负载均衡、服务注册、消息队列等功能，很适合用来做微服务间通讯。

https://nats.io/
https://github.com/nats-io/nats.go/blob/main/micro/README.md

@ltq918 #39

Skia 版本的 Flutter 性能差用户体验不佳是众多开发者有目共睹的 ( https://github.com/flutter/flutter/projects/188 ) 。官方在文档里甚至专门提到了： https://docs.flutter.dev/perf/shader , https://flutter.cn/docs/perf/shader

Flutter 刚出那会儿手机的屏幕分辨率只有 60HZ ，因此 Flutter 的目标一直是 提供 60fps 的性能( https://docs.flutter.dev/perf/ui-performance )。然而这两年手机 120HZ 高帧率逐渐普及，Flutter 卡顿的缺点自然就被放大了。

Impeller 引擎目前在 iOS 上已经投入生产，Android 进度目前是 80% ( https://github.com/flutter/flutter/milestone/76 )，估计 Android 版本的 Impeller 能在明年正式投入生产。估计届时 Flutter 关于性能的 issue 会大大减少。

我对 Flutter 的前景还是很乐观的。谷歌地球使用 Flutter 已经有一段时间了，在 Web 上除了首屏加载时间慢其他体验还是很流畅的。

1. 语言
TypeScript + jsx 完胜 Dart

2. 性能
React Native 在各个系统上均使用原生渲染；
Flutter 现阶段在 iOS 上使用 Impeller 渲染引擎，在 Android 上使用 Skia 引擎；
Skia 版本的 Flutter 在滑动、翻页时存在明显卡顿，动画反馈也会延迟几帧，Impeller 版本的 Flutter
有的文章认为 Flutter 性能好于 React Native ，实际上是在说 dart 的性能好于 js 。然而 React Native 目前使用 jsi 与原生进程通信，性能与早期版本相比有大幅度改进，js 代码的执行速度已经不是瓶颈。
在现在这个时间点来看，React Native 的性能/动画流畅度/用户体验是好于 Flutter 的，但是 Flutter 的 Impeller 引擎完善之后估计会追平 React Native 。

3. 开发体验
Flutter 的环境搭建很方便，React Native 使用 expo 开发也很方便，React Native 使用 react-native-cli 的话搭环境会很麻烦。

4. 生态
RN 坐拥 npm 生态，虽然包质量稂莠不齐，但是 npm 的生态比 dart 繁荣得多。
全面使用 React Native 的 APP 很多：Discord 、Mattermost 、京东、https://reactnative.dev/showcase
全面使用 Flutter 的 APP 寥寥而已：哔哩哔哩漫画、彩云小梦，不得不再提一下这两个 APP 在动画流畅度方面是存在很大问题的。


在我个人看来 Flutter 相比 React Native 是没有优势的，作为用户来说 Flutter 开发的 APP 体验是倒退的。
除了 React Native 环境搭不好的情况，现阶段还是推荐 React Native 。

“flutter 比 react native 性能要好”，这个结论是怎么得出来的？

flutter 成也自绘自绘。自绘的好处是能对 UI 精准把控，坏处则是性能比不过原生。
Flutter 刚出那会儿手机还流行 60FPS ，性能劣势还不明显。近些年手机逐渐逐渐普及 120FPS 高帧率，Flutter 的卡顿就被放大了。

我用过的 Flutter 应用就没有流畅的，包括《哔哩哔哩漫画》、《彩云小梦》。
所有 Flutter 应用不可避免地存在渲染卡顿、不跟手的问题。这是 Skia 绘图引擎的缺陷，Flutter 团队为此不得不自研 Impeller 引擎。Impeller 目前还在开发，不知道什么时候能完成，也不知道 Impeller 相较于 Skia 有多大提升、离 Native 有多大差距。
反观 React Native ，使用 Native 渲染，动画效果、滑动流畅度都达到了原生的水准。js 的性能确实比不过 dart ，但是 js 也不慢，不会有使用体验上的下降。

在我看来 Java 缺少好用的 ORM 。就这一点足以否决 Java 作为互联网项目的后端。
C# 有 EF Core 、Ruby 有 Active Record 、php 有 Eloquent 、TypeScript 有 MikroORM 、kotlin 有 Ktorm ，连 Rust 这样的编译型语言都有 SeaORM 。
别的语言已经用 OOP 语法完成 CURD 业务了，Java 还在用 MyBaits 手写拼接 SQL 。

都说 Java 生态好，可是连最基础的 ORM 都没有好用的。在我看来真正生态繁荣的是 Node.js 背后的 npm 生态，当然 npm 过于繁荣、各种包库卷出花来，质量更是良莠不齐...

说的好，但是我选择 strapi: https://strapi.io/

nodejs+react 还有一个好处是可以很轻易实现前后端类型安全： https://trpc.io/

省去了前后端沟通的时间，只要后端写了强类型的接口，前端就可以愉快地调用了。

我已经搞了很久 nodejs react 全栈了。
结论是 nodejs 作为后端来说是很不错的。

首先 nodejs 的 io 模型性能极好，正常 curd 业务的处理速度不比 Java/Go 差。真有 CPU 密集场景，那也可以直接调用 C++/Rust : https://napi.rs/

更重要的是 node.js 的 crud 开发体验要比 Java/Go 好得多，nodejs 生态下有 Prisma 、MikroORM 、TypeORM 这些兼顾类型安全、开发效率的 ORM 。据我所知 Java/Go 生态下是没有可以媲美的 ORM 类库的。

还有就是 js/ts 的语言特性。js 这门语言很烂，一般都会选择上 ts 。ts 的面向对象语法和 C#/Java 很贴近，时下火热的 nestjs 就一股 spring 味。

正常语言调用函数一般只需要 1 行，而 go 语言需要 4 行，也算是一种繁琐吧。

不是什么新鲜的技术 ，别大惊小怪的
三四年前阿里就有 imgcook 了： https://www.imgcook.com/

这类机器生成的代码一般缺少交互逻辑，可维护性也不好。很难在真实项目中使用。

前端复杂就复杂在交互逻辑，比如点击按钮、输入框内容判断
要是纯静态的页面，Figma 、MasterGo 、蓝湖这类设计工具生成代码也很容易。

@kidlj #13
ent 是这么更新的：
n, err := client.Blog.
Update().
Where(
blog.Url("http://example.com"),
).
SetUrl("http://example.com/blog").
SetTitle("The Last Theorem").
SetAuthor("Clarke").
Save(ctx)

ent 比 gorm 要严谨得多，而代价则是啰嗦的指令式调用，极大损失了灵活性。

与 ent 相比，同样使用代码生成的 node.js 的 prisma 是这么更新的:
const bolg = await prisma.blog.update({
where: {
url: "[email protected]",
},
data: {
url: "Viola the Magnificent",
title: "The Last Theorem",
author: "Clarke",
},
});
prisma 将查询参数和更新数据全都赛进 update() 中，更容易实现动态参数。

跟 C# 的 EF Core 比，MyBatis 最多算一个 SQL Builder 。
好的 ORM 应该尽可能减少 SQL 的书写，尽量自动化，尽量贴近语言原生语法。
看过 C# 的 Entity Framework 、Ruby 的 Active Record 、php 的 Eloquent 、Typescript 的 MikroORM 、kotlin 的 Ktorm
才知道什么是好用的 ORM 。相比之下 Java 、go 生态下缺少好用的 ORM 框架。

优雅的 ORM (EF Core)是这么更新的：
using (var context = new BloggingContext())
{
var blog = context.Blogs.Single(b => b.Url == "http://example.com");
blog.Url = "http://example.com/blog";
context.SaveChanges();
}
使用 C# LINQ 表达式写查询，直接修改 blog.URL 的值再保存修改，真正的面向对象、真正的自动化，开发人员甚至不需要深入了解 SQL ，极大减轻了开发时的负担；

GORM 是这么更新的：
db.Model(Blog{}).Where("Url = ?", "http://example.com").Updates(Blog{Url: "http://example.com/blog"})
在 gorm 自身的语法 "db.Model().Where().Updates()"之中混入半句 sql "url = ? "，这就要求开发人员既要会 sql 也要熟悉 gorm 额外的语句，开发时的性质负担并没有减少；

死亡真的很可怕，一旦死亡之后，这世间的一切美好都和我再无关系。
死了以后，我不能再有一个悠闲的周末，我不能再打开一次 steam 在电脑前坐两天，我不能再去街尾的面馆点一碗拉面，我不能再去肯德基点一份吮指原味鸡。

哪怕死后会有后人祭奠，哪怕名垂青史，这一切和我也再无关系。

然而死和生是一样的频繁，死亡以后和出生之前其实是一样的。我可能无法想象 2077 年的我身处何方，正如我无法想想 1977 年的我身处何方。

我只能选择去相信轮回，相信一缕意识来这世间不是偶然，相信“我”会再次降临世间。