在 webworker 中运行 react virtual dom
在一次内部分享会中，我表达了可以把 react 的 virtual dom 那一套全部放到 webworker 中，这样就可以避免在主线程进行计算量很大的 diff 操作，一方面节省主线程的计算消耗提升性能，另一方面也不需要再去构建 react 的 scheduler 做那么复杂的协程工程。大致意思就是，在主线程只做 DOM 操作，而 DOM 的操作，全部由 worker 线程发送消息到主线程完成。在 worker 中计算得到 patches，发送到主线程，由主线程的程序完成 patch，也就是在主线程中，只存在 DOM 操作，不存在计算过程。其中比较重要的一点，是事件响应问题。当用户在界面上做了一次点击后，需要发送一个 event 消息到 worker 中，然后由 worker 中构建的一套事件处理系统完成事件响应和接下来的 diff，将最终的 patch 发送回主线程。
之后，在同事的推荐和自己的寻找下，找到两个项目：
- web-perf/react-worker-dom: Experiments to see the advantages of using Web Workers to Render React Virtual DOM (github.com)
- dai-shi/react-worker-components: React Worker Components simplify using Web Workers (github.com)
- ampproject/worker-dom: The same DOM API and Frameworks you know, but in a Web Worker. (github.com)
前一个项目比较老了，感觉正好符合我的想法。后一个项目受最近 server components 的启发才出来，也是非常有意思。
在深入想想。既然我们可以把计算过程放到 worker 中，也可以放到 wasm 中去。我们可以用 rust 重写 virtual dom 的实现，并像上面 worker 中的处理方式，放到 wasm 中，通过接口传递数据，完成计算后再回调方法，最终实现这个效果。
而以上这套思路，还有点像小程序的思路，但最终还是不大相同。
有些东西坚持很久，东西本身可能无所谓，但坚持这件事很有意义
今天QQ音乐推荐了我的个人播客节目《Robust》。
虽然是由于腾讯内的同事在帮忙推，但是也是一件很开心的事情。做《Robust》是圆自己一个电台梦，可以有一方自己的王国，想说什么就说什么，其他人只能听。但是我是一个很淡然的人，我见到一些朋友做播客喜欢走极端路线，比如一些同性恋节目、离婚、一个事情是不是犯法等等，我觉得都太功利目的了，都想通过内容主题来吸引听众。我做的内容，完完全全不是要吸引听众，就跟我写博客一样，更多是一种表达的方式，把自己的知识或感悟积累成为可以用语言表达的有框架的知识体系。所以，有网友说我一个人讲太无聊了，要是两个人讲就轻松一些。因为我讲的东西偏技术，有的甚至讲技术细节，所以听起来肯定很枯燥，但是并不影响听众打发时间。枯燥是枯燥，但是我还是希望尽可能沉淀东西进去，很久以后回来听，也不会太过时。
我的计划是最少要做100期，我现在做了3年，做了25期，也就是说还要9年才能做满100期，那时我正好40岁，还真是有仪式感的一段岁月。
我写博客也写了马上10年，博客的内容有的时候也是很糙，但是，就像我标题说的，其实，内容本身可能无所谓，因为现在写的东西，过一两年就过时了，甚至是错误的，内容即使在当下很超前很硬，但也有过时的一天。而写博客这件事本身，却伴随了我整整10年，对我来说，是一件了不起的事情。一件事如果能坚持10年，就是了不起，又有谁太在意它的内容本身呢？
-
给你点个赞 (｡>∀<｡)
-
加油#1031 1188 2021-04-20 09:34
-
谢谢支持！#1032 回复给#1031 否子戈 2021-04-20 10:49
-
谢谢哦#1033 回复给#1030 否子戈 2021-04-20 10:49
腾讯3年可以申请更换设备，虽然大家都说Mac好，但是我还是申请更换了一台windows，因为已经有一台iMac，所以打算留一台windows以备不时之需。以前用windows最大的问题是开发环境不好搭，在morningstar的时候，自己装了个vmware跑Ubuntu，但是性能很不爽。而如今windows直接上WSL，在系统底层跑linux子系统，性能和直接用windows没差，简直飞起。而且由于linux子系统和windows主系统共享文件系统和网络，在linux里面跑的服务，直接可以在windows上访问，减少了各种配置工作。而且说实话，windows上的软件，虽然界面确实没有mac好看，但是从功能完整性讲，绝对比mac好很多，在加上winget，总之，现在我已经有点享受windows上开发的乐趣了。
-
WSL简直太棒了, 有时候在win上装node的package必须要linux环境,现在直接用vscode一键wsl搞定, 配合自家的vscode用起来简直不要太爽了,完全就是为开发者准备的.#1029 maoa mao 2021-04-17 02:29
JS 糟粕之全局变量和引用
JS的全局变量是排第一的糟粕。比如：
const a = 1
function get() {
retun a
}
函数内可以直接使用一个函数外的变量，而且可以层层往上引用。如果这个变量还是对象的话，还可以修改对象。例如：
const o = { count: 0 }
function set(count) {
o.count = count
}
这种写法，由于我们写JS写的久了，觉得天经地义，而且还是个与其他语言不同的特性（优点），殊不知，这种东西，害人害己。
全局变量的设计，会使得内存引用及其复杂，且导致内存溢出。虽然js是自动回收垃圾，但是实际上很多情况下开发者需要自己手动释放，而且由于全局变量这个特性，根本释放不了。
如果要改进这门语言，我觉得可以学习rust，去掉全局变量这种东西。
const a = 1
function get(&a) {
return a
}
const b = get(a) // b === a === 1
let b = a // a === null, b === 1
// ---------------
mut o = { count: 1 }
function set(mut &o, int count) {
o.count = count
}
function clone(o) {
return o
}
const n = clone(o)
虽然这使得这门语言麻烦很多，理解起来更复杂，但是可以避免很多问题。
react jsx编译后中文乱码问题
在一次开发中，我发现，构建出来的react应用出现中文乱码现象。于是我很自觉的，在html头部添加 <meta charset="utf-8" />，然后问题解决了。但是作为资深搬砖人，必须得搞清楚，为啥会乱码。
于是我打开了构建后的文件，发现里面中文被转码为unicode了。
这就尴尬了，但是经过观察之后，我又发现，只有createElement的部分被转码，其他部分的中文还是中文。
于是我想，肯定是编译工具在搞鬼，我得找到是哪个地方的问题，把这个转译给关闭。要么是webpack，要么是babel jsx。
于是还是用bing进行中文搜索，没有一个结果指向这个问题。再用英文搜，也没有找到相关解决办法。最后只能请出google大神，找到这个栈漏答案，找到了相关资料。兜兜转转一大圈，发现这是react自己埋的坑，跟编译工具无关（也有关），总之就是关不掉，只能这样，放弃挣扎。
-
之前也有遇到这情况, 想改个项目里的标题, 搜中文搜不到, 结果发现是unicode#1015 ID_1188 2021-03-02 16:29
我时常有一些执念，以至于有的时候不合群。我遇到无法修改react传入的props的情况，我大概知道在react源码里面干了些坏事，但是我想确认这一点，于是我在bing搜索相关问题。大部分的答案，无非是和react单向数据流相关的一些废话，谁不知道这些原则，我现在就是想打破这些原则，而我打破不了，你只告诉我原则就是根源，我呸！然后我找了很久，在漏栈上找到一个答案 https://stackoverflow.com/questions/26089532/why-cant-i-update-props-in-react-js 这个答案获得了20个反对票，最主要的原因在于，他指出只有通过修改react核心代码才能实现，于是被一路狂喷。我……我被气炸了！这个回答直指问题本质，就是react中使用Object.freeze(element.props)导致我们修改props会报错。我tm不懂，为啥真正指出问题所在的答案被驳20次，而千篇一律的讲废话的答案得到大量赞同。真是只要主义，不要实际！
-
因为 react 社区动辄喜欢谈设计理念，原则之类的，不考虑实际使用者的场景
-
有的时候爱，有的时候恨，选择太少了#1007 回复给#1006 否子戈 2021-02-05 19:52
-
没，有时候吾辈反而觉得前端选择太多了，各种乱七八糟的工具链和层出不穷的类似的轮子，上层应用的基础变化太快了。。。
-
有趣的例子.#1009 ID_1188 2021-02-09 15:40
