
Standard library for JavaScript and Node.js - gballan
https://github.com/stdlib-js/stdlib
======
itmeyou
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.

~~~
GroSacASacs
Have a look at BlasJs also
[https://github.com/R-js/blasjs](https://github.com/R-js/blasjs)

------
TeMPOraL
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.

~~~
kgryte
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...](https://github.com/stdlib-
js/stdlib/tree/develop/lib/node_modules/%40stdlib/math/base/special)).

Aside: calling the library "essentially a statistics toolkit" is a
mischaracterization given that the bulk of available functionality is _not_
statistics. For example, lodash/async style utilities
([https://github.com/stdlib-
js/stdlib/tree/develop/lib/node_mo...](https://github.com/stdlib-
js/stdlib/tree/develop/lib/node_modules/%40stdlib/utils)), iterator utilities
([https://github.com/stdlib-
js/stdlib/tree/develop/lib/node_mo...](https://github.com/stdlib-
js/stdlib/tree/develop/lib/node_modules/%40stdlib/iter)), assertion utilities
([https://github.com/stdlib-
js/stdlib/tree/develop/lib/node_mo...](https://github.com/stdlib-
js/stdlib/tree/develop/lib/node_modules/%40stdlib/assert)), benchmark
framework ([https://github.com/stdlib-
js/stdlib/tree/develop/lib/node_mo...](https://github.com/stdlib-
js/stdlib/tree/develop/lib/node_modules/%40stdlib/bench/harness)), etc. While
certainly a WIP, might prove informative to peruse:
[https://github.com/stdlib-
js/stdlib/tree/develop/lib/node_mo...](https://github.com/stdlib-
js/stdlib/tree/develop/lib/node_modules/%40stdlib).

------
diegoperini
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).

~~~
kgryte
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...](https://github.com/stdlib-
js/stdlib/tree/develop/lib/node_modules/%40stdlib/blas/base/daxpy/benchmark)).
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...](https://github.com/stdlib-
js/stdlib/tree/develop/lib/node_modules/%40stdlib/math/base/special/hypot/benchmark)).
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.

------
jdpigeon
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)

~~~
kgryte
For an example of using stdlib in Observable, see here:
[https://beta.observablehq.com/@kgryte/stdlib-real-time-k-
mea...](https://beta.observablehq.com/@kgryte/stdlib-real-time-k-means-
clustering). Other notebooks can be found here:
[https://beta.observablehq.com/collection/@kgryte/stdlib](https://beta.observablehq.com/collection/@kgryte/stdlib).

------
nmstoker
So is this a way to help reduce the risk of leftpad type problems in NodeJS?
[https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/](https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/)

~~~
chrismeller
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.

~~~
pburckhardt
padding functions and other string utilities are available under the "string"
namespace: [https://github.com/stdlib-
js/stdlib/tree/develop/lib/node_mo...](https://github.com/stdlib-
js/stdlib/tree/develop/lib/node_modules/%40stdlib/string)

