fp-stdlib v0.13.0-beta.6
fp-stdlib
Stdlib is a lightweight library meant to fill the gap between Ramda (functional) and Lodash (performance). All functions are auto-curried and expect data as the last argument to encourage composition.
Stdlib vs. Ramda vs. Lodash
| Category | Stdlib | Ramda | Lodash | Lodash-FP |
|---|---|---|---|---|
| Minified (kb) | 6.38 | 41.1 | 66.8 | 76.6 |
| 100% Immutable | Yes | Yes | No | Yes |
| Auto-Curry | Yes | Yes | No | Yes |
| Object Equality | Reference | Value | Reference | Reference |
| IE 9+ | Yes | Yes | Yes | Yes |
Benchmarks
Each benchmark is measured by the tested operation being performed 10,000 times. The results are in ms. Take these with a grain of salt, they are currently just based off of results from a local Node v6 environment.
| Function | Parameters | Stdlib | Ramda | Lodash | Lodash-FP |
|---|---|---|---|---|---|
| filter | 10,000 items | 295 | 279 | 1369 | 1365 |
| find | 10,000 items | 70 | 63 | 1333 | 4480 |
| findLast | 10,000 items | 62 | 62 | 1213 | 4155 |
| map | 10,000 items | 160 | 843 | 180 | 183 |
| reduce | 10,000 items | 108 | 6357 | 135 | 150 |
| scan | 10,000 items | 524 | 577 | -- | -- |
| sum | 10,000 items | 77 | 8524 | 882 | 884 |
| takeWhile | 10,000 items | 138 | 743 | 407 | 392 |
Comparisons
Stdlib vs. Ramda
To be continued...
Stdlib vs. Lodash
Lodash is extremely popular for good reason; it is renowned for its incredibly performance and exceptionally ergonomic API. We'll touch on both of these separately as we compare it against Stdlib.
Graceful Null Checking
Graceful null checking is the concept that you can provide a null, undefined, or otherwise bad value to a function and not cause it throw at runtime. This feature is beloved by many JavaScript developers since it eliminates one of the biggest sources of pain caused by the language's dynamic nature. Its ommission from Stdlib is not accidental; Lodash's null checking solution, in my opinion, the wrong solution to the problem.
Lodash's graceful handling of null values serves to prevent runtime errors, but does so silently -- this is the key. I instead argue that users should be more explicit about edge cases and handle them opaquely (this is also where Functors start to shine since they essentially encapsulate this logic inside of a type).
Function Shorthands
Concerning shorthand syntax, in my experience I've found it to be more sane to keep API surface area as small as possible, and this means avoiding polymorphic and overloaded functions. By limiting the number of different ways a function can be applied, we implicitly standardize code styles and limit the amount of "magic" in the codebase.
Design Philosophy
Lodash's functional build, coined lodash-fp, does a great job at trying to pull Lodash back into the functional world. However, there are a few areas where it is lacking. First, it is simply a transformed version of lodash core. This makes sense, since it wouldn't be wise to rewrite Lodash in its entirity and maintain the two separately; however, what this means is that it is a second class citizen. It lacks sufficient documentation, instead opting to describe how lodash core is transformed to lodash-fp, which is lacking as a reference resource.
Recommendations
Lodash will always be a more comprehensive library than Stdlib. If you are looking for a full functional replacement, or a functional library that offers similar shorthand methods, Stdlib is not it.
To be continued...