On Mon, May 20, 2013 at 12:07 PM, Kevin Smith <[email protected]> wrote: > On the other hand, I think it is possible with URLs to create a system which > truly does work out-of-the-box. > > Let's imagine a world where publicly available modules are located at sites > specifically designed for naming and serving JS modules. Call it a web > registry. Intra-package dependencies are bundled together using lexical > modules - the package is the smallest unit that can be referenced in such a > registry. The registry operates using SPDY, with a fallback on HTTPS, so > for modern browsers multiplexing is not a critical issue. In such a world,
There are lots of problems with this kind of URL-based IDs with a web registry, which I will not enumerate because they basically boil down to the problems with using URLs: URLs, particularly when version information gets involved, is too restrictive. The IDs need to have some fuzziness to make library code *sharing* easier. I have given some real world examples previously. That fuzziness needs to be resolved, but it should be done once, at dependency install time, not for every run of the module code. "Dependency install time" can just mean, "create a file at this location", does not mandate tools. At this point, I would like to see "only URLs as default IDs" tabled unless someone actually builds a system that used them and that system got some level of adoption. If it was a great idea and it solved problems better than other solutions, I would expect it to get good adoption. However all the data points so far, ones from other languages, and ones from systems implemented in JS, indicate the URL choice is not desirable. Note that this problem domain is different from something that needs new language capabilities, like the design around mutable slots for "import". This is just basic code referencing and code layout. It does not require any new magic from the language, it is something that could be built in code now. Side note: existing HTML script tag use of URLs is not a demonstration of the success of URLs for a module system since they are decoupled from the references of code in JavaScript, and requires the developer to manually code the dependency graph without much help from the actual code. Another side note: if someone wanted to use a web registry for library dependencies, it could just set the baseURL to the web registry location and have one config call to set the location for app-local code. It would end up with less string and config overhead than "only URLs as IDs". There has even been a prototype done to this extent: http://jspm.io/ -- it is backed by the module ID approach used for AMD modules/requirejs. But again, these are all side notes. The weight of implementations, and real world use cases, indicate "only URLs as default IDs" are not the way to go. James _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
