偶然看到 Google 官方在 bilibili 发的视频 WebAssembly：全新 Web 开发范式，发现 WebAssembly 真好玩，特别提到了 fastText 这个基于 AI 模型的工具，一上头就打算试试把它搬到浏览器会怎样。
先在 npm 搜索了一下，基本都是只支持 Node.js 单一环境的，有一个包 fasttext.wasm 说是支持浏览器环境的，结果在 Next.js 中一试直接裂开，各种报错 😂
兴致上来了就一心想着搬到浏览器上，遂先在原仓库上各种魔改，始终解决不了问题，最后确定应该是要分离浏览器和 Node.js 环境的相关具体实现的，从而能方便的避免各种问题。
这次实践涉及到的关键技术点汇总一下
- WebAssembly
- Git Submodules
- Xmake
- 分环境开发打包 wasm 和库代码 （最大问题）
按照 fastText 官方的流程无法编译，所幸 fasttext.wasm 有个基于 Xmake 的编译，刚安装怎么也编译不了，最后稀里糊涂把 Xmake 的路走通了 😂
能编译之后就是另一个问题，如何分环境编译 wasm 文件，找 emcc 和 Xmake 各种文档研究怎么分环境打包，所幸官方对此早已实现，注入 xmake.lua 的参数也是连蒙带猜可算是注入进去了。
其实不分环境编译 wasm 在 Vite 环境下已经能够正常使用了，在 Next.js 总是会弹出 wasm 的 JS 绑定文件使用 Node.js 的
module包的异常，所以不得不研究分环境编译 wasm 了。
这一路都是靠玄学通关的，如果编译 wasm 的第一步失败的话，我大概就直接弃坑了。最后写了个简单的 benchmark 测试了一下，效果是真不错。
另外还有个 Vite 库打包的问题，由于 wasm 文件的编译会带上一个对应的 JS 绑定文件，这不太可能自己去写，所以需要保留代码的原始形式。Vite 库打包死活要把 wasm 文件变成内联的 base64 格式……也有人反馈了这个问题：
- Add build.assetInlineExclude config
- library mode can't extract static assets
- add an option to not to inline assets in library mode when format is 'es'
看起来这个问题也有些年头了，至今都不支持，也是不懂为啥……最后决定通过骚操作绕过这个问题，将对应的 JS 绑定文件添加到 external 中，再用静态资源复制的 Vite 插件把相关的资源复制过去 😂 一切又正常了。
各种踩坑之后终于搞定了，现在已部署两个环境，欢迎体验：
搞完之后就一个想法，如果要深入 WebAssembly 大概得入个门 Xmake 才行，现在全靠玄学想想都有点搞 😅 最后，基于 fastText 的核心封装搞定了，应该可以方便扩展 fastText 支持的各种模型功能了，有时间逐步加上，未来可期 😄
