Where should Web Components live?

Question

This is one big question for me regarding Web Components; The promise of Web Components is that they are meant to be generic re-usable components that anyone can take and run with; eventually being able to create and remix web components to build there own applications and take on existing apps.

However, the big question arises in how to accomplish such a vision, as:

1. We have an app idea, we create a repo for the app, we create the web components inside the app repo

2. We have an app idea, we create a github org for the app, we create a repo for each web component

Option 1 seems like it would reduce the most amount of overhead, but increases the amount of fragmentation, reduces discoverability, and hinders getting new contributors onboard (as they are now confronted with your entire app, rather than just the web component).

Option 2 seems like it would increase overhead, but decreases the amount of fragmentation, while improving discoverability of the web components and the ability for contributors to get up and running with your web component, as a team of maintainers could maintain the same web component together.

However. Option 1 while it increases fragmentation, it seems like it is better catered for the evolution of the web components over time, whereas Option 2 would see a lot of deprecated components laying around in favor of better components developed later on in the development process.

However. That above however, is probably countered by the fact that community agreed deprecation is better than company fragmentation. E.g. better to have a, b, and c, web components with c being the latest. Than to have, company1-a, company2-a, company3-a, with them all being maintained.

So what is the way to accomplish the promise of web components while finding a good balance with implementing them?

Answer 1

Deciding what should be reusable

You should think about it from the component level rather than app level. If you have app functionality that's useful, it's likely that could be factored into a component. At that point, it's an author choice whether or not to make the component available to others. For some cases, it doesn't make sense to share components (e.g. they're specific to the app). For components that should be shareable, the Polymer team embraces your #2.

One repo per component

If you look at Polymer's org, every component is in a separate repo. The idea is that users can easily install individual elements, a la carte:

bower install Polymer/core-ajax

Get what you need is one promise of web components.

Tradeoff of high granularity: overhead

High granularity comes with a price: overhead. As component authors, that's something we're willing to take on. IMO, the flexibility for consumers greatly outweighs the maintenance we take on as authors.

Creating component sets from multiple repos

Keep in mind, the majority of folks won't create hundreds of elements. They'll create just a few. For vendors, it's not terribly hard to create a shell repo that aggregates a set of components. For example, all ou core-elements can be installed with a single Bower command:

bower install Polymer/core-elements

The dependencies are managed for us by Bower. Every component repo maintains its own list of dependencies.