恕我直言 什么性能什么卡顿，不是平台的问题。

以前纯 js 都没整明白，现在准备同时整明白 js 和 rust ，省省吧。
人家不卡就是有魔法优化，有点出息行不。

还有觉得用系统 WebView 就是最好的，我怀疑你没用过 XP 。

现在没问题不代表以后没问题，操作系统是会终止支持的好不，
你依赖系统的组件, 人家系统不更新, 乱更新, 到时候你咋办,
有些公司新换一个 CEO ，IE 永不为奴;
有些人的系统，啪，360 加持，走独立自主创新道路

打铁还须自身硬，不要幻想有一个什么名词，只要我 stick to 这玩意，一切就都自动摆平了。

自带所有依赖或者静态编译是非常有道理的，是对最终用户负责的一种处理方式。

现在还只是简单的个人项目，放几个网页出来，讲真用啥都行。
要是真正的商业软件或者什么，分分钟都是客户投诉，都是退款请求。

@abcbuzhiming 没啥魔法，代码都是公开的，人家治理得好而已；
一般应用也用不着那么大的盘子，只需要架构上不出错误就可以了，别阻塞，别来回阻塞

vscode 也是 electron, 没人觉得卡
实际上 electron 卡并不是因为性能不足，而是因为阻塞，主进程和渲染进程之间互相踩脚

说到底开发桌面应用是有门槛的，以目前 js 程序员的平均水平，做桌面应用非常勉强。

怎么管理 IPC ，怎么在多进程间同步状态，怎么管理本地存储，怎么处理激活态 /折叠态的转化，怎么给异步任务依赖排序，怎么不让以上所有操作相互阻塞

你突然抓一个前端来做这些事，能搞得好就怪了

庞氏赋能

服务器啥配置我听听

求老哥传我永生秘籍

厉害了，楼主高中刚毕业，起点就这么高

@codehz 类装饰器还是可以拿到 prototype ， 你说的没法直接拿到 prototype 仅限于其它类型的装饰器，换句话说只是不再允许胡乱魔改 prototype ，这个没什么的。因为可以使用闭包或者时序机制把其他装饰器的信息收集到类装饰器一起做修改。

在这个帖子语境底下 Decorator 主要是用来承载一些 metadata, 这是 Decorator 或者说 Annotation 最基本的用法。
如果连这种用法都不支持，那它就不叫 Decorator 了，TC39 也变成一个失能委员会，分分钟被几大巨头另立中央。

“不应该在严肃项目里用现有的装饰器”这个我没见过，如果这样那它还搞这些麻烦事干啥啊，直接拒了提案不就得了。

@codehz 没那回事，es 装饰器是在 ts 装饰器基础上设计改进的，只是输入输出变了，本质功能是一脉相承的，到时候改一下装饰器实现就可以了。
装饰器这东西又不是 ts 新发明的，它是个啥东西别的语言早就定义好了，es 只需要确定细节

你这就像尤雨溪说 class 的定义不稳定所以不提供 class 写法一样，怎么不稳定了，class 又不是新发明的，它是个啥东西别的语言早就定义好了，八九不离十，最后是啥样根据情况微调一下实现就是了

楼主加油，大方向对了，具体实现上还是差点。和你另一个 oidc 项目一样，大方向对了，实现上差点。

目前 TS+node.js 生态里面确实缺少一个 fastapi 类似物，并且写一个 fastapi 类似物是可能的，我手上就有，但不开源。
现在开源的没一个能打的，那些个接口没法说是生成，全部是手动描述，和代码是割裂的，等同于注释文档，需要单独维护。你这个现在有一点点生成的意思了。

给你几点建议
首先，类型信息是以 Dto 为单位组织的，你用的 zod 库就是这个角色，它的完全体应当是一个类

第二个，Decorator 是最基本的，没有 Decorator 你的类型元信息就没有地方承载，势必会对代码组织形式产生严重的侵入，你看下你现在的代码，一切需要围绕 zod 展开，zod 就是你的爸爸，而且 zod 自己还到处侵入代码组织形式，这就是没有 Decorator 给代码带来的侵入

第三个，不要在 TypeScript 的推导上陷得太深，真实场景下总有它推导不了的情况，要随时允许程序员介入，帮助程序员，而不是教会程序员，做程序员的辅助，而不是程序员的爸爸


我觉得你着实应该好好看看面向对象，咋说，咱不耻下问吧，写几个 fastapi 的 demo ，在语言之间多看看，横向比较，不要把自己局限在 js/ts 生态里面