How should we manage dependencies?

wilzbach commented 9 years ago

If you haven't done so, please read this excellent article as an intro to the problem of dependency management in web components by @Tjvantoll:

http://tjvantoll.com/2014/08/12/the-problem-with-using-html-imports-for-dependency-management/

@Tjvantoll discusses the following options - for convenience shortly summarized here:

Option 1: Use a CDN

<script src="//cdnjs.cloudflare.com/ajax/libs/moment.js/2.7.0/moment.min.js"></script>

only works if exactly the same URL (same CDN provider, same protocol, same version) has been choosen
prevents script concatention
prevents offline development
Option 2: Enforcing a folder structure on the end user + relative imports
The Polymer project uses this strategy
Could be done with either npm or bower
Requires strong convention (naming, structure)
The developer would need to upload two files to /dist (1 dev file with relative imports, 1 minimized with all dependencies)
Can't deal with version conflicts (e.g. two versions of jquery)

The Polymer project is using this approach - here is the distribution guide for 0.5 written by @addyosmani.

Option 3: Feature detection

Summary: using a tiny module loader to detect whether the script has already been loaded

two modules can still request the same module with a different URL
has to be done asynchronously in dev environment
no/harder build (vulcanize) process
Option 4: Not using HTML imports for external dependencies

Summary: no reference in the component's code - the dependency is only referenced in the documentation

This also has been discussed at the Polymer project.

Here is my opinion to start the discussion: Option 2 (enforcing a common folder structure) seems to be the lesser evil.

However for dependency conflicts:

bower's conflict resolution warns you about a conflict and you can choose which version you want to load, but it doesn't help if two components really depend on two different versions (e.g. Angular 1 and Angular 2)
npm3 (currently in beta) is awesome at detecting whether there will be a semantic conflict (as long as the author uses correct semantic versioning) - however if there is a conflict it will put the conflicting file in the components node_modules folder (depending on what module was installed first). As an ugly workaround an author could just include both paths (node_modules/<lib>/dist/<lib>.html and ../<lib>/dist/<lib>.html)

I am very much looking forward to your thoughts :)

herkulano commented 9 years ago

@greenify 2 and 3 are not conflicting, but they are different ways, especially because of Polymer's dependency.

3 depends on Polymer JS, which has a few problems:

Every time Polymer HTML is updated you have to build Polymer JS and update it.
It can be confusing for some people to have Polymer, but not be able to use any of it's components. Like the case of @AntonPetrov, who uses iron-ajax.

I vote for 2. It's cleaner, doesn't depend on Polymer and if someone wants to use Polymer components they can simply import them using the Bower + Polymer way.

Hypercubed commented 9 years ago

By # 2 do you really mean creating a BioJS helper module that acts as a web component constructor... like polymer, without the HTML imports?

herkulano commented 9 years ago

@Hypercubed Isn't that the idea behind what @greenify is doing in https://github.com/biojs/bio-element-vanilla?

Hypercubed commented 9 years ago

Perhaps, but I don't see the API in there yet. What I mean is BioJS web components can use a component constructor that looks like Polymer:

  <script type="module">
    BioJSComponent({
      is: "dom-element",
      properties: {
        greeting: {
          type: String,
          value: "I\'m a DOM element. This is my local DOM!"
        }
      },
      created: function() {
        this.createdRan = true;
      }
    });
  </script>

Hypercubed commented 9 years ago

If it is exactly the same... might as well use polymer. i.e. # 3

herkulano commented 9 years ago

I don't know @greenify's plans on this.

I agree if the library is the same there's no point in duplicating work.

Although, i still have the concerns i mentioned before with using Polymer JS, unless the Polymer team embraces the idea of Polymer JS, which from @addyosmani's comments it's highly unlikely at least short-term.

Hypercubed commented 9 years ago

Polymer JS, if I understand what you mean, could be as simple as:

jspm install polymer=github:Polymer/polymer

and

require('polymer/polymer.html!html');
module.exports = Polymer;

herkulano commented 9 years ago

AFAIK, it doesn't work like that, because of Polymer's HTML Imports. That's why @greenify had to do a Polymer JS, extracting all of the html and importing polymer-mini.html and polymer-micro.html into one .js file.

