@otato 所以 react vue 这些没火起来以前的 web 前端薪资水平比后端低很多
原生方案时代很少有人去做优秀的 web 前端工程的性能提升，多数的原生工程管理集中在目录结构、没有涉及到 dom 渲染的性能层次
多数的框架也都是 UI 相关框架、主要性能关注也是在 UI 组件本身、也没有染指提升工程整体性能的层次，或者像 jQuery 这种，也提供了很多便利性而并非性能优化
传统前端不太在意性能，直到虚拟 dom 系出来搅局，原生更加显得被低估，而虚拟 dom 系的这些并没有真正提升 native 本来可以达到的高度，这是件挺可惜的事情——说句不好听的，前端社区里真正懂底层、性能人相对比较少

@otato 我不是 web 前端工程师，也不太了解前端社区特别好的解决方案细节、只是偶尔了解一点。想做一点页面，但是 react 、vue 这些需要更多时间熟悉它们的基础，想直接原生搞，然后原生的框架没有找到我满意的姿势（自己对性能有些强迫症），就搞了 pm.js 这么个，简单归简单，但是工程性在架构分层的不同层里，每一层处理好自己的只能就好，pm.js 是 Page Manager 的意思，如果是我自己用我会理解成 Project Manager，因为在 pm.js 管理页面基础上的工程结构，再加上动态 dom 元素的事件绑定和动态更新，另外找一套漂亮的 UI 框架，基本就足够了（可能还有一些其他细节比如 i18n 国际化之类的不赘述）

代码层面的工程管理本身并不需要太多东西，只是被有的人有的社区搞得有些过于复杂甚至华而不实，学起来头大用起来繁琐，虽然也是一种工程规范，但本来可以搞得简单些，就像独孤九剑，我不想玩花架子 :joy::joy:

@otato pm.js 原理和实现都很简单，不是什么高深的玩意。只是我想做些页面，选用一些 UI 框架时看到的一些工程示例，比如 github 上数万 star 的 bootstrap admin 模板项目，dashboard 切换功能标签时是 url 路由到新页面、每次都全部重新加载，性能损失太亏了。

@otato

“你这个其实就是个路由嘛，或者说加载器，功能感觉够了” —— 定义不一样也不那么重要，但是要实现的功能是类似的，这个方案并不是以 web 为出发点的来做的，而是以 GUI 为出发点捎带着给 web 领域的。浏览器本身是在 GUI 系统之上发展起来的一套复杂姿势，但 GUI 领域比如桌面、游戏引擎，都相对规范得好一些、没有 web 领域这么繁杂松散

“虚拟 DOM 的性能，就是在 js 里对比一下” —— 这个说法不够详细，不知道兄弟你的意思是对比单个 dom 还是整个 dom 树，我没有读过 react 、vue 的源码、不确定它们的实现方案。如果我自己实现虚拟 dom，我不会去实现管理整个 dom 树所有节点，只会去按照初始化后触发修改才去把相应的 dom 元素加到管理列表，每次触发修改也只对比这个元素自己然后更新

“”现在直接大段 innerHTML 确实性能最好，但是再细的粒度呢“ —— 这个理解是不准确的，直接大段只是加载子页面时一次性 load，不是每次有 dom 元素变更都需要 reload 大段

“”要么使用者手动去操作 dom，要么你实现个中间层，可是，这个中间层，不也就会是个虚拟 DOM 么 23333" —— 手动操作 dom 是对的，不需要另外实现个中间层、虚拟 dom 是有些多余的

”事件系统建议就用在页面间传数据或者跟主程序通讯，发布 /订阅模式适合做底层不适合在业务中全面使用。
早期有框架使用“ —— 所以提供了单独 bind dom 元素的只用来更新需要动态变化的 dom 。其他的很多功能比如复杂的 UI 组件，还是交给 UI 框架，pm.js 并不是做全套解决方案，只是提供单页面方案或者工程性的基础

@shunia redux 这种，核心本质就是事件分发数据驱动，但是它搞得太复杂了。所以前端社区学不动，甚至很多非前端的老司机想搞下前端都忽觉门槛奇高，这于工程性不够友好。

虚拟 dom 系的新栈最大的好处是强行提高了门槛，强行约束了工程规范，虽然依旧是屎山，但是不是什么样子的小白都能爬上山了，所以现在这些山上的人们，至少做事能力靠谱了很多，而且在这山上再能制作出很漂亮的前端产品，确实是值得肯定的，因为比用 go 写一些基础业务还是要难度大很多的。

@shunia 我不知道我理解的路由是否正确，如果说的不准确，多多指正。
我上面说的是传统方案的路由（不是 react 、vue 的路由）——传统 web 前端方案主流应该是 window.location 吧，然后是 reload，性能差。说的是传统方案这样性能差，好像没说对标 react 、vue 的路由导致性能差。

如果你理解成对标 react 、vue，那么对标的部分我是指它们的虚拟 dom，因为最终都是操作 native，所以如果 native 实现方案合理，react 、vue 并不会比 native 性能更高。

