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.
Web Components are a suite of specifications that help with implementing custom HTML elements:
<template>element is parsed without interpreting it (no loading of images etc.).
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.
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”.
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:
Andrew argues that Web Components should be:
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.
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.