Package to replace
safe-stable-stringify
Suggested replacement(s)
object-identity
From my benchmarks, safe-stable-stringify is already the fastest alternative from others in this space. So only one suggestion for now.
Manifest type
preferred (lighter or more modern alternative package)
Rationale
The current object-hash replacement guidance correctly points users toward ohash as the direct successor when they want an end-to-end hashing library.
However, the Web Crypto example is slightly different. It recommends using the native SubtleCrypto.digest API (good) and pairing it with a stable serializer, currently safe-stable-stringify.
For that narrower case, I think object-identity is worth considering once it clears the project's 10k weekly downloads soft threshold.
The reason I'm proposing this is that, for this specific Web Crypto use case, object-identity appears to be a smaller and faster fit based on the comparisons I have run.
| package |
min + gzip |
object-identity |
~538 B |
safe-stable-stringify |
~2.47 KB |
That makes object-identity roughly 4.5× smaller for this use case.
| case |
object-identity |
safe-stable-stringify |
relative |
| simple |
~932,332 ops/sec |
~588,871 ops/sec |
~1.58× faster |
| deep |
~124,505 ops/sec |
~73,292 ops/sec |
~1.70× faster |
| deep circular |
~183,042 ops/sec |
~139,264 ops/sec |
~1.31× faster |
| big |
~12,467 ops/sec |
~7,404 ops/sec |
~1.68× faster |
| leafy |
~42,223 ops/sec |
~19,622 ops/sec |
~2.15× faster |
I realise I'm naturally biased here since this is my package, so I'm opening this to discuss the criteria rather than assuming it should immediately replace the current recommendation.
The main questions I'd like input on are:
- Should the serializer recommendation in the Web Crypto example be evaluated separately from the broader
object-hash → ohash successor path?
- Is
safe-stable-stringify preferred here because of specific technical behaviour, maturity, ecosystem usage, or because it is already documented?
- Once
object-identity passes the 10k weekly downloads soft threshold, would it be reasonable to mention it as the stable serializer option, either instead of or alongside safe-stable-stringify?
Availability
Not a native replacement.
This proposal is for a preferred package replacement / alternative stable serialization, to be used in conjunction with the already documented Web Crypto native hashing API for those use-cases.
Code example (optional)
import { identify } from 'object-identity';
// same shape, different key order, same id
identify({ a: 1, b: 2 }) === identify({ b: 2, a: 1 }); // true
// a plain object and an equivalent Map produce the same id
identify({ a: 'b' }) === identify(new Map([['a', 'b']])); // true
// nesting, Sets, Dates, and RegExps are all supported
const key = identify({ user: 7, filters: new Set(['active', 'new']) });
Package to replace
safe-stable-stringifySuggested replacement(s)
object-identityFrom my benchmarks,
safe-stable-stringifyis already the fastest alternative from others in this space. So only one suggestion for now.Manifest type
preferred (lighter or more modern alternative package)
Rationale
The current
object-hashreplacement guidance correctly points users towardohashas the direct successor when they want an end-to-end hashing library.However, the Web Crypto example is slightly different. It recommends using the native
SubtleCrypto.digestAPI (good) and pairing it with a stable serializer, currentlysafe-stable-stringify.For that narrower case, I think
object-identityis worth considering once it clears the project's 10k weekly downloads soft threshold.The reason I'm proposing this is that, for this specific Web Crypto use case,
object-identityappears to be a smaller and faster fit based on the comparisons I have run.object-identitysafe-stable-stringifyThat makes
object-identityroughly 4.5× smaller for this use case.object-identitysafe-stable-stringifyI realise I'm naturally biased here since this is my package, so I'm opening this to discuss the criteria rather than assuming it should immediately replace the current recommendation.
The main questions I'd like input on are:
object-hash→ohashsuccessor path?safe-stable-stringifypreferred here because of specific technical behaviour, maturity, ecosystem usage, or because it is already documented?object-identitypasses the 10k weekly downloads soft threshold, would it be reasonable to mention it as the stable serializer option, either instead of or alongsidesafe-stable-stringify?Availability
Not a native replacement.
This proposal is for a preferred package replacement / alternative stable serialization, to be used in conjunction with the already documented Web Crypto native hashing API for those use-cases.
Code example (optional)