pursuer

现在前端都直接发布 es module 了吗？感觉 es module 还是灵活性比较差

@Seanfuck service worker 不能跨域

从 LLVM 出现之后，大部分语言中间语言都用 LLVM IR 了，先编译成另一个语言再编译要解析代码两次浪费时间，以前还没有 LLVM ，没有标准的中间表示所以会选 C/C++，这样支持的平台比较多。

最重要的是生态，造轮子大部分都是浪费时间，综合来看现在是 JS/TS(前端 Web 生态唯一选择，强大的动态和调试能力) 和 C++(Linux 和 Windows 等平台的 API 原生支持以及跨平台库支持(libuv))，然后 Android 上需要补充一个 Java ，基本只做 binding 。

本来想看看 Zig 来代替 C++的，毕竟 c++不用协程，写异步以及内存管理真的很麻烦。但转念一想用的不多还是算了

@w568w
c++生态还不错，但包管理就不行，当然这也没办法，毕竟要面对的相当广泛的平台。要是以后 WASM 成为 C++的"JVM"说不定能有新突破？
另外 C 互交互里 ABI 不兼容是个巨大的坑，所以我现在跨语言交互尽可能优选 RPC 了

@RedNax 走 wasm 是会有序列化性能损耗的。而且 wasm 生态还有个 assemblyscrip 更是和 TS 十分接近的写法，移植不是更容易？话说回来这些写惯 TS 的这些开发者能忍得了 Go 的拉胯的类型系统和类型推断能力也是神人了。

把 typescript 里的 sync 调用改成 async 的 issue( https://github.com/microsoft/TypeScript/issues/1857) 挂着没改，整了个 Go 的，给我气笑了。真要把这个作为 TS 后继版本，那些使用了 typescript 的 API/transformer 的 JS/TS 代码怎么办。我需要性能的时候我直接 transpile 忽略类型检查不就行了，真的是没活可以咬打火机。

之前写过一个 WebAssembly 的 JIT 编译运行时
https://github.com/partic2/pwart
但是有点懒得继续跟进新特性了，后面接着加复杂度那我不如拿 TCC 来改个 C 的运行时，可能还简单一点。

21 ，有一些 PDA 设备版本比较早。有的机顶盒设备甚至 4.4 的都有。。对我来说 21 最大问题是 libuv 需要 24 ，所以我 patch 了一个支持到 21 的版本。其他的直接 webview 糊，webview 如果用 X5 的话，能到 Chromium89 ，基本够用，不知道 geckoview 能到哪个版本。反正不管哪个 SDK 版本都觉得原生 API 既碎片化而且太难用了，不怎么想在上面写复杂逻辑。