Policy: how should we handle "web component-like" modules written in other libraries - e.g. Angular 1?

[wilzbach]

Angular 1's directives are conceptually similar to Custom Elements, but they are implemented without the Web Components API.

There are a couple of small problems with Angular directives

• they don't have the concept of a shadow dom or encapsulation
• they allow to bind with existing DOM elements
• Angular doesn't enforce hyphen-separated (aka x-prefix) naming (e.g. is possible)

Here is my opinion (feel free to discuss): BioJS3 should only include "real" web components - any helper library that helps to create them and sticks to our (to be defined) API/policy is fine.
And in the future this won't be a big problem, as Angular 2 directives will be web components :)

[mhelvens]

Hi Seb,

You know my thoughts on this, but let me put them on record: I don't think it's smart to "only allow X" in BioJS. Rather, each component needs to be properly annotated with which capabilities it does and doesn't have. This could be web-component, Angular 1, Angular 2, React, Riot, FRP, etc. The registry can be filtered by such capabilities, so you can easily look at all web-components if you want to.

Rather, if you're convinced that web-components are the best way to go, create a compelling proof of concept, and make people want to implement it. Let web-component-less modules be shamed into compliance through natural selection. ;-)