- WASM is platform independent, so it can easily be precompiled. Which means just the .wasm module needs to be distributed (e.g. inside a npm package). However WASM modules only have access to things that were already available to JS before (no random C/C++ libraries can be included which e.g. call into the OS, no multithreading, etc.). And the toolchain might be at the moment not yet the easiest to set up.
- Node native extensions have quite good tooling support. Write a binding.gyp and the C++ files and everything works pretty smooth. The native code can also do everything that native code is allowed to do on the platform. However node native extensions are platform specific, which means either precompile them for all target plattforms (and each node release) or deliver C/C++ sources which are always compiled on the deployment plattform at npm install time. They also can't be shared between browser and node plattform.
All in all I think they have slightly different usecases:
- Node native extensions for accessing operating system APIs and other libraries which are not already exposed through nodes JS APIs.
- WASM for making existing C/C++ code including full applications (like games) runnable in the browser
- WASM for making modules which speed up pure algorithms (like audio processing) and which can be used on both platforms.
- WASM is platform independent, so it can easily be precompiled. Which means just the .wasm module needs to be distributed (e.g. inside a npm package). However WASM modules only have access to things that were already available to JS before (no random C/C++ libraries can be included which e.g. call into the OS, no multithreading, etc.). And the toolchain might be at the moment not yet the easiest to set up.
- Node native extensions have quite good tooling support. Write a binding.gyp and the C++ files and everything works pretty smooth. The native code can also do everything that native code is allowed to do on the platform. However node native extensions are platform specific, which means either precompile them for all target plattforms (and each node release) or deliver C/C++ sources which are always compiled on the deployment plattform at npm install time. They also can't be shared between browser and node plattform.
All in all I think they have slightly different usecases:
- Node native extensions for accessing operating system APIs and other libraries which are not already exposed through nodes JS APIs.
- WASM for making existing C/C++ code including full applications (like games) runnable in the browser
- WASM for making modules which speed up pure algorithms (like audio processing) and which can be used on both platforms.