发现一个把码表加载到web前端的项目，使用WebAssembly 技术

[jingjingxyk]

https://github.com/LibreService/my_rime

使用WebAssembly 技术 。 编写CPP 代码， 转换为 WebAssembly 代码

预览： https://my-rime.vercel.app/

[yanhuacuo]

这个项目引入了太多第三方工具，非常 dirty 的一个项目。 不好看，也不好用，往浏览器扩展转化的意义几乎为零。

[eagleoflqj]

我确实有把项目改造成vscode扩展和浏览器扩展的计划，思路也是无服务器，纯前端运算。当然UI不可能移植到这两个平台（最多把wasm的librime抽出来复用），也不确定目前所用的技术能否应用到这两个平台。欢迎交流

[yanhuacuo]

我确实有把项目改造成vscode扩展和浏览器扩展的计划，思路也是无服务器，纯前端运算。当然UI不可能移植到这两个平台（最多把wasm的librime抽出来复用），也不确定目前所用的技术能否应用到这两个平台。欢迎交流

啊……这……被原作者看到了……其实并无恶意，只是纯粹对技术选型有别的看法，因为 chrome 扩展来做无后端检索时，纯性能要求是很高的。

[eagleoflqj]

没事没事，我也不是想推广我的项目，就是单纯技术交流嘛。 你应该只想要一个98五笔的chrome扩展，所以把整个librime弄到前端可能确实不是最优解；我是比较追求通用性，任何码表都能用。 前端运算性能我感觉还可以？而且以后会越来越不成问题。后端运算也是需要考虑网络延迟的，而且要自己架服务器，用户多了还要考虑并发，成本是比前端高的。目前My RIME的页面放在vercel上，wasm和码表由npm和jsdelivr提供，做到了0成本。

[yanhuacuo]

没事没事，我也不是想推广我的项目，就是单纯技术交流嘛。 你应该只想要一个98五笔的chrome扩展，所以把整个librime弄到前端可能确实不是最优解；我是比较追求通用性，任何码表都能用。 前端运算性能我感觉还可以？而且以后会越来越不成问题。后端运算也是需要考虑网络延迟的，而且要自己架服务器，用户多了还要考虑并发，成本是比前端高的。目前My RIME的页面放在vercel上，wasm和码表由npm和jsdelivr提供，做到了0成本。

没错，是这样。形码的需求非常有限，一个极轻量的 js 就可以解决所有需求了。librime 本身 web 化需要考虑的点太多了。

[eagleoflqj]

更了一版，拿你的98五笔测了下： 点Micro Plum，Schema URL粘https://github.com/yanhuacuo/rime98wb/blob/main/opt/rime98wb/rime-data/wubi98_dz.schema.yaml ，然后Install、Deploy，可以打出五笔单字

[yanhuacuo]

更了一版，拿你的98五笔测了下： 点Micro Plum，Schema URL粘https://github.com/yanhuacuo/rime98wb/blob/main/opt/rime98wb/rime-data/wubi98_dz.schema.yaml ，然后Install、Deploy，可以打出五笔单字

是从 schema 同位置（路径）加载 dict 的吗?

[eagleoflqj]

是从 schema 同位置（路径）加载 dict 的吗?

对，虽然不是plum包，但是一般都把dict和schema放在一个目录下，也就能顺藤摸瓜找到；lua同理