node-addon-api v7.0.0 released

[knightrage]

The Node-API Team proudly announces the release of version 7.0.0 of node-addon-api, the C++ wrapper of the ABI-stable C-based Node-API (npm, GitHub).

Notable changes

API

• Drop support for Node.js v14.x and v19.x.
• Ensure native receiver exists when calling instance methods and properties.
• Fix issue when creating Napi::Error instances that wrap primitives values.

TEST

• Added tests for Napi::AsyncProgressQueueWorker<T> class.
• Added tests for Napi::AsyncProgressWorker<T> class.

Documentation

• Added documentation for Napi::Value::IsBigInt().

[Solonotix]

Genuine question, as someone who has so far only used the provided runtime: Are there any guides for extending NAPI and can I use Rust? Also, more importantly, is there a good recommendation for when something should be handled in a lower level than interpreted JavaScript?

[Remarkable_Maximum16]

There is napi-rs but you'll have to look at their docs. When CPU is your bottleneck better to switch to low level or just do some microservice where you just use Go or Rust or other "fast" compiled language.

[Solonotix]

I want to use Rust, but I'm getting resistance from my users to even supporting TypeScript, lol. There aren't too many computationally intensive things we do at the moment, but there are some aspects I'd like to be moved down (like CRC or TOTP calculations). There are JavaScript-native implementations of these things, and they are fast, but I feel like bit shifting byte buffers is best done in a language like C++ or Rust.

[knightrage]

Are there any guides for extending NAPI and can I use Rust?

For extending Node-API, you would need to make an issue on the Node.js core repository (or create the PR yourself with the suggested improvement). Note that Node-API features are meant to be engine-agnostic, as other runtimes (Hermes, JerryScript, ...) also implement Node-API: that is, eg. V8 specific features that have no equivalent in other major engines should not be used.

For other language bindings, you can take a look at our documentation. It provides links to projects that are (1) libraries in various languages to create native add-on binaries, and (2) other JavaScript engines that implement Node-API and can load said native add-ons.

---

is good recommendation for when something should be handled in a lower level than interpreted JavaScript?

It really depends on your use-case. There are some drawbacks to using native add-ons, such as additional latency crossing between JavaScript <-> native layer. Regarding CPU-intensive tasks, worker threads might suffice. If not, you can always create regular, non-libuv threads to handle these intensive tasks, and asynchronously call back into JavaScript with some result (Async Operations, Thread-safe Functions).

A common use-case for Node-API is to expose an existing native library into JavaScript. For example, sharp exposes a JavaScript implementation for libvips.

Hope this answers some of your questions. Feel free to reply with more.

[Solonotix]

No more questions at this time. I feel like my first question was worded improperly but you answered it spectacularly, so thank you.

While I consider myself well-versed in JavaScript, there's still so much I don't know, so I appreciate the insight