Thanks @kgryte
I compared the size of the minified files on my disk.

Thanks for circling back. Looking at the UMD bundle, the bundle is around 76 kb, but, as I mentioned, this is largely due to needing a robust implementation of the inverse incomplete beta function.

Dear @kgryte,

Thanks for the fast reply and sorry for the late response.
It is great to know that stdlib-js implementation for inverse t distribution is more accrued :)

I did a random comparison, and the most significant distinction between stdlib-js and jstat for inverting t was that only the first six digits after the decimal point were identical.

For a webpage, speed is important, and there is a significant advantage if the JavaScript file is smaller. The minified jstat is only 72KB and includes many distributions and tests. On the other hand, stdlib is more accurate. Now, I'm not sure which one to use :)
Anyway, more options are always better, and I like the way stdlib-js is organized :)

Re: speed is important. We recognize this, but we also recognize that, while there will always be room for improvement, some implementations will always be more involved (read: require more bytes) than others.

As a general principle, users benefit the more they use stdlib because the more they use stdlib the more underlying implementations are shared.

In contrast, if a user picks and chooses various non-stdlib npm packages, there will likely be duplication of similar logic, leading to eventual larger bundle sizes than if stdlib had been used exclusively.

In short, there will always likely be a bundle size penalty when consuming one-off stdlib packages, just because of our level of rigor and comprehensiveness, but that penalty is significantly reduced and eventually inverted once you consume more and more of the project, as you're allowing stdlib packages to reuse more and more shared infrastructure and underlying implementations.