在我的Wasm的实践来说,Wasm对于前端开发来说是解放了一些特殊能力,使得一些边缘计算成为了可能。而对后端来说,Wasm主要是解决了后端开发C++库的一些心智负担。可别小看这两点,在实际应用中都是十分有用的。
首先说说为什么说解放了前端的特殊能力,大家其实也知道Web前端的算法能力和数据处理能力在对于C++是比较薄弱的,那么很多时候C++实现的算法对于Web前端来说是比较困难在浏览器中实现的的,但是Wasm打开了这扇门。使得很多C++实现的算法很方便的移植到了浏览器中,使得JS只需要调用调用方法就可能实现以前JS很难实现的功能,比如我前段时间做的扣脸功能。
那么对于后端来说,如果要使用一个C++库则需要安装这个C++库的依赖到线上环境,其次再使用node-gyp来构建的库,这样就很可能C++库版本依赖发生变化导致的各种各样的问题,无疑是加大了后端开发者的心智负担,而如果使用Wasm则只需要一次构建,不再需要安装C++依赖库。其实不管是nan还是napi或多或少都会因为V8代码的结构调整收到影响或导致不可用,可以说有可能你node10能使用的C++扩展到node12居然就不可用了。那么无疑Wasm是最佳解决方案,可以使nodejs后端开发不再关注于V8或C++库的一些变化,而更关注于JS相关的东西,极大的减少了nodejs后端开发的心智负担。尤其是团队中,你会发现同时维护两个语言是相对痛苦的。所以在使用Wasm来替代C++扩展的回报比是非常强的。所以在很多项目上,我都将C++扩展移植到了Wasm,包括我自己近期的公开的项目数字水印也一并移植到了Wasm。
所以即使WebAssembly抛开性能不讲,我也是极度推崇WebAssembly这门技术的。