I only skimmed the github page, but this seems to be more of 'what the author commonly uses' rather than what you'd normally expect of a standard library. For example, I'd expect that many of these features be more in a separate dedicated library rather than the 'standard':
- 40+ PRNGs (You might want one or two, but do you really need so many varients?)
- Plot API (Definitely more suited for a separate library)
- 50+ Sample Datasets (Often useless and a lot of wasted space if not used)
- Native BLAS Interface (Extremely niche usecase)
Edit: To be fair, it does say right at the very beginning "with an emphasis on numerical and scientific computing applications". So they are upfront about it, but the library name and HN submission name are confusing because they don't make this obvious.
Oh. This one. I discovered it a couple weeks ago, and since then I keep wondering - how what's essentially a statistics toolkit can get called a standard library? In every language I can think of that actually has a standard library, the library has very little to do with mathematics.
Notable exceptions are R, Julia, MATLAB, Mathematica, etc. Namely, environments/languages which focus on numerical and scientific computing applications. One of the project's goals is to provide similar functionality on the web and in Node.js as those environments. Accordingly, in order to realize that goal, one needs to offer quality ("standard") implementations for doing mathematical operations (see https://github.com/stdlib-js/stdlib/tree/develop/lib/node_mo...).
I feel spoiled enough by the ecosystem to expect that libraries which wants/advertises itself to be a standard for Node.js to be backed by native code instead of pure Javascript, especially if the use case is complex, numerical computation.
Aside from that, the collection presented here is actually quite remarkable, kudos to the developer(s).
Re: native vs JS. I'd say it depends. For certain implementations, such as operations on large arrays, native implementations can provide performance benefits (see https://github.com/stdlib-js/stdlib/tree/develop/lib/node_mo...). However, for other implementations, including common mathematical functions, implementing them in pure JavaScript can be more performant when running in Node.js, as you do not need to cross from JS to C/C++ (see https://github.com/stdlib-js/stdlib/tree/develop/lib/node_mo...). Lastly, even if functionality is backed by native code, would still need JavaScript fallbacks in order to, e.g., allow for bundling and use in non-Node.js environments.
This looks like just the thing I've been looking for. I'm interested in getting into Mike Bostock's Observable notebooks to do data visualization research but am afraid of the potential frustration of manipulating data frames in JS. This looks like it could make that a lot easier (I see you have a groupby function)
As another comment mentions, this is less of a standard library in the traditional sense and more a collection of functions the author finds useful in their specific line of work on a regular basis - it has a heavy emphasis on numerical and statistical functions that most people probably aren't going to use terribly often.
So in a generic way... maybe? It does offer a set of standard functions that aren't available natively, though personally I find Lodash to be much more of a traditional standard library than this.
In a specific way? No, as I don't see any kind of padding function and there will always be instances in which you need a small module that may be overlooked - that's the nature of any packaging system.
- 40+ PRNGs (You might want one or two, but do you really need so many varients?)
- Plot API (Definitely more suited for a separate library)
- 50+ Sample Datasets (Often useless and a lot of wasted space if not used)
- Native BLAS Interface (Extremely niche usecase)
Edit: To be fair, it does say right at the very beginning "with an emphasis on numerical and scientific computing applications". So they are upfront about it, but the library name and HN submission name are confusing because they don't make this obvious.