It would be good if you could test it so that we are sure of what we are saying. I'm not, so don't know if it works or not. :smile:

wilzbach commented 9 years ago

Extracting the Polymer HTML to Javascript is already automated and do think that if we ask nicely they (Polymer) will accept a pull request because it is nothing they have to maintain.

My opinion is that Angular 2 will have support for Web components. It will definitely come in other frameworks like React too or there will be new frameworks. So I don't think we should build our own polymer. We probably lack the resources to maintain it. However if a developer doesn't want to include the 150kb for Polymer he shouldn't need to.

Thinking especially about the parsers it could make sense if we maintain our own lightweight library here because simply they don't need all the fancy features from polymer and all parsers are supposed to inherit from a common parent that we have to and want to maintain anyways.

On July 13, 2015 2:02:12 PM GMT+02:00, Herculano Campos notifications@github.com wrote:

I don't know @greenify's plans on this.

I agree if the library is the same there's no point in duplicating work.

Although, i still have the concerns i mentioned before with using Polymer JS, unless the Polymer team embraces the idea of Polymer JS, which from @addyosmani's comments it's highly unlikely at least short-term.

Reply to this email directly or view it on GitHub: https://github.com/biojs/biojs3/issues/4#issuecomment-120903088

herkulano commented 9 years ago

@greenify

Extracting the Polymer HTML to Javascript is already automated and do think that if we ask nicely they (Polymer) will accept a pull request because it is nothing they have to maintain.

So you still have to update it and push it when they make changes or that is also automated?

My opinion is that Angular 2 will have support for Web components. It will definitely come in other frameworks like React too or there will be new frameworks. So I don't think we should build our own polymer. We probably lack the resources to maintain it. However if a developer doesn't want to include the 150kb for Polymer he shouldn't need to.

Support for web components is not being questioned. Polymer is, which is not the same.

That means you vote for 3, right?

If we're going with 3 we should think about:

Documentation for developers that using Polymer JS != Polymer HTML
Documentation and example of using Polymer components with BioJS components
Fully automated process for Polymer JS [you might already have this]
Build for production. Fully using jspm build, for simplicity or other build tools? [we already have the jspm build working in the systemjs-plugin-html]

wilzbach commented 9 years ago

On 2015-07-13 14:50, Herculano Campos wrote:

@greenify https://github.com/greenify
Extracting the Polymer HTML to Javascript is already automated and do think that if we ask nicely they (Polymer) will accept a pull request because it is nothing they have to maintain.
So you still have to update it and push it when they make changes or that is also automated?

Nope it is not triggered automatically, well we could add that. However I guess asking Polymer is the better way.

My opinion is that Angular 2 will have support for Web components. It will definitely come in other frameworks like React too or there will be new frameworks. So I don't think we should build our own polymer. We probably lack the resources to maintain it. However if a developer doesn't want to include the 150kb for Polymer he shouldn't need to.

Support for web components is not being questioned. Polymer is, which is not the same.

That means you vote for 3, right?

