The rise of Web Components

It is now been a while since people started to talk about Web Components. But it finally became a reality. As of the beginning of 2020, all the major browsers implement most of the specification. Moreover, the need to support some of the ancient browsers, like the older IEs, is drastically decreasing. Fortunately, there are polyfills to still support IE11 and other not too old generation. So what are web components and should you use them?

Web Components

Web Components is actually a generic term that encompasses several different specifications:

• Custom Elements Define new HTML element types (e.g. new HTML tags). They are easily identifiable from the stock HTML elements as their name must include an hyphen '-'. Support: https://caniuse.com/#feat=custom-elementsv1
• Shadow DOM Encapsulates the markup and the styles of a component. Basically, the shadow DOM isolates the implementation of your component from the rest of the page. Support: https://caniuse.com/#feat=shadowdomv1
• ES6 modules As Web Components heavily rely on JavaScript, ES6 modules define a elegant way to load JavaScript code within the browser. Support: https://caniuse.com/#feat=es6-module
• HTML template Used to define fragments of markup that are not rendered by the page, but can be reused later in particular from JavaScript. Support: https://caniuse.com/#feat=template Here is a great introduction to these specifications: https://www.webcomponents.org/introduction

Not that the idea of natively extending the HTML markup and isolating components is not new. There is prior art, like Microsoft HTC or Mozilla XUL. Web Components, instead of being vendor specific, are part of the W3C specification and work similarly on every browser following that spec.

Web components vs Frameworks

Let's put it this way: they do not compete, they rather complement each other. The Web Components specification provides native behaviors implementation, thus helping the frameworks to be simpler and lightweight. On the other hand, the frameworks make it easier to write Web Components. If you were brave enough to write a web component manually, then you know what I'm talking about. What would take a few lines of React code could lead to hundreds using the bare Web Components APIs.

The Web Components specification is an evolving one, that still has gaps to fill. But it reached a state where it provides real value in term of performance and browser compatibility.

How to write Web Components

Ok, let's forget about solely using the raw browser APIs, but let's get help from Frameworks, as they handle a lots of things for us (data binding, event handlers, ...).

Even though existing frameworks came before the Web Components specification, they all have ways to create and consume custom elements. On the other hand, they generally do not (yet?) properly handle advanced capabilities like Shadow DOM:

• React React Components are actually fairly different from Web Components. That being said, a React application can both consume custom elements and expose its components as custom elements, see: https://reactjs.org/docs/web-components.html.
• Angular Angular, if not built on top of the Web Components specification, is actually closer than React. The Angular team came with Angular Elements, which let's you package your components as custom elements.
• Vue.JS Similarly, Vue has its own library to expose custom element: @vue/web-component-wrapper. If using these well known technologies feels appealing, they come with some caveats/limitations when it is about Web Components: the component models have different life cycles, they carry more code than necessary, the features are not matching 1-1...

Fortunately a new generation of frameworks, based on top of the Web Components specification, appeared. Will they replace the legacy ones is a good question. It won't certainly happen soon, although they make it easier and more efficient when leveraging Web Components.

Part of these frameworks are:

• Lighning Web Components (LWC) This is one of the latest, but promising framework brought by Salesforce. Ok, my judgment is certainly biased because I'm a Salesforce employee, and because we are using this technology on a daily basis. But trust me, it deserves a look :-) Most of my upcoming posts going further will be around on that technology!
• Stencil.JS This technology is developed by the Ionic team, basically to fulfill their own needs. In short, the first Ionic release was Angular based and they got many requests for both a React and a Vue version. So they decided to standardize on a common Web Components implementation and then wrap them within each of these framework.
• Polymer That's one of the original frameworks brought by Google. It evolved a lot in the past 5 years, following the browser implementations, finally making it an efficient framework for writing Web Components. Finally, instead of the initial large monolithic framework, it now provides several projects like LitElement or lit-html.
• Svelte Svelte is an efficient reactive library, oriented towards performance. It brings some innovation, particularly with the drop of the virtual DOM. Its community development model is very interesting, with an impressive list of involved people.

• And many more!
  Hybrids, Slim.JS, Bosonic, Riot.JS, Smart HTML Elements... And yes, I'm missing some, in particular the ones that do not yet exist.
  Choosing one framework or the other can be matter of preferences, skills or actual framework capabilities. But we should not forget a non negligible aspect, which is the sustainability of the technology:

• Will the technology remain compatible over time?

• How will it adapt to the new standards?

• Who is behind it? Is it another open source project that will loose attention& love in a foreseeable future?

• What is the community?
  These are fair questions that we need to answer before we choose a technology for business purposes. Of course, your mileage may vary.