The latest articles on DEV Community by FUJI Goro (@gfx). https://dev.to/gfx https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F41349%2F104c88b4-cfbb-4e0e-ab30-53f1c12e904a.png https://dev.to/gfx en FUJI Goro Fri, 17 Nov 2017 05:36:28 +0000 https://dev.to/gfx/using-webassembly-for-a-nodejs-native-addon-dpf https://dev.to/gfx/using-webassembly-for-a-nodejs-native-addon-dpf <p>Recently I have released an npm <a href="https://www.npmjs.com/package/@gfx/zopfli">@gfx/zopfli</a>, which is a JavaScript binding to <a href="https://github.com/google/zopfli">google/zopfli</a>, as a drop-in replacement to <a href="https://www.npmjs.com/package/node-zopfli">node-zopfli</a>.</p> <p>I have a story for this package: it is built with Emscripten into WebAssembly.</p> <p><a href="https://github.com/gfx/universal-zopfli-js">https://github.com/gfx/universal-zopfli-js</a></p> <p>WebAssembly is a portable executable format for the web browsers, but it is not only for the web but usable for nodejs native addons. That is, the package includes pre-built executable binary in wasm. No compiler is required to install it. No node-pre-gyp magic is required (in fact node-zopfli has problems with node-pre-gyp <a href="https://github.com/pierreinglebert/node-zopfli/issues/87">pierreinglebert/node-zopfli#87</a>). Even Windows users can use it just by <code>npm install @gfx/zofpli</code> (or <code>yarnpkg add @gfx/zopfli</code>).</p> <p>You might be worried about wasm performance, but I think it is already production-ready, although it is slower than native code.</p> <p>Here is a benchmark result in the repo on NodejS 8.9.1 (see <a href="https://github.com/gfx/universal-zopfli-js/blob/master/benchmark/random-bytes.js">benchmark/random-bytes.js</a> for the code):</p> <blockquote> <h4> payload size: 1 </h4> <p>universal-zopfli x 106 ops/sec ±0.79% (80 runs sampled)<br> node-zopfli x 201 ops/sec ±1.99% (82 runs sampled)</p> <h4> payload size: 1024 </h4> <p>universal-zopfli x 1.37 ops/sec ±12.99% (11 runs sampled)<br> node-zopfli x 4.62 ops/sec ±3.34% (27 runs sampled)</p> <h4> payload size: 1038336 </h4> <p>universal-zopfli x 0.26 ops/sec ±6.91% (6 runs sampled)<br> node-zopfli x 0.39 ops/sec ±1.35% (6 runs sampled)</p> </blockquote> <p>The speed (ops/sec) of universal-zopfli (i.e. in wasm) is about 30% - 70% of node-zopfli (i.e. in native code). It is good enough for production if you use <code>@gfx/zopfli</code> as a Zlib alternative in <a href="https://github.com/webpack-contrib/compression-webpack-plugin">compression-webpack-plugin</a>. And fortunately, the current state of WebAssembly implementation in NodeJS/V8 is just an MVP! It should be getting better in performance.</p> <p>Development of nodejs native addon with Emscripten is difficult for now, but I believe most of NodeJS native addons which do not use systemcalls, including nodejs standard libraries such as zlib, can be replaced with wasm because of its portability.</p> javascript webassembly node zopfli