On Tue, May 7, 2013 at 5:21 PM, Domenic Denicola
<domenic at domenicdenicola.com> wrote:
> I'm not sure the Node.js scheme is the best idea for the web, but I *would* like to emphasize that the AMD scheme is not a good one and causes exactly the confusion we're discussing here between URLs and module IDs.

I believe this is mixing the argument of allowing URLs in IDs with how
logical IDs might be resolved in node vs AMD. Not all AMD loaders
allow URLs as dependency string IDs, but requirejs does. That choice
is separate from how logical IDs are resolved.

If normal logical ID notation is used with an AMD loader (like,
'some/thing', as in Node/CommonJS), then it is similar to node/CJS. It
just has a different resolution semantic than node, which is probably
an adjustment for a node developer. But the resolution is different
for good reason. Multiple IO scans to find a matching package are a
no-go over a network.

I think the main stumbling block in this thread is just "should module
IDs allow both URLs and logical IDs". While I find the full URL a nice
convenience (explained more below), I think it would be fine to just
limit the IDs to logical IDs if this was too difficult to agree on.
That choice is still compatible with AMD loaders though, and some AMD
loaders make the choice to only support logical IDs already.

---

Perhaps the confusing choice in requirejs was treating IDs ending in
'.js' to be URLs, and not a logical ID. I did this originally to make
it easy for a user to just copy paste their existing script src urls
and dump them into a require() call. However, in practice this was not
really useful, and I believe the main source of confusion with URL
support in requirejs. I would probably not do that if I were to do it
over again.

However, in that do-over case, I would still consider allowing full
URLs, using the other URL detection logic in requirejs: if it starts
with a / or has a protocol, like http:, before the first /, it is an
URL and not a logical ID.

That has been useful for one-off dependencies, like third party
analytics code that lived on another domain (so referenced either with
an explicit protocol, http://some.domain, or protocol-less,
//some.domain.com), which is only "imported" once, in the main app
module, just to get some code on the page. Needing to set up a logical
ID mapping for it just seemed overkill in those cases.

James

On Tue, May 7, 2013 at 5:21 PM, Domenic Denicola <domenic at domenicdenicola.com> wrote:
> I'm not sure the Node.js scheme is the best idea for the web, but I *would* like to emphasize that the AMD scheme is not a good one and causes exactly the confusion we're discussing here between URLs and module IDs.

I believe this is mixing the argument of allowing URLs in IDs with how
logical IDs might be resolved in node vs AMD. Not all AMD loaders
allow URLs as dependency string IDs, but requirejs does. That choice
is separate from how logical IDs are resolved.

If normal logical ID notation is used with an AMD loader (like,
'some/thing', as in Node/CommonJS), then it is similar to node/CJS. It
just has a different resolution semantic than node, which is probably
an adjustment for a node developer. But the resolution is different
for good reason. Multiple IO scans to find a matching package are a
no-go over a network.

I think the main stumbling block in this thread is just "should module
IDs allow both URLs and logical IDs". While I find the full URL a nice
convenience (explained more below), I think it would be fine to just
limit the IDs to logical IDs if this was too difficult to agree on.
That choice is still compatible with AMD loaders though, and some AMD
loaders make the choice to only support logical IDs already.

---

Perhaps the confusing choice in requirejs was treating IDs ending in
'.js' to be URLs, and not a logical ID. I did this originally to make
it easy for a user to just copy paste their existing script src urls
and dump them into a require() call. However, in practice this was not
really useful, and I believe the main source of confusion with URL
support in requirejs. I would probably not do that if I were to do it
over again.

However, in that do-over case, I would still consider allowing full
URLs, using the other URL detection logic in requirejs: if it starts
with a / or has a protocol, like http:, before the first /, it is an
URL and not a logical ID.

That has been useful for one-off dependencies, like third party
analytics code that lived on another domain (so referenced either with
an explicit protocol, http://some.domain, or protocol-less,
//some.domain.com), which is only "imported" once, in the main app
module, just to get some code on the page. Needing to set up a logical
ID mapping for it just seemed overkill in those cases.

James