This is a very active topic of discussion and experimentation on the team. The module registry in 0.8 is basically the minimally viable system given that html imports already do the dependency loading, de-duping, and ordering. And it really is minimal at < 40 lines of code, since it only deals with registry and lookup, while other loaders do much more. If it's a knee-jerk reaction, it's really just to our own need to manage JS dependencies in a relatively new world of html imports, and a demonstration of how simple a task that is in the new world.
We have some use cases that are important: library referencing internal to Polymer, using JS libs in Polymer elements, and using Polymer elements in other JS libraries and frameworks. Our ideal would be ES6 module loading that works well with html imports, and the whole world switching to that, but something has to work in the meantime. We're going to look into whether or not the module registry as is should stick around, change, be internal only, be replaced, and how we could either make other loaders, or at least the API of other loaders, play nice with html imports. Stay tuned. -Justin On Sun, Feb 22, 2015 at 3:10 PM, Michael Bleigh <[email protected]> wrote: > I think module loading is maybe the biggest unsolved question wrt Web > Components (and maybe the web in in general). With Mozilla backing away > from HTML imports, it seems less certain that they will become part of a > final, widely-adopted spec. There's also the duplicate import issue that > makes it more or less impossible to work with Web Components without using > a flat-hierarchy-package-manager like Bower. > > I don't have the answers to these questions, but they do need to be > answered. I think it's both necessary and important to have a mechanism for > modularizing HTML and CSS in addition to JavaScript, but at the same time > especially in Polymer 0.8 where component definitions seem much more > JS-centric an HTML file with a <script> tag and nothing else doesn't quite > seem right either. > > Web Components are paving the way for the elimination of framework silos > like jQuery plugins, etc. in terms of their "it's just DOM" interaction > model, but I think there's still significant work to be done on the > resource loading side. What we really need are lower-level primitives that > can be hooked into. We need some kind of standard primitive upon which ES6 > modules, HTML Imports, and RequireJS could all be built. Without that, > we're just going to see further fragmentation and the continued reliance on > build steps. > > Again, reliance on a build step isn't that big of a deal for people > building larger-scale apps (where a build step is expected and/or > necessary), but what about when Web Components want to start going down > market? When we want it so that anyone with a blog is just a <link > rel="import"> to a CDN URL away from doing big complex things? > > Hard questions to answer, but good discussion to have. > > > On Sunday, February 22, 2015 at 12:24:12 PM UTC-8, Erik Ringsmuth wrote: >> >> Polymer 0.5 is good because it isn't a framework. It has a limited scope >> of adding template binding and event mapping to custom elements and the >> template tag. The addition of a "module registry" is crossing the line from >> library to framework. >> https://github.com/Polymer/polymer/blob/0.8-preview/ >> PRIMER.md#module-registry >> >> This feels like a knee jerk reaction to the people asking for the ability >> to load JS. It looks like a combination of RequireJS and Angular 1.0 DI >> which is just a glorified namespace system. >> >> The module registry looks like a very small subset of RequireJS that only >> implements named modules http://requirejs.org/docs/api.html#modulename >> and requires loading them beforehand either with HTML imports with inline >> script tags, or loading a JS file that calls modulate(). Named modules are >> one of the dangerous/sketchy features of RequireJS and was implemented so >> the r.js optimization tool could bundle modules into a single file. >> >> When Angular 1.0 was released, there was only RequireJS. Now we are in >> the era of SystemJS, RequireJS, and soon ES6 modules. There is a huge >> amount of utility in offering a module system, but why create yet another >> one? I see this leading to a future where everyone is writing Polymer >> modules rather than ES6 modules. It's tightly coupling the module system to >> the framework just like Angular 1.0. >> >> I know I don't really have any say in the matter, but I would leave out >> the module registry altogether or have it be a separate library and give >> people the option between that, and some of the other options like these. >> >> System.import >> https://github.com/ModuleLoader/es6-module-loader#getting-started >> >> module tag >> https://github.com/ModuleLoader/es6-module-loader#module-tag >> >> SystemJS >> https://github.com/systemjs/systemjs >> >> RequireJS >> http://requirejs.org/ >> >> Browserify, Webpack, etc. >> >> Everything else about Polymer is awesome, but I'm struggling with my >> feelings about 0.8 solely due to the addition of such a non-standard >> feature to a library devoted to enhancing web standards. >> > Follow Polymer on Google+: plus.google.com/107187849809354688692 > --- > You received this message because you are subscribed to the Google Groups > "Polymer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/polymer-dev/b9cc427b-b0ab-4f00-b654-0eaa2dc7b93d%40googlegroups.com > <https://groups.google.com/d/msgid/polymer-dev/b9cc427b-b0ab-4f00-b654-0eaa2dc7b93d%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups "Polymer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAEKsHmCvYzHLhZCHL5Nw1nc407gU1PXv6%3DS85ssMD7-KQ9OgDg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