“go 多好啊” —— 严重同意，所以我也不是折腾 js 后端，只是捎带一点前端思路

@Kasumi20 如果业务层觉得有必要，完全可以自己使用路由。只是使用 pm.js 的方案不需要使用路由，并且通常没有必要，这在 GUI/H5 GAME 领域很常见。
需求仍然可以按照多个 html 进行工程管理。传统路由方案是为了切换页面，pm.js 的一样能达到而且简单方便、可以得到最佳性能保障，而传统 native 路由切换页面的方案正是常规项目性能的最大瓶颈所在。

看来大家都去搞 react 、vue 了，没人关心 native 了 😂

周一搬砖日，up up ~

@lesismal 参考自：

https://github.com/opentracing/basictracer-go/blob/8e39e894ba59569ffb0b13167ebbe64b0b142e94/examples/dapperish.go

@kevinwan @DoctorCat ARPC 也实现了个编码中间件的扩展示例，把 opentracing 的支持加上了，例子：

https://github.com/lesismal/arpc/tree/master/examples/middleware/coder/tracing

@lesismal 描述清楚了就好回答了，文字沟通不方便，如果是面对面沟通可能早就讲清楚了 😁😁

"不过我一般考虑到资源隔离，以及协程的资源占用不高，3 都是开个协程来处理"
—— 嗯嗯，这种用于 RPC 的场景，请求和依赖的下游模块做好限流之类的，系统就不会爆

ARPC 主要是考虑通用场景比如包括游戏领域的业务，请求方的频率可能会非常高，热点时段协程数量可能会爆，所以留给了业务层根据实际场景做更灵活的同步异步定制

周末愉快 ^_^

@lesismal 或者分成"异步请求处理" 和 "异步回包"来描述更清楚些，但是这个处理流程比较简单，就几行代码，就不做太强的概念辨识度相关的解释了 😂

v 站玩的少，markdown 和代码段的格式不知道怎么搞，编辑好的缩进发出来都给我整没了 😂😂

@so1n

一次完整的调用过程指 client 端 Call 调用的返回，其中大致包括了几个主要流程：
1. client 发送请求数据
2. server 接收到请求数据
3. server 处理请求
4. server 发送响应数据
5. client 收到请求数据，调用结束

因为传统 RPC server 端的流程，以 go 的 "net/rpc" 为例，对于每个连接的流程大概是
go func() {
for {
2. server 接收到请求数据
go func() {
3. server 处理请求 // 这里是回调业务层注册进来的 handler
4. server 发送响应数据 // 业务层处理完之后，框架层把 3 中的 handler 返回值打包成响应数据，发送给 client
}()
}
}()

3 中 handler 是默认 go 一个新的协程进行处理，这种在连接数非常多、并发请求量大的时候协程数量多、各项资源消耗比较浪费
但是业务层处理 3 的流程，又不能自主选择是否每次 go 一个新的协程


我在主帖中说的是："异步响应"和"异步回包"。ARPC 提供了更灵活的机制，大概如下：
处理请求的 handler = 3+4 （ server 处理请求+server 发送响应数据）
go func() {
for {
2. server 接收到请求数据
if 注册时设置为异步处理 {
// 此处是指 "异步响应"
go handler() // 3+4
} else {
handler() // 3+4
}
}
}()
而 handler 的实现中也可以自主选择同步或者异步回包，比如：
func handler(ctx *arpc.Context) {
// do something
if condition {
go ctx.Write(...) // 此处指"异步回包"
或者
// 此处是指 "异步响应"
go func() {
// do something
go ctx.Write(...) // 此处是指 "异步回包"
}
} else {
// do something
ctx.Write(...)
}
}

晚上状态有点懵逼，不知道有没有写错的地方，先大概看下吧 😁😁

@so1n 兄弟，先读点好书，或者搜知识点，阻塞、非阻塞、同步、异步，还有其他的很多基础知识补上再交流，否则问出来的问题容易把我问死，不是不想回答，但基础知识的科普，我没那么多时间啊，而且零碎的知识不如你自己系统性学习的效果好 😂😂
或者可以直接来读源码，标准库的源码很赞、很值得学习，或者比如你想问的 ARPC 的问题，ARPC 源码也相对简单，你按照 server 的启动流程看进去，很快就能找到答案了

@robot9 这两点对于非 rpc 的领域好像也同样重要，所以，反倒不是 rpc 的重点了，而是通用场景的重点 😅😅

@so1n
单个连接上的消息是顺序读取的，你说的这种是 one-by-one 的方式进行处理，处理完一个再处理下一个，http 是这样子的，一个处理完之前下一个要排队等待，如果一个处理慢了会导致其他消息也被阻塞、这个问题通常叫线头阻塞
io 多路复用是指 select 、poll 、epoll 、iocp 、kqueue 等，通过事件机制、异步 io 对多个文件描述符（网络连接也是文件描述符的一种）进行高效的异步 io 操作
兄弟概念有点迷茫，可以多看些好书比如 CSAPP 、APUE 、UNP 之类的，啃下来消化消化应该会有很大帮助😁😁

@kevinwan 嗯嗯了解😆😁