JavaScript has no standard way for one library to include another. But it is very easy to insert a library into a web page.

The code I ported is a standalone library that can be imported into a web page and then its functions can be called. There is a lot of useful code that looks like that. It is a shame that there is no standard bit bucket that you can put it in.

Yes, but here's the problem. I am using JavaScript outside of the browser on a project at the moment. I want to use your library, but your library directly loads a dependency, by trying to load a webpage. My JavaScript motor doesn't know how to load webpages, so now I can't use your library. On the other hand, if we had a standard call for loading libraries, each implementation could do as it needs - web browsers could try to load the code from a known repository on the current page's server. Embedded JavaScript and server-side JavaScript could load from a known repository, or from a repository specified at the launch of the JavaScript session. And we could all specify our dependencies in a clean manner that would be transportable.

I feel like you are not responding to what I wrote.

My statement is that having a widely known repository is still useful for random libraries which are simple enough to not have dependencies. I completely agree that having a standard way of loading dependencies would make such a thing much more useful still, but it still has utility without that.

Seriously, if you need to be able to calculate several standard probability distributions to 5 digits of precision in JavaScript, you can do it today with the library that I ported. Either embedded or server side. Doesn't matter. Go ahead and use it. (If GPL/Artistic doesn't work for you then I'm sorry. I can't grant a more generous license than the Perl version I started with.)