Split API spec for modules and loader?

[Mike Wilson]

The AMD API description (https://github.com/amdjs/amdjs-api/wiki) currently intertwines discussion of how modules may be written with how the loader is configured. These two things are separate concerns that could benefit from a clear division from each other in the spec. It is crucial to keep a standardized and stable API for modules (typically you have many modules possibly from multiple sources), while a standardized loader configuration is not equally important (typically you configure the loader in one file that you have control over yourself, so updating is not a big problem if you switch to another AMD loader).

With this mindset I'm thinking it will be quicker and easier to find consensus on the important parts (API visible to modules), not mixing this task with the search for the best loader configuration style. Actually, there may very well be room for completely different loader configuration styles, so a question in itself might be what is, or isn't, relevant to specify in the AMD spec.
An example of this pattern is Java's inject package, which declares annotations that are used by modules to specify their injection wishes in a container-independent manner. The injection container (Spring, Guice, etc) chosen by the application is supplied its own implementation-specific global configuration.

A final thought is that it might be good to put version numbers on the AMD API spec iterations?

Best regards
Mike

[James Burke]

On Tue, Jul 23, 2013 at 7:02 PM, Mike Wilson <mik...@gmail.com> wrote:
> The AMD API description (https://github.com/amdjs/amdjs-api/wiki) currently
> intertwines discussion of how modules may be written with how the loader is
> configured. These two things are separate concerns that could benefit from a
> clear division from each other in the spec. It is crucial to keep a
> standardized and stable API for modules (typically you have many modules
> possibly from multiple sources), while a standardized loader configuration
> is not equally important (typically you configure the loader in one file
> that you have control over yourself, so updating is not a big problem if you
> switch to another AMD loader).

I'm not sure what this means in practice, besides putting some headers
over the home wiki page, such that:

Module API

* AMD

Loader APIs

* require
* Loader-Plugins
* Common-Config

That is how the specs are grouped as far as module declaration vs
loader APIs, with the AMD part being very stable for some time now.
The fuzziness is really in Common-Config and Loader-Plugins, and with
Loader-Plugins more around build APIs than runtime APIs (although I am
sure we could tighten down the runtime APIs too).

> With this mindset I'm thinking it will be quicker and easier to find
> consensus on the important parts (API visible to modules), not mixing this
> task with the search for the best loader configuration style. Actually,
> there may very well be room for completely different loader configuration
> styles, so a question in itself might be what is, or isn't, relevant to
> specify in the AMD spec.

The AMD part of the wiki is very stable, the others are less so. In
practice, just having a module API is not so useful, some common
agreement on loader API also is useful. The ES6 "Modules" and "Module
Loader' wiki pages reflect this too.

> An example of this pattern is Java's inject package, which declares
> annotations that are used by modules to specify their injection wishes in a
> container-independent manner. The injection container (Spring, Guice, etc)
> chosen by the application is supplied its own implementation-specific global
> configuration.
>
> A final thought is that it might be good to put version numbers on the AMD
> API spec iterations?

I would avoid versioning. I see it more like HTML, just an evolving
spec. I'm actually hoping ES6 modules really get nailed down soon so
there will be less need for AMD over time.

Although, I can see, due to the limited capability of the built-in ES
Module Loader, that the Loader-Plugins and Common-Config APIs still
may make sense post ES6, although I could see revisiting them at that
time. For instance, the hooks for the Loader-Plugins API may be
slightly different to mesh with the built in Module Loader hooks.

Depending on how that shakes out though, it is possible it will just
work via feature detection and a version would not be needed. I think
we need more data and a more solid ES6 set of specs to know for sure.

James