源起
当今互联网的开发模式充斥着低效与重复，我对此深感厌倦，并决心以组件化的方式重构它。
市面上已有一些组件化产品，例如：
auth0：用户系统stripe：在线支付Disqus：网页评论algolia：站内搜索
而且，作为一个完美主义者，以上产品无一能让我满意。
auth0缺少类似谷歌的「多账户切换」功能，且价格高昂，每月一万用户竟需 7700 美元。stripe的微信、支付宝通道费率高达2.2% + $0.35，而直连费率仅0.6%，堪称暴利。Disqus无法针对特定语句评论，评论亦不能自动翻译成用户的浏览语言。algolia的搜索结果旁应提供正文预览，类似苹果 Finder 的「速览」功能。
并且，这些零散的组件各自为政，整合过程既繁琐又复杂。
个人开发者若想开发并销售一套类似的网页组件，就必须独立构建令牌、订阅、工单等一系列配套系统，研发成本极高。
因此，我希望能创建一个类似苹果应用商店的网页组件市场，基础设施开源，并提供免费的云服务。
将所有服务整合至统一的账户体系下，并赋能个人开发者研发、销售组件。
这是一个庞大的构想。
幸运的是，我并非那种「我有一个好想法，就差个程序员了」的空想家。
我，就是那个程序员。
技术
动工之前，必先确定底层技术架构。
勿在浮沙筑高台。
在技术层面，我亦有诸多想法。
前端
前端，我构思了一套基于 importmap 与 svelte 的方案，旨在实现无打包、零运行时依赖的组件化开发。
这让用户可以灵活替换、覆盖组件样式和内部逻辑，进行二次开发。
后端
后端，我设计了一套 rust → protobuf → grpc → http 的自动化映射流程。
能自动生成相应的 js 代码，将 rust 函数无缝映射为前端函数。
目前，我正全力实现此后端方案，代码库: js0-grpc。
我选择 protobuf 作为前后端通信的数据格式，并为此实现了一个压缩后仅 1KB 左右的编解码器。
| file | minify | zstd | gz | br |
|---|---|---|---|---|
| demo/test/D.js | 1896 | 1039 | 1031 | 949 |
| demo/test/E.js | 1596 | 869 | 865 | 789 |
| demo/test/echoD.js | 892 | 526 | 523 | 473 |
| demo/test/echoE.js | 700 | 429 | 426 | 405 |
这世上，屎山般的代码俯拾即是。难以想象，在我之前，主流 js 的 protobuf 编解码器体积竟以 MB 计算。
如下图所示，Protobuf-ES 一文便展示了其项目中 protobuf 编解码器惊人的尺寸开销 ── 这正是前端鲜少采用 protobuf 的主因。
坦白说，json 格式相当冗余，反复传输的键名浪费了大量带宽。
虽然，我的 protobuf 编码器虽有 1KB 左右的额外开销，但这部分成本很快便能被节省下的数据传输带宽所抵消。
至于 http 与 grpc 的交互，我计划用 rust 和 tokio 实现一个全新的请求转换网关，它支持自动前端将的多个 grpc 并发请求合并为单一 http 请求。
例如，当网站首页几乎同时发起「请求用户名」和「请求用户消息流」这两个 RPC 调用时，前端会通过一个类似 setTimeout(()=>{mergePendingRpcCall()},10) 的节流函数，自动将它们合并为单次 http 请求，从而进一步减少传输开销、降低后端接口的耦合度。
结尾
每个人都期待能做一些改变世界而不是卖糖水的事情。
一个人写代码是孤单的，就像与风车作战的堂吉柯德。
欢迎感兴趣的朋友参与开发，一起来创造美丽新世界。
我们用 邮件列表 来讨论，欢迎加入。
想法很多，想法很廉价。
与其临渊羡鱼，不如退而结网。
暂述至此，我继续去写代码了。
Talk is cheap. Show me the code.
2025-10-16
