Web Components support

Motivations

Carbon has many framework variants, maintaining them (development/testing) is time-consuming effort
- Need single reference implementation for the best markup and a11y considerations, that "just works" for multiple JavaScript frameworks - Need to avoid having to test against multiple frameworks
- From that reason, Carbon Angular team is looking at Web Components (or making their Angular library on top of Web Components)
Win7, where the vast majority of IE11 users are, will be EOS in January 2020 (just a half year ahead)
- Also, Chronium-based Edge seems to get IE11's rendering engine which means user can seamlessly use Chrome rendering engine for latest IBM apps while she can use IE11's rendering engine for her company's legacy app
Salesforce, Red Hat, SAP, Wired, Material, etc. have focused effort on Web Components: https://blog.bitsrc.io/9-web-component-ui-libraries-you-should-know-in-2019-9d4476c3f103
- Salesforce offered to host Web Components spec discussion meeting even: Web Components F2F Spring 2019 WICG/webcomponents#786 (comment)

First beta release by the date of Win7 EOS (January 2020)
- Less-focused effort (prototype with <=20% efforts) in 2Q 2019
- Focused effort (>50% of a few devs) in 2H 2019
- Involve interested teams for contribution
If the feedback goes well
- First production release in Q1 2020
- React/Angular/Vue wrappers in Q2 2020
Keep non-WC-based React/Angular/Vue/vanilla versions for two years after first production release, given some product teams have harder requirements for older browsers
- We can make it shorter or cancel such grace period, depending on the feedback

Should be "bare metal" - Otherwise, it'll be just be yet another framework variant (template syntax bikeshedding)
- No heavy framework should be there on top of Web Components
- Align well to upcoming specs (e.g. Template Instantiation: https://docs.google.com/document/d/1XXJVGKm6UA6SfESDHEH1vFLP5EhTstFYm5DGMQ6Snl8/edit) - One library that is closely aligned to such Template Instantiation spec is lit-html
- Avoid introducing DSL
Consider TypeScript
- I personally am on the fence on this, but some potential contributors seems to be interested in this

Will the Web Components and React/Angular/Vue interop?
- Yes - Imagine <button> as a native button. React/Angular/Vue uses it with no problem. Web Components lets us create Carbon button as <bx-btn> which works the same manner as native <button>, which means React/Angular/Vue can use <bx-btn> with no problem. Here's a React example with data binding:

const Button = (kind, disabled, small, href) => (
  <bx-btn kind={kind} disabled={disabled} small={small} href={href} />
);

Can we still support IE11?
- Though the ideal is dropping support for IE11 given the "future spec" nature, we can try polyfills to get "mininum" support
Will there be another "template syntax bikeshedding"?
- Likely not; We are going with the template syntax used in the one of the most popular design system, which is aligned very well on upcoming specs