I'm considering webassembly for a new project, and this got me wondering:
Is anyone aware of a consortium that is curating a CDN for webassembly libraries? Ideally, such an offering would improve load times with caching, allow for the benefits of dependency injection, and centralize encryption/security behaviors so that new algorithms can be rolled out quickly when the crap hits the fan with quantum computing.
If there isn't one, does anyone know how to lobby to get one started?
I realize that many libraries can be recompiled into webassembly downloads, but that would bloat the application size, and put extra strain on each shop to manage their library consumption.
Additional (but less critical) benefits to a curated CDN would include shared performance increases for libraries that support data warehousing, shared performance increases for database access, forcible separation of concerns when coding, significantly smaller project sizes, simplified interface contracts via nuget, etc. The list of benefits is pretty huge.
Also, if webassembly containers gain enough adoption, such shared libraries could serve as a vehicle to allow for a much more seamless transition to/from different technology stacks (possibly unifying the JAVA stream and .NET linq libraries for example) under the expressed goal of being language agnostic. Webassembly is meant to be language agnostic. It seems like it would be a shame if each technology platform/shop built their own redundant libraries, which would serve to be slower and less reliable than libraries forged under the scrutiny of open sourcing.
Ideally, such an offering would improve load times with caching
It doesn't work like that in modern browsers; for security reasons they incorporate a technique called a double-keyed HTTP cache (unfortunately, I don't know of a good explainer to link out to, but this one should work well: https://github.com/shivanigithub/http-cache-partitioning/).
What this means is that any resources from a CDN are loaded and stored separately under the origin that requested them, and not shared between various websites like it used to be in the past.
As such, you will be much better off actually compiling the required native libraries for your particular application - that way you will benefit from compile-time optimisations, and won't be loading any unused parts of the huge libraries or frameworks for each user.
However, now that we covered the performance aspect, there are indeed some attempts to serve precompiled Wasm modules, mainly for tiny libraries where code size is not as much of a concern as in standard frameworks.
If you're looking for Wasm libraries intended for use from JavaScript, then npm is used just like for other libraries, and is a convenient platform because you can ship JavaScript wrappers (e.g. Emscripten or wasm-bindgen generated code) together with the actual native code. E.g. just a random example from a quick search: https://www.npmjs.com/package/xsalsa20.
If you're looking to ship Wasm applications built with WASI API in mind, then you might be interested to take a look at https://wapm.io/, which does just that and ships a bunch of precompiled apps.
TL;DR: there are some package managers and CDNs that allow shipping WebAssembly libraries and applications, but it's done mainly for convenience, not performance; if you care about performance and download sizes, then you're better off compiling native libraries yourself for your particular app.