Polymer 0.8 Module Registry

[Erik Ringsmuth]

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.

[Peter Wong]

I too feel that Polymer is overreaching by providing a module registry API... but at least it appears to be completely optional (unlike Angular's DI).

I don't mind if Polymer uses this internally, but would prefer it stays internal, not be exposed/documented as a public API, and not have other API's use it (mixins).

[Michael Bleigh]

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.

[Justin Fagnani]

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

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 polymer-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/b9cc427b-b0ab-4f00-b654-0eaa2dc7b93d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Daniel Elebash]

@Justin

Do you guys have any ideas you would like to share on how you think ES6 and Html Imports could or should work together.  For me this area is a little fuzzy, and I am concerned about the dedup feature of html imports not being very robust.

ES6 looks like it will be adopted fairly well across browsers, at least that is how it seems right now.  Maybe moving away from html imports towards ES modules might be the way to go.

If you could share the teams thoughts on how you would like to see ES6 modules, module loader and Html imports work together that would be helpful.

Thanks,

Dan

[Erik Ringsmuth]

@Daniel

I've never felt HTML Imports was a module loader at all. It serves a separate purpose loading HTML documents, but not JS modules. It feels appropriate to import a document that registers an element if it's all declared using HTML. I think Mozilla sees it as a module loader and that's why they took the stance of not shipping it https://developer.mozilla.org/en-US/docs/Web/Web_Components/HTML_Imports. I still hope this will change if they realize it's not a module loader, but a way to load external HTML assets.

Todays script tags can import ES6 modules using a polyfill for System.import() https://github.com/ModuleLoader/es6-module-loader. This would really become slick if the module tag is adopted https://github.com/ModuleLoader/es6-module-loader#module-tag.

One of the things I'm not clear on ES6 modules is whether they can load non JS assets. This is something SystemJS can do with it's plugin system similar to RequireJS's plugin system https://github.com/systemjs/systemjs#plugins.

My idea of a slick setup for an element definition would look something like this.

<link rel="import" href="user-view.html">


<dom-module id="main-view">
  <template>
    <user-view first="{{user.first}}" last="{{user.last}}"></user-view>
  </template>
</dom-module>


<module>
  import { Polymer } from 'bower_components/Polymer';


  Polymer({
    is: 'main-view',
    published: {
      user: Object
    }
  });
</module>

[Daniel Elebash]

@Eric

I think a big question that you asked is if the module loader can load non js, I think that is a very important question. 

Another problem is that in your example you have

import { Polymer } from 'bower_components/Polymer';

which could also be written as

<link rel="import" href="bower_components/Polymer/polymer.html">

and this is where the confusion comes, why two different ways to load assets, what I would like to have would be one way to load all assets.  Html imports are ok, but if the ES6 module loader can load and manage all assets then wouldn't it be better to not use Html Imports.  Html Imports is simple so maybe we keep it for simple cases, but the module loader does not need to be complicated either.

I would rather see a unified standard for loading assets implemented across all browsers and was hoping ES6 module loader might be that solution maybe it will evolve to that.

When it comes to Polymer if we use html imports which brings in our js files as well, then I guess we don't need to use module loader, but I can see this getting very ugly if an app uses part module loader part html imports.  Also the de-duping feature is not very robust, just having two jquery files from two different cdn's in two different web components defeats the de-dup feature. 

[Erik Ringsmuth]

This doesn't directly load Polymer.

<link rel="import" href="bower_components/Polymer/polymer.html">

It loads an HTML file with this script tag.

<script src="polymer.js"></script>

HTML imports don't load JavaScript. They load HTML that may contain an inline script tag or a script tag with a `src` attribute. This isn't module loading in any way shape or form. It's not wrong. It's a completely valid way of doing it. It's just not module loading.

With the `script` tag and the `link` tag we have 2 types of "loaders". ES6 modules can replace the script tag. You still need 2 types of loaders either way.

