想到啥就写点啥，但基本都是技术相关的吧: https://sadofriod.github.io/

提供一份试试 https://sadofriod.github.io/about/about.html

@softnero 方便发我一份 JD 么

@nickr 能发份 jd 给我么，谢谢

@golangLover https://www.v2ex.com/t/779814#reply13

@wellsc Modern-Deedy

@Mistwave 加班么，听同学说貌似有些强度啊

直接上后缀树

发了邮件一周无回复就是不合适么

技术与数据中台么🐟

@3dwelcome
确实，我一直在说某个技术现在能解决的问题及其优势的场景。而你更像一个“布道者”，就像当年推广 angular 的大漠穷秋

@3dwelcome
？？？
我不知道你是怎么从强调 dom 调用性能这一点，看出我把 wasm 作为 vdom 框架的附属库这一点的。

其次，我强调 dom 操作性能的同时不也一直在强调 wasm 在 cpu 密集计算的性能？

舍弃 react 的历史包袱？我们早就舍弃了不止一个历史包袱：JAVA SwingGUI 由于标准库带来的不稳定问题；新的 Android 开发框架 Jacket compose ； Jquery 大量交互状态难以维护的问题。所以，舍弃 react 从来都不是问题，问题想是让我们用报告新的解决方案，一定是新的方案能提供更优的性能 /更好的维护性覆盖老方案至少 95%以上的场景，剩下 5%也可以用一些 geeky 的方式解决。

至于你说的 DOM 数量上限的问题，可以见得你对 DOM 到底要解决什么问题毫无了解

@3dwelcome
1 、我先入为主了什么？是我先提出的框架问题么？我始终在说 wasm 对于非 cpu 密集场景的一些性能和使用问题吧？
2 、你甚至不了解为什么客户端开发要引入 dom 的概念。对于这一点建议了解下“保留模式”和“即时模式”的区别。
3 、figma 大画布的解决方案确实很惊艳，但就如我最早的例子中 ps online，这个早期版本只是使用了 js 的产品，在高斯模糊计算，图片像素取色依旧表现不输原生啊。

@3dwelcome
1 、“把 VUE 框架代码换成 wasm 来写，就会拖慢系统运行速度”，虽然但是，你要用一个框架和语言比运行速度么？至少也要用 YEW （使用 rust 构建 web 应用的框架）来对比 vue 吧？或者正面回答一下 “或者说 wasm 解析 arraybuffer 的过程甚至会比 webapi 操作 dom 快？”
2 、我说的任何一个场景有涉及到三大框架的任意之一么？我只是单纯的比较 JS 和 wasm 在 web 开发不同场景的适用性罢了。
3 、对于虚拟 dom 的 diff 算法的性能分析。是否应该权衡下，在我上文提到的上千个状态的管理问题，和与之带来的协同开发问题？当然了，如果要是这样比较的话，我们又回到了问题 1，wasm 真的比 js 在操作 dom 时快么？

@3dwelcome
1 、所以，我始终说的都是 wasm 无法 "直接"(引号表强调) 操作 dom 有什么问题么？
2 、说慢是和直接用 js 操作都没进行比较的。或者说 wasm 解析 arraybuffer 的过程甚至会比 webapi 操作 dom 快？
3 、“导入 /导出函数，都和主程序进行动态地址绑定”，一个客观事实是，就目前生态而言，对 wasm 相关的 debug 工具链仍不完整。另一个主观疑问是，“最合理的模块分离技术”是指的，换个操作系统平台运行的时候，各种 DLL lost 么？
4 、 “如果有人觉得 WASM 运行太慢，那只能说代码接口设计有问题”，从来没有人觉得在 CPU 密集的场景下，wasm 运行慢，只是说在强调交互，并更新交互状态时，wasm 没有直接用 JS 操作快。

最后能否说明：wasm 对这个“大型前端项目”的定义有任何的补充

@3dwelcome 并且，我举出例子，尝试定义了下什么是大型前端项目。目前还是没看懂 wasm 对这个“大型前端项目”的定义有任何的补充

@3dwelcome 如果你说的操作 dom 是编译之后，通过 js 操作 webapi，也算是直接操作 dom 的话那就是吧。。。。

一段 mdn 原文：
Emscripten first feeds the C/C++ into clang+LLVM — a mature open-source C/C++ compiler toolchain, shipped as part of XCode on OSX for example.
Emscripten transforms the compiled result of clang+LLVM into a .wasm binary.
By itself, WebAssembly cannot currently directly access the DOM; it can only call JavaScript, passing in integer and floating point primitive data types. Thus, to access any Web API, WebAssembly needs to call out to JavaScript, which then makes the Web API call. Emscripten therefore creates the HTML and JavaScript glue code needed to achieve this.

其链接： https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts

@3dwelcome
2021 年的今天,wasm 依旧没办法直接操作 dom （请不要说通过调用某个 js 提供的库进行操作），且 wasm 基本是用于解决 CPU 密集的并行任务的（比如音视频解码），我所说的交互逻辑指的是：对 UI 界面有大量的交互操作，产生的状态需要实时展示，状态的数量级在 4 位数左右，上述产生的状态不需要关系存储，频繁的读写操作发生在客户端的内存或缓存中。

综上所述，wasm 目前（ 2021 年）并没有提供对前端强交互场景的强力支持，只是对一些垂直领域，例如：音视频的简单编码，加密文档生成提供了一些支持。你提出 wasm 并不能很好的支持你的论点

且上述 wasm 提供的特性，对转译成 wasm 的程序的原始代码有一定要求：
1 、 并发计算。wasm 目前没有提供 webwork 的调用
2 、 系统 API 支持，例如 linux 的 fork

再讨论 wasm+三方库可操作 dom 的方案。这一方案中，由于 wasm 的运行，目前仍然依赖 JS 胶水脚本，对 wasm 暴露的 event 进行调用。所以，如果在非 CPU 密集场景下，使用 wasm 甚至会带来系统性能的降低。