The benefit is having a loader that isolates different apps/widgets in
the browser without having to configure anything at build time and
writing canonical IDs into the bundle files. It completely separates
building from loading. While the loader does not support AMD syntax out
of the box it should be trivial to add as an extension. I would be happy
to explore this if there is interest.
> I think it is great to have different small loaders that specialize on
> specific tasks, even ones that do not support loader plugins. However,
> I did not follow your points about not explicitly supporting plugins:
>> > * They are present and can be executed when generating bundles.
> I think the plugin needs to be present anyway since it is needed for
> runtime? I'm not sure what this point is about. Maybe expanding it
> would help.
Scrap that explanation. It was late :) Let me try and elaborate and I
will update the text when this thread is done.
To me there are two types of plugins:
1) Plugins that modify module source before module is loaded
2) Plugins that modify loader to achieve specific behavior
While RequireJS seems to combine these two types into the same interface
I believe they should be separated and handled distinctly.
Plugins that facilitate (1) should be declared by the exporting package
(provider) not the module requiring the modified module (consumer). By
having the provider export a consistent modified module all consumers
will always get the same module and the modified module may be written
into the bundle file without needing to include the plugin. The plugin
should be an AMD/CJS module that is invoked at build time to "compile"
the module source once. I don't think you want the overhead of the
plugin on the client side in most cases. For this approach to work you
* A development loader that understands packages and package
descriptors and is able to load (without server helper of build step)
type (1) plugins into the browser (and these plugins must run in the
browser). A browser loader that could do this is BravoJS with the
package mappings plugin .
* A server helper or build step that invokes the plugins and only
makes the result available eliminating the extra step from the client.
Plugins that facilitate (2) should be loaded along with the application
and then be injected into a sandbox to modify the behavior of the
sandbox's require which then loads the application code. These plugins
should be pure JS AMD/CJS modules.
In my experience, the above approach simplifies the loader logic and
makes the build step more robust.
>> > * Module/resource source code is bundled in a specific format potentially leading to duplicate source code in bundles.
> I also do not follow this point either, expanding on how there could
> be a duplicate source in a build would be useful to know.
I take this back. It applies only to cases where an application requires
the raw module source and the modified module source (without wanting
the type (1) plugin on the client). I don't see a way around this.