Web Components support

[asudoh]

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)

Suggestion of timeline and go-to-market strategy

• 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

Architecture

• 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

Q&A

• 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

Iteration plans

Please refer to:
https://github.com/carbon-design-system/carbon-custom-elements#iteration-plans
https://github.com/carbon-design-system/carbon-custom-elements/tree/master/plans

[jeoffw]

Looks promising. I do wonder if data binding interop could be made possible.

[asudoh]

Thank you @jeoffw for raising a question! Updated Q&A for this with a code example.

[cal-smith]

This is great 🎉 definitely agree that we want to stick as close to the standards as reasonable. Things like lit-html and mwc style components are just natural extensions of the standard.

• Consider TypeScript

In my experience the tooling benefits and refactoring guarantees are worth it, and since it's a superset of JavaScript the changeover is primarily just swapping out the compiler. It's been a great success in carbon-charts for a complex non-Angular example.

[stale]

We've marked this issue as stale because there hasn't been any activity for a couple of weeks. If there's no further activity on this issue in the next three days then we'll close it. Thanks for your contributions.

[anthumchris]

Generally speaking, how much "buy-in" does Web Components currently have from IBM and the Carbon team? Has this been discussed for a while or is it a relatively new proposal? What would it take for Web Components to gain traction?

I'm very interested in seeing Carbon provide first-class support for Web Components, as I expressed in carbon-design-system/carbon#2833. Very happy to see the Angular team already discussing this! In regards to "best practices", these resources could be helpful to align the development and avoid common mistakes:

• https://developers.google.com/web/fundamentals/web-components/best-practices
• https://www.youtube.com/watch?v=sK1ODp0nDbM

[asudoh]

@anthumchris Great to see that you jumped in this thread! Wrt Web Components discussion, it's been around at least for a few years, but in early days I saw that focusing on Web Components wouldn't be a sensible decision given the key specs were v0. Now v1 specs are implemented by all key browsers but IE/Edge and a lightweight, well-aligned-to-standards engine to stamp out template with data got its 1.0 release in Q1 this year - So good timing to re-start the discussion.

I personally saw the video (2nd link) at the time it was uploaded, and it definitely was a good one! The first link looks good, too, and I'm trying to add some key ones to the coding standard documentation.

As I mentioned in another thread, great to have more discussions/contributions! I see this is the best way for this effort to get tranctions. Also, don't forget to talk to your buddies and let them add 👍 to the issue description above!

[pulakb]

Why not Stenciljs can be used?
As per the documentation, Stencil takes features such as

• Virtual DOM
• Async rendering (inspired by React Fiber)
• Reactive data-binding
• TypeScript
• JSX

Further, since Stencil generates standards-compliant web components, they can work with many popular frameworks right out of the box.

[asudoh]

@pulakb Great question! We have had some conversations with people wrt Stencil. Given we are seeking for a possibility of Web Components serving the basis of multiple framework variants, we set "bare metal", "web standard alignment even in library choice" and "no DSL" goals described above. Stencil unfortunately seems to go against those goals. It only affects carbon-custom-elements repo with the goals described above, though, which means it doesn't prevent people to come up with Stencil version in another repo - Carbon is an open source design system.

[anthumchris]

These are some goals and ideas that could immediately help our teams, which consist of roughly 30 front-end and QA engineers spread across 3 countries & time zones. We'd like to reduce bugs and increase overall quality, consistency, and velocity:

• Performance is prioritized - best-in-class development guided by knowledgable developers and best practices. Immediately:
  • components are lightweight, fast and independent.
  • library/framework bloat is non-existent.
• Consistency, predictability, and quality assurance when used amidst other JS/CSS libraries
• Quality control - use automated testing and rendering of component states and edge cases (long text, line-wrapping, etc).
  • Rasterized images - automated, batch-processed; QA teams could scroll through images for fast visual inspection.
  • Rendered DOM - on-demand, instant refresh; Developers can instantly and automatically reproduce a component's state and inspect DOM in browser.
  • Automated code tests - linting, unit tests, etc. would facilitate required use of best practices, APIs, and programatic behaviors.
• Implementor-friendly - devs need a fast path to learn how to use and add a specific component.
  • Accessible & Dyslexic-friendly - offer brief, direct, and intuitive documentation/instructions/examples. avoid complexity.
• Future-forward - older browsers shouldn't hinder quality; encourage customers to upgrade browsers

[asudoh]

Thanks @anthumchris for sharing your priorities! The notion of thin library stack (avoiding library/framework bloat) 💯 aligns one of the goals in carbon-custom-elements project. I'm seeing QA/a11y benefits, too, by having a single library for multiple frameworks as you said, and automated tests (including a11y) is in considerations.

[abdonrd]

This is really great!

I would like to share a couple of references from @web-padawan (from @vaadin):

• https://github.com/web-padawan/lit-components
• https://github.com/web-padawan/aybolit

And open-wc project:

• https://open-wc.org