https://www.notion.so/Better-than-JSON-2c3b546fcb2d81ca96edeb3d7c7b3830?source=copy_link
一篇安利 Protobuf 的文章，认为多数情况下 Protobuf 比 JSON 更好，但我不这么认为。曾经我也是 PB 的狂热拥趸，为它写过很多工具和轮子，甚至一度尝试开发一个 Protobuf -> TypeScript interface + react-router 的代码生成器，企图用 Protobuf 进行所有的 web 开发，还好中途没时间就放弃了（这可能是我最庆幸的一次弃坑）。
Protobuf 的一些问题，首先它不仅是一个数据的序列化协议，还包含了 schema validation 的规则，这与 JSON 纯粹截然不同。数据传输到端后，不只是要反序列化，还要做结构验证，JSON 可以用 JSON Schema 来表达丰富的 schema，或者用 zod / valibot 等库以代码的形式定义，但 Protobuf 只能遵循自己的协议，因此表达能力严重不足，比方说不支持 required 字段、不能区分空值和未传递字段（null 与 undefined 的区别）等等。归根究底，它是为了高度的向前、向后兼容性，牺牲了自身的功能。所以我觉得它更适用于一些特定的场合，比方说在一些极高性能的微服务之间传递相对扁平的结构数据，或者在特别重要的基础服务之间使用，以此确保数据格式的变更不会产生兼容问题。而这些都不是复杂多变的 web 服务所强需求的。JSON 的零成本启动、人类可读等特性都能大大降低项目进行的阻力和调试的难度。
另外，我一直坚信实用主义胜过一切，JSON 虽然也有各种各样的问题被人诟病，有无数「方言」想要改进和取代它，但它始终是最流行的序列化格式，我想这是 “Worse is Better” 的又一个佐证。相对于 Protobuf 追求完美的正确性、一致性和完整性，JSON 追求的是实现的简单性，哪怕功能有点残缺，只要它简单、能跑、容易传播，那么它就会成为更好的。对 JSON 的各种抱怨，恰恰是因为它被用的最多，还很难换掉，你说气不气？这么想，感觉也可以跟 YAML 和解了😛
一篇安利 Protobuf 的文章，认为多数情况下 Protobuf 比 JSON 更好，但我不这么认为。曾经我也是 PB 的狂热拥趸，为它写过很多工具和轮子，甚至一度尝试开发一个 Protobuf -> TypeScript interface + react-router 的代码生成器，企图用 Protobuf 进行所有的 web 开发，还好中途没时间就放弃了（这可能是我最庆幸的一次弃坑）。
Protobuf 的一些问题，首先它不仅是一个数据的序列化协议，还包含了 schema validation 的规则，这与 JSON 纯粹截然不同。数据传输到端后，不只是要反序列化，还要做结构验证，JSON 可以用 JSON Schema 来表达丰富的 schema，或者用 zod / valibot 等库以代码的形式定义，但 Protobuf 只能遵循自己的协议，因此表达能力严重不足，比方说不支持 required 字段、不能区分空值和未传递字段（null 与 undefined 的区别）等等。归根究底，它是为了高度的向前、向后兼容性，牺牲了自身的功能。所以我觉得它更适用于一些特定的场合，比方说在一些极高性能的微服务之间传递相对扁平的结构数据，或者在特别重要的基础服务之间使用，以此确保数据格式的变更不会产生兼容问题。而这些都不是复杂多变的 web 服务所强需求的。JSON 的零成本启动、人类可读等特性都能大大降低项目进行的阻力和调试的难度。
另外，我一直坚信实用主义胜过一切，JSON 虽然也有各种各样的问题被人诟病，有无数「方言」想要改进和取代它，但它始终是最流行的序列化格式，我想这是 “Worse is Better” 的又一个佐证。相对于 Protobuf 追求完美的正确性、一致性和完整性，JSON 追求的是实现的简单性，哪怕功能有点残缺，只要它简单、能跑、容易传播，那么它就会成为更好的。对 JSON 的各种抱怨，恰恰是因为它被用的最多，还很难换掉，你说气不气？这么想，感觉也可以跟 YAML 和解了😛