Oh sorry - I was writing the message on my phone. I would prefer if we focus on the basic, Vanilla (#2) approach and find solutions based on this.

If we're going with 3 we should think about:

Documentation for developers that using Polymer JS != Polymer HTML

Documentation and example of using Polymer components with BioJS components

Fully automated process for Polymer JS [you might already have this]

Build for production. Fully using jspm build, for simplicity or other build tools? [we already have the jspm build working in the systemjs-plugin-html]

Also for approach II we have to solve some of those issue. E.g. we have to find our a documentation format/parser (see #9).

herkulano commented 9 years ago

Also for approach II we have to solve some of those issue. E.g. we have to find our a documentation format/parser (see #9).

@greenify agree, automated documentation is a must :+1: although it will be an issuewith any solution we go for.

Hypercubed commented 9 years ago

@herkulano Using systemjs-plugin-html you can import polymer as a global. The HTML imports are all within the polymer project so they are resolved by the browser. That is what I am doing in my app (I can share more tomorrow). The trouble occurs if the developer includes a polymer component which HTML imports a version of polymer using a external relative path. Bundling we still need to figure out.

Hypercubed commented 9 years ago

BTW, I am also testing this method of including scripts in HTML imports (https://github.com/ModuleLoader/es6-module-loader/issues/95). If it works (so far looks good) then we can import HTML files that contain inline ES6 (and dependencies).

herkulano commented 9 years ago

@Hypercubed Great work on systemjs-plugin-html, it's looking good :+1:

herkulano commented 9 years ago

@Hypercubed let me know if you need / want any help with the bundling.

Hypercubed commented 9 years ago

Hello guys, I've added unit tests and updated the html plugin to allow inline script modules. Rather than filling up this issue I created an issue here: https://github.com/Hypercubed/systemjs-plugin-html/issues/2 .

herkulano commented 9 years ago

@Hypercubed :+1:

Hypercubed commented 9 years ago

Here is a way to bridge SystemJS and polymer elements: https://github.com/Hypercubed/systemjs-plugin-html/tree/master/test/polymer

herkulano commented 9 years ago

@Hypercubed great work. didn't have time to check it out, will do it asap.

Hypercubed commented 9 years ago

Since it looks like we are leaning towards 2 or 3 with JSPM build. Perhaps we need some discussion of what this actually means. What is the expected output of a JSPM build step run on a biojs component? What about a JSPM build on a app that includes a biojs component?

Hypercubed commented 9 years ago

Here is an example polymer component that uses SystemJS for dependencies (using the SystemJS html plugin). This also demonstrates jspm bundling using the vulcanize branch of the plugin.

herkulano commented 9 years ago

@Hypercubed that's really great! :+1:

I only have one concern, which might not be an issue for some people. Correct me if I'm wrong, but it's still difficult to use Polymer Elements with jspm, because of the HTML Import links. For example, paper-button.html looks like this:

<link rel="import" href="../polymer/polymer.html">
<link rel="import" href="../paper-material/paper-material.html">
<link rel="import" href="../paper-ripple/paper-ripple.html">
<link rel="import" href="../paper-behaviors/paper-button-behavior.html">

Because of the way bower's folder structure works they can get away with this link: ../

We could change it at runtime and build time to point to the right folder, similar to what polyserve does.

Any thoughts?

Hypercubed commented 9 years ago

The setup I've shown uses polymer as a helper, but doesn't need to, it can work on vanilla elements. To use polymer elements you can do what I showed here: https://github.com/Hypercubed/systemjs-plugin-html/tree/master/test/polymer . Basically, create a ../polymer/polymer.html file that imports the jspm installed version of polymer. It should bundle using vulcanize/system-plugin-html. Unfortunately you need to manually install the elements.

Hypercubed commented 9 years ago

The biggest problem I am seeing is that if you incorporate two copies of the same HTML import with different urls (including polmer.html its self) HTML imports/vulcanize can't deduplicate, resulting in a runtime error.

herkulano commented 9 years ago

@Hypercubed :+1:

doomedramen commented 8 years ago

I am 100% behind option 2

frankandrobot commented 8 years ago

Great work guys. But what is the final result? (I counted about half-dozen outgoing links + sample repos). In particular, I'm interested in Option 3. Polymer JS + SystemJS + JSPM Build Mainly what I'm interested in is Polymer JS + SystemJS. If I have to use vulcanize to bundle, that's fine.

What are my options? Is there a sample repo?

Update: using hypercube's HTML plugin, I was able to create a polymer component that is JSPM installable in an app. (I apologize for not having any code to share since I'm behind an enterprise proxy.) However, I seem to be unable to JSPM install existing polymer components. Ex: iron-collapse. Are we supposed to use the JSPM bower endpoint for these?

davidmaxwaterman commented 8 years ago

I'd also like to know the final result...

Hypercubed commented 8 years ago

I can't speak for BioJS but for me, there was too much flux and uncertainty around WC.

biojs / biojs3

How should we manage dependencies? #4

Option 1: Use a CDN

Option 2: Enforcing a folder structure on the end user + relative imports

Option 3: Feature detection

Option 4: Not using HTML imports for external dependencies