What happened to Web Components?

[2015-08-29] dev, webcomponents, clientjs
(Ad, please don’t block)

Three years ago, there was a lot of excitement surrounding Web Components: everybody talked about them, the frameworks Ember and Angular planned to integrate them or even be based on them, etc.

By now, that excitement seems to have died down. This blog post examines what happened to Web Components. Spoiler: they are alive and well and slowly being adopted across browsers.

Refresher: Web Components  

Web Components are a suite of specifications that help with implementing custom HTML elements:

  • Custom elements: an API for registering your own implementations for HTML elements.
  • Shadow DOM: Encapsulates and hides the innards of a custom element inside a nested document. The most important part of Web Components and hardest to polyfill.
  • Templates: enable you to store HTML data inside an HTML document. The content of a <template> element is parsed without interpreting it (no loading of images etc.).
  • HTML Imports: let you import other HTML documents into the current one. That way, HTML documents become bundles of HTML, CSS and JavaScript. You need such bundles to distribute custom elements and all of their dependencies.

For more information on how Web Components work, you can read the introduction “Bringing componentization to the web: An overview of Web Components” by Travis Leithead and Arron Eicholz.

Recent developments  

For a long time, it was mainly Google (and, to some degree, Mozilla) that pushed Web Components. In recent months, other parties became more involved. There were two face-to-face meetings on 2015-04-24 and on 2015-07-21 that were attended by employees from Mozilla, Microsoft, Google, Apple and others. During those meetings, two Web Component specifications moved closer to a cross-browser consensus:

  • Shadow DOM: There is now broad agreement on how to standardize the Shadow DOM, which is great, because, as mentioned before, it is the spec that is most difficult to polyfill.

  • Custom elements: Everyone agrees that custom elements are important, but getting the details right is difficult, especially when to activate a custom implementation – while creating the custom element in the DOM or later.

What about the other two specifications?

  • HTML Imports are still controversial, because there is much overlap with ES6 module loading. Especially Mozilla and Microsoft argue that further work on HTML Imports should wait until ES6 module loading is finished.

  • Templates are not a very complex feature and already broadly supported. The status for Microsoft Edge is: “in development”.

More information:

Web Components versus React  

When Sebastian Markbage (one of React’s creators) was asked about Web Components, he answered:

We’re not going to use it at all at Facebook. We’re not going to build React on it because there’s a strong model difference – imperative in Web Components to declarative in React. Web Components doesn’t have an idiomatic way to define things like where events go. How do you pass data when everything is a string? We see it more as an interop layer that lets various frameworks talk to each other.

In talking to the Atom team, this doesn’t solve different framework idioms as it doesn’t have an opinion on how they relate.

This sounds like React and Web Components are at odds with each other. However, in the talk “The complementarity of React and Web Components”, Andrew Rota disagrees:

  • Web Components can be used as leaves in the tree of React Components, just like native DOM elements.

  • React is getting better at supporting Web Components:

    • Custom elements already work (elements with lowercase names are interpreted as DOM, replacing a whitelist of names).
    • Support for custom attributes and custom events is work in progress.

  • Andrew argues that Web Components should be:

    • Small: atomic, not compound. React and other frameworks can be used to assemble Web Components.
    • Completely encapsulated: For example, a Web Component should not put script tags into the surrounding document.
    • As stateless as possible: avoid internal state, use events to communicate changes.

    These rules for designing Web Components help React, but they make sense in general.

  • Using React inside a Web Component makes less sense, it goes against Web Components being as minimal as possible.

Further information  

The Web Platform Podcast episode 54 (2015-07-28) asks a panel of experts: “Are Web Components Ready Yet?” (80min video). Watch that video to get more information and context on Web Components.

Mentioned in the podcast, the work of the CSS Houdini Group will help with implementing Web Components in the future:

The objective of the CSS-TAG [Technical Architecture Group] Houdini Task Force (CSS Houdini) is to jointly develop features that explain the “magic” of Styling and Layout on the web.

Styling and layouting are currently mostly black boxes. The Houdini Group plans to expose the internals of those boxes and to let you customize what is going on there.