radash vs remeda: 772 B vs 1.6 KB Gzip
5 min read
Hands-on
I bundled ten overlapping helpers from each library on this box: radash 12.1.1 came out at 772 bytes gzip, while remeda 2.51.0 came out at 1,560 bytes. On the same fixtures, pick/omit/group/unique/clone favored radash; isDeepEqual favored remeda by about 3×.
Short answer: pick radash when you want a smaller data-first toolkit with dotted-path get. Keep remeda when you want pipe/data-last composition and a faster deep-equal. No affiliate links in this post.
What I tested
- Machine: 8 vCPU Intel Xeon / 15 GB RAM shared Linux cloud box, tested 6 Oct 2026 about 02:20 IST.
- Versions: radash 12.1.1, remeda 2.51.0, Node 22.20.0, esbuild 0.28.2 browser ESM minify + gzip -9.
- Inputs: nested object, 50-row group fixture, 100-int unique list. Speed: 30k–300k calls per op, median of 9 rounds, two runs with library order reversed. Scripts in /workspace/bench-radash-remeda/.
- Findings: core ten-export gzip 772 B vs 1,560 B; full namespace 4,915 B vs 9,203 B. ns/op (run1/run2): pick 102/95 vs 123/118; omit 280/271 vs 363/359; group 558/546 vs 783/794; unique 558/846 vs 2,631/2,629; isEqual same 554/606 vs 188/206; clone 182/182 vs 3,238/3,280.
- One surprise: remeda.prop is single-key only (no "a.b.c" path). My deep-get timing used prop(obj,"a").b.c, which is not the same job as radash.get(obj,"a.b.c").
- Not tested: remeda.pipe pipelines under tree-shaking, Lodash migration parity matrices, or non-JSON values in clone (functions, Map, Date).
How much smaller is radash?
| Build (esbuild browser minify) | Minified | gzip -9 |
|---|---|---|
| radash (10 helpers) | 1,599 B | 772 B |
| remeda (10 helpers) | 4,143 B | 1,560 B |
| radash full namespace | 12,299 B | 4,915 B |
| remeda full namespace | 28,460 B | 9,203 B |
| radash get only | 189 B | 168 B |
| remeda prop only | 206 B | 156 B |
About 2× smaller gzip for a comparable named-export set. Track client cost the same way as size-limit vs bundlesize. Broader Lodash swaps sit in es-toolkit vs lodash. Merge helpers in the same lane show up in defu vs lodash.merge.
Which ops were faster?
| Call cost (median of 9, 2 order-reversed runs, ns/op) | radash | remeda |
|---|---|---|
| pick | 102 / 95 | 123 / 118 |
| omit | 280 / 271 | 363 / 359 |
| group / groupBy | 558 / 546 | 783 / 794 |
| unique | 558 / 846 | 2,631 / 2,629 |
| isEqual / isDeepEqual (same) | 554 / 606 | 188 / 206 |
| clone | 182 / 182 | 3,238 / 3,280 |
| mapValues | 77 / 77 | 92 / 92 |
radash won pick, omit, group, unique, clone, and mapValues on this box. remeda won deep-equal by roughly 3×. Debounce utilities next door are covered in perfect-debounce vs lodash. Cloning tradeoffs also appear in klona vs structuredClone.
Do the APIs match?
| Topic | radash 12.1.1 | remeda 2.51.0 |
|---|---|---|
| Call style | mostly data-first | data-first and data-last |
| Deep path read | get(obj, "a.b.c", fb) | prop is one key; chain or pipe |
| Drop empty-ish object keys | shake (default drops undefined only) | filter + isTruthy on arrays |
| Group | group(arr, fn) | groupBy(arr, fn) |
| Equality | isEqual | isDeepEqual |
pick/omit/group/unique matched on my fixtures. shake({ a:0, b:null, c:undefined }) kept 0 and null; only undefined left. String-case helpers often pair with these toolkits in scule vs change-case. Path helpers sit next to pathe vs node:path.
Which one should you pick?
| Situation | My pick |
|---|---|
| Smallest named-export util set | radash |
| Need dotted-path get with fallback | radash |
| Pipe / data-last composition | remeda |
| Hot deep-equal in checks | remeda |
| Lodash-style kitchen sink already elsewhere | compare es-toolkit vs lodash first |
Bottom line: radash 12.1.1 was 772 B gzip versus 1,560 B for remeda 2.51.0 on ten helpers, and it won most of the mutator/group timings on this box. Who should not switch: teams standardized on remeda.pipe and data-last imports, or code that needs remeda's faster isDeepEqual in a hot path. Hashing keys instead of reshaping objects pairs with ohash vs object-hash.
How this was made: I installed both packages on the ShopperCove box, measured esbuild browser bundles for core and full imports, timed nine overlapping operations in two order-reversed runs, and compared get/prop, shake, pick, omit, and group outputs. The JSON results sit next to the scripts. The write-up was drafted with AI help and checked against that output.
Sources
- 01github.com/sodiray/radash
- 02github.com/remeda/remeda
- 03npmjs.com/package/radash
- 04npmjs.com/package/remeda
Related
Lab evidence
What I found running this
Hands-on on ShopperCove box 6 Oct 2026 ~02:20 IST (8 vCPU Intel Xeon / 15 GB shared Linux, Node 22.20.0). radash 12.1.1 vs remeda 2.51.0, esbuild 0.28.2 browser ESM minify + gzip -9. Size: core ten 1,599/772 B vs 4,143/1,560 B; full 12,299/4,915 vs 28,460/9,203. Speed (9-round median, order-reversed, ns/op): pick 102/95 vs 123/118; omit 280/271 vs 363/359; group 558/546 vs 783/794; unique 558/846 vs 2,631/2,629; isEqual 554/606 vs 188/206; clone 182/182 vs 3,238/3,280. Behavior: radash.get("a.b.c") vs remeda.prop single-key; shake default drops undefined only. Not tested: remeda.pipe tree-shake matrices, Map/Date clone, Lodash parity. No affiliate.