The de-dupe feature in HTML imports isn't the part that's lacking. The problem you mentioned about jQuery is that it's defining itself on the window global as `window.$` and `window.jQuery`. Modules on the other hand don't ever define globals. You load a reference to the object using it's file path. If you have two different versions of jQuery as modules, say `bower_components/jquery/1.7.0/jquery.js` and `bower_components/jquery/2.1.0/jquery.js`, and you load 2.1.0 using `import { $ } from 'bower_components/jquery/2.1.0/jquery'`, it wouldn't conflict with 1.7.0.

HTML imports doesn't have a problem with de-duping. The problem is globals. The thing I don't want to see Polymer suggest doing is this "module registry" which has nothing to do with modules. It's a namespace mechanism. HTML imports are a great alternative to loading HTML with iframes but they are a mediocre way of loading JavaScript at best.

[Peter Wong]

FYI - It looks like the module registry was just removed: https://github.com/Polymer/polymer/pull/1264

On Sunday, February 22, 2015 at 2:24:12 PM UTC-6, Erik Ringsmuth wrote:

[Erik Ringsmuth]

Thank you Polymer team!

[Taylor Savage]

Thank you for the feedback! We're closing in on the proper 0.8 release which as Peter pointed out won't include a module registry, and this kind of feedback will be critical as we're moving toward a 1.0 - really appreciate it.

Taylor

On Fri, Mar 6, 2015 at 7:08 PM, Erik Ringsmuth <erik.ri...@gmail.com> wrote:

Thank you Polymer team!

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 polymer-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/33c2e8b3-9d84-450a-b62e-0efd8d185cc8%40googlegroups.com.

[Martin Amm]

I personally think that removing the module registry was a step in the wrong direction. I think that having to hard code file names for dependencies is currently the weakest point in the Polymer architecture.

I'd prefer to replace the current import like

 <link rel="import" href="../core-icons/core-icons.html">

with

 <link rel="import" name="core-icons">

and then being able to define in globally which url provides core-icons.html.

This would allow to e.g. replace core-icons/core-icons.html with my-icons/core-icons.html

It would also allow to control client side caching by e.g. starting with /version1/core-icons.html and replace it later with a newer /version2/core-icons.html without having to modify all imports.

[Carl Youngblood]

I like this suggestion of being able to name imports and change load paths.

[Justin Fagnani]

On Tue, Mar 10, 2015 at 8:19 AM, Martin Amm <m...@adenin.de> wrote:

I personally think that removing the module registry was a step in the wrong direction.

The module registry wasn't 100% required for core (as evidenced by the fact that it could be removed :) ), so it's easiest to remove it for now while we still try to figure out the right solution for elements and libraries that need to reference each other. That might be just be some instructions on how to use existing module systems like AMD or SystemJS with HTML imports.

We also played with a version of the old module system that was tweaked slightly to be AMD compliant (mostly a rename of modulate->define). That's nice to me because it doesn't require any source transformation. I know others might prefer Browserify, SystemJS or an ES6 transpiler which do.

We will be publishing a lot more information, and maybe some more code too, but for 0.8 it was better to slim down and focus.

Cheers,

  Justin

 

I think that having to hard code file names for dependencies is currently the weakest point in the Polymer architecture.

I'd prefer to replace the current import like

 <link rel="import" href="../core-icons/core-icons.html">

with

 <link rel="import" name="core-icons">

and then being able to define in globally which url provides core-icons.html.

This would indeed be great, but the module registry couldn't provide this behavior because it can't hook the resolution of import URLs. The solution here probably involves a spec for import hooks that's ideally just the same as the one for ES6 modules.

 

This would allow to e.g. replace core-icons/core-icons.html with my-icons/core-icons.html

It would also allow to control client side caching by e.g. starting with /version1/core-icons.html and replace it later with a newer /version2/core-icons.html without having to modify all imports.

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 polymer-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/6084ebf7-ef28-403e-9e9d-28f12fc7891a%40googlegroups.com.

[pianoboy sai]

another framework "aurelia " used systemjs, it could use ES6 module as data binding

https://github.com/aurelia/documentation/blob/master/English/get-started.md

I really hope ploymer could support this.

On Sunday, February 22, 2015 at 12:24:12 PM UTC-8, Erik Ringsmuth wrote: