新思路：基于 web worker 的双线程前端框架
yisar opened this issue · 15 comments
这里介绍一下 voe 的新思路
js 是单线程的，大量的计算会阻断 UI，为了解决这个痛点，react 发明了时间切片，而我在 fre 中更是将异步渲染作为默认渲染模式，但是时间切片本质上是利用了宏任务队列，搞了个假的多线程
但是浏览器是自带另一个线程的，即 web worker，它特别适合做一些计算工作，而在前端框架中，diff 的遍历恰好是纯 js 计算
我们的主要思路是，在 web worker 中进行 vdom diff，然后将 diff 结果（一个非常小的对象）发送给主线程，主线程拿到它，先操作 dom，然后将事件（一个简化后的事件对象）交还给 worker
很难说它是否可以提升性能，事实上，我从来不在意性能
但是它却有另一个场景：小程序
小程序的核心需求是，屏蔽 web 能力，就是绝对严格的让你只能通过数据驱动 UI
微信小程序等应该是在 native 端造了一个沙箱，用来隔绝浏览器 dom 环境
但是其实 web worker 更适合做这件事，它恰好是没有 dom 的，更纯粹
我们用主奴关系形容这种绝对掌控与绝对服从， web worker 为 master，UI 主线程为 slave
所以现在来说，我们核心工作变成了：
- master 层，写一个纯计算的，结果足够小的，vdom diff 算法
- slave 层，写一个足够简单的事件系统
与此同时，关于 API，可能大概我会刻意倾向 vue3，因为大家比较熟悉，我也顺便学习一下源码
再来一个新思路，
既然 web worker 都用上了，建议尝试用 web assembly 写 worker （不知道可不可行），
可行的的话，速度岂不是更快
既然 web worker 都用上了，建议尝试用 web assembly 写 worker （不知道可不可行）
很明显不可行，写过 wasm 的都知道，所谓的 wasm 是 go 等后端语言模拟全局对象，是 go 默认提供的包，这些包本身就没有足够的 API
另外，使用双线程的目的不是为了性能，而是为了绝对控制，用户没有任何 web 能力
这是一种绝对控制与绝对服从的主奴sm关系
考虑用 ts 编写这个库吗
有个疑问、如果不是为了性能、这么做是要解决什么问题呢？还是说只是纯粹的想要表达一种思路？
@132yse
感谢回复。我可能没有表达清楚我的疑惑、隔绝 web、屏蔽 DOM 是这个框架给出的解决方案、那么什么场景下需要这么做？对开发者有什么益处？我首先能想到的就是性能、其次就是展示一种思路。
@zipeijun 主要还是小程序这种第三方平台，不能让用户（开发者）有任何权限，不然微信会被玩坏的
性能提升是 web worker 的好处，其实微信他们没有用 web worker，他们用 v8 或 native，性能反而更差
但是同样的目的都是屏蔽 dom，让用户什么都用不了，只能用框架提供的 API
@132yse
哦、我懂你意思了。
本质还是展示小程序的一种思路、我刚开始有疑惑是因为 Voe 是跑在浏览器的、所以我很奇怪这么做有什么用、现在懂你意思了。
其实我是再想多线程相关的性能优化才关注带 Voe 的、我本来的想法是能不能 fork Vue、然后把核心移植到 web worker 里面去的同时保持兼容。
@zipeijun 性能提升不需要做到框架级别的
你业务中有什么需要性能的，自己去worker里计算即可，仅仅是为了性能的话，没必要把整个框架 runtime 放到沙箱里
@132yse
不是碰上的具体业务、只是在写 Python 多线程的时候灵光乍现。
考虑到不同应用、不同组件之间的作用域隔离，web worker在微前端领域可以发挥一定的作用
@132yse
不是碰上的具体业务、只是在写 Python 多线程的时候灵光乍现。
我跟你有同样的想法。最近在思考如何结合offscreencanvas, webworker, rust(wasm)以及vue来提升electron app的性能。
offscreencanvas, webworker, rust(wasm)
offscreencanvas 是 OK 的，但 wasm 还是算了
worker dom