✨ Make `react-native-nitro-buffer` the default buffer

[XChikuX]

What feature or enhancement are you suggesting?

See benchmarks of https://github.com/iwater/react-native-nitro-buffer

Beats @craftzdog/react-native-buffer by a large amount

What Platforms whould this feature/enhancement affect?

Both

Alternatives/Workarounds

N/A

Additional information

• I agree to follow this project's Code of Conduct
• I searched for similar feature requests in this repository and found none.

[boorad]

Thanks for the suggestion — I dug into what this would actually take. Good news: it's a small, low-risk swap. The nuance is whether the benchmark win actually translates to RNQC's crypto throughput.

The swap is nearly mechanical

react-native-nitro-buffer is a full Node Buffer polyfill — class Buffer extends Uint8Array with from / alloc / concat / byteLength / isBuffer / toString(enc, start, end), plus copyBytesFrom and poolSize. Every static/instance method RNQC relies on (from, isBuffer, alloc, concat, byteLength, writeUInt) is present, so it's close to drop-in:

• 1 line in package.json — replace @craftzdog/react-native-buffer with react-native-nitro-buffer.
• ~30 source files — a mechanical import-specifier rename.
• src/index.ts — we can actually delete the @ts-expect-error there, since it exists specifically because craftzdog's Buffer is missing copyBytesFrom/poolSize — both of which nitro-buffer provides.

Both buffers extend Uint8Array, so the existing isBuffer → ArrayBuffer.isView fallthrough and any cross-library hand-offs stay safe. And no new native toolchain is pulled in — Nitro is already a dependency.

Two things to check before committing to it

1. Does the perf win actually land in RNQC's crypto path?

RNQC already routes the hot encodings — hex, base64, base64url, utf8, latin1, ascii, utf16le — through its own native C++ (utils.stringToBuffer / bufferToString), not through the JS Buffer. The JS Buffer object's from/toString only handle fallback encodings and general plumbing, none of which is on the crypto hot path.

The benchmark in the issue compares nitro-buffer vs craftzdog in isolation. But RNQC already bypasses that layer for the throughput-critical work, so the real-world delta on actual crypto operations is likely much smaller than the screenshot suggests. It needs to be measured against RNQC's own benchmark suite, not the standalone buffer benchmark.

2. react-native-nitro-buffer is v0.0.14.

Pre-1.0, on a cryptography library. The mitigating factor is #1 — the immature code would sit on a narrow, non-hot surface — but it's a real consideration for a lib where encoding correctness matters (hex/base64/utf16le round-trips against test vectors).

Ask

Would you be up for taking a swing at the benchmark yourself? The most valuable data point here is nitro-buffer swapped into RNQC and run through RNQC's own benchmark tab in the example app (not the standalone buffer benchmark) — that's what tells us whether the win survives once RNQC's native encoding fast-paths are in the picture. If it shows a measurable improvement on real crypto ops, that makes the case, and the swap itself is trivial from there.

[XChikuX]

I've already done a swap and have been using nitro buffer for quite sometime.

Haven't run a benchmark yet though.

Their benchmark was also tested vs craftzdog buffer v2.

Not v3, which has significant gains over V2.

Let's keep this open for when I have some extra time to run the benchmark.

If the gains aren't significant, we can stay as is.

[XChikuX]

For those of you who want to take advantage of nitro-buffer at this very instant you can just install the package with

bun add react-native-nitro-buffer

Then do:

module.exports = {
  presets: ['module:metro-react-native-babel-preset'],
  plugins: [
+   [
+     'module-resolver',
+     {
+       alias: {
+         'crypto': 'react-native-quick-crypto',
+         'stream': 'readable-stream',
+         'buffer': 'react-native-nitro-buffer',
+       },
+     },
+   ],
    ...
  ],
};