3 ms·
This is definitely a problem today, but NAN (https://github.com/nodejs/nan https://github.com/nodejs/nan) which is now the recommended way to build native modul
by aravindet 11y ago
This is definitely a problem today, but NAN (https://github.com/nodejs/nan https://github.com/nodejs/nan) which is now the recommended way to build native modules, offers a way out. That project provides a stable API to insulate module developers from changes between v8 versions.
Sometime down the line, a NAN-spidermonkey or NAN-chakra project might become feasible.
- lmeyerov 11y agoSort of -- in practice, we found ourselves instead playing catchup to NAN (many changes across Node 10, 12, 4, etc.). It insulates from minor changes, and increasingly, part of that has been Node waiting longer and longer between v8 changes.
- ndesaulniers 11y ago> which is now the recommended way to build native modules, offers a way out On paper. In reality, HELL NO. I maintain node native addons, and the thing is, NAN is great, but they simply cannot foresee what will break next in v8. Once something breaks, they provide a node-version-independent feature-shim, but every time there's a new version of Node, I DREAD the work I'm going to have to do to maintain my add ons. It's simply less work to cross compile C++ to JS w/ Emscripten or write it in JS (or higher level language and compile to JS) in the first place.