More options for itkjs file loaders

[mhalle]

The current dynamic loading of itkjs file loaders is flexible, but it is inconvenient for a variety of packaging and loading situations.

• It requires extra non-standard webpack machinery
• It prevents straightforward distribution by CDNs
• It causes extra runtime network traffic that might be undesirable in some situations
• As far as I can tell, it uses a non-standard mechanism for module loading

It would be nice to have some additional options for loading support for different file types. The most straightforward and standard is ESM dynamic imports using the import() statement. import() allows a file loader to load whatever code it needs dynamically, much like require() did. This mechanism is supported on most recent browsers according to caniuse.

An alternative is to provide a static import option for specific loaders. That would allow compile/load time initialization of support for particular formats. Other libraries do this with import "@itk/loaders/dicom" style imports that rely on side effects to build up a loader list. This option can be backward compatible with the existing loader: some modules would be loaded at load time, others just-in-time at run time, with the dynamic loading potentially disable-able.

In either the dynamic or static import case, modules would be treated as code, not as data. Right now, itkjs treats its dynamic modules as data that has to be put into the public source repository. By doing so, I would guess these modules are taken out of the standard webpack optimization path. Handling their code just like all the other code from the application is a more convenient and less brittle alternative to the current implementation.

[thewtex]

:+1: @mhalle . Yes, we can make improvements to move to more standard Webpack machinery, perhaps with a loader or the new WebAssembly support in Webpack 5. Also, ESM support would be excellent. Of course, the current infrastructure was developed well before those existed.

One option to be aware of, maybe you already saw it, but compiled modules can be hosted on a CDN or existing server and referenced with their full URL without involving Webpack.

A motivation to have the modules resolved at runtime: we have multi-feature modules available, and the downloaded code depends on the features supported by the client. Previously, this was used for ASM.js as a fallback when WASM was not available. WASM is now fairly well supported across browsers, but SIMD-WASM, WebGPU, are not yet supported across browsers. Another motivation is async, on-demand loading.