IE and Webkit-based browsers will evaluate the script tags in a
non-deterministic order (*not* in the order they are added to the
document), so they will simply not work in this mode.
>
> The second issue is that a goog.net.BulkLoader is always used, even if
> the URIs that contain the modules are on a different domain. Ideally,
> I think that ModuleLoader should check to see whether the URIs are on
> the same domain first before opting to use a goog.net.BulkLoader. As
> the existing comment in the code points out, the JS should be made
> available on the same domain so that it can be loaded with an XHR so
> that failures are easier to monitor, but I can imagine scenarios where
> someone might serve their JS on the same domain in production. (For
> example, resources may be spread across subdomains to get around the
> browser's connection limit.)
>
> The simplest solution that would unblock me would be to drop the "&&
> goog.userAgent.GECKO" clause from the conditional. In production, I
> happen to serve the JS for the modules on the same domain, so the
> second item isn't an issue for me personally, but I could fix it while
> I'm already in the code if it is an issue for others.
>
> If anyone is curious why I even have this problem, it is because I'm
> adding support for modules to plovr (http://plovr.org/). Because plovr
> is run on a separate domain during development (localhost:9810), the
> main page (which is probably running on localhost:80 or localhost:
> 8080) needs to be able to load the modules from plovr, so XHRs won't
> work.
>
Some people have asked for a CrossDomainBulkLoader, but I don't know
if anyone has looked into how hard it would be. It's not as simple as
changing an if condition. Most people I know just use server-side
forwarding to play make-believe that the cross-domain resource is on
the same domain, but I don't know how widespread that practice is.
Nick
How slow is "slow"? I guess slow is better than nothing. Go for it.
Idly thinking about the larger problem:
Ideally, we would pressure browser developers to just provide some
standard way to do this.
You could use the "// @sourceURL" trick, but it means that everyone
has to modify their serving infrastructure to add a @sourceURL and
serve the raw JS somewhere, which is a PITA. And even if you use the
"// @sourceURL" trick, it still doesn't help with stack traces:
http://code.google.com/p/v8/issues/detail?id=672
There are also progressively hackier things that you could do with
JSONP, etc. But none of them are really satisfying.
Nick
OK, I tested this out by creating several test pages. In my own
experiments and Googling, I could not figure out a way to just append
the <script> tags in such a way to enforce load order.
Message received:
http://wiki.ecmascript.org/doku.php?id=strawman:simple_modules
http://wiki.ecmascript.org/doku.php?id=strawman:simple_modules_examples
> You could use the "// @sourceURL" trick, but it means that everyone
> has to modify their serving infrastructure to add a @sourceURL and
> serve the raw JS somewhere, which is a PITA. And even if you use the
> "// @sourceURL" trick, it still doesn't help with stack traces:
> http://code.google.com/p/v8/issues/detail?id=672
>
> There are also progressively hackier things that you could do with
> JSONP, etc. But none of them are really satisfying.
The Dojo approach to this has been to treat x-domain loading as the exotic
case and assume a tool had been run in order to enable it. That
let the build system do the hackish JSONP things while the loader only
needs to determine if the requested module base path is on or off
the local domain before requesting it.
Not perfect, but it at least allows workable CDN hosting of modules
with the significant caveat that you can't optimize nearly as
aggressively.
Regards