Web Components have been around for some years now. This article recapitulates what this term stands for and provides an overview of the current trends.
The Frontend World Gravitating towards Components
Component-based frontend development has been established for several years now. And with good reason: Building User Interfaces composed of reusable UI building blocks—the components—helps to scale complexity, accelerates development and leads to higher-quality web applications.
Fortunately there is another approach to develop components except betting on a specific framework: It’s called the Web Components standard.
The Web Components Standard in a Nutshell
The Web Components standard combines a set of standardised web APIs allowing to create custom, reusable and encapsulated HTML Elements.
The Web Components standard consists of the four following web specifications.
- Custom Elements
The Custom Elements API, incorporated into the HTML standard, allows you to define new HTML tags with associated templates, styling and logic. A Custom Element can then be used in the same way as a standard HTML Element, for example a button.
- Shadow DOM
The Shadow DOM API belongs to the DOM standard and offers a way to hide internal implementation details of a component by creating a scoped DOM subtree. As a result, the component’s DOM as well as its styling remain self-contained and isolated from the embedding code.
- HTML Templates
- ES Modules
The concept behind Web Components has been around for years, with attempts dating back to 1998. A detailed overview of the history of Web Components can be found in this blog post by Johannes Reuter and Patrick Hillert. Alex Russell introduced Web Components for the first time at the Fronteers Conference in 2011.
Although the official standardisation process of some APIs is still in progress, Web Components are already natively supported in modern browsers and run on nearly all mobile devices and desktop browsers. For browsers that don’t natively support all APIs yet, polyfills are available to fill in the gaps in the meantime. Have a look at the image below. It shows the latest browser support for Web Components involving the current version (v1) of Custom Elements and Shadow DOM, HTML Templates and ES Modules.
How to Build Web Components
There are several ways to build a Web Component. Of course Web Components can be made using plain CSS, HTML and JS, but there are also many libraries that make building Web Components easier. These libraries reduce complexity by handling data bindings and event listeners for you. Many libraries also offer additional lifecycle methods to give you more control over your Web Components. In the following you can get a brief overview of the most popular libraries for building Web Components.
- lit-html & litElement
Stencil, developed by the Ionic Team, is a compiler that generates Web Components and progressive web apps. Stencil integrates popular concepts of known frontend frameworks, for example TypeScript, JSX, a small virtual DOM layer, efficient one-way data binding, an asynchronous rendering pipeline inspired by React Fiber and lazy loading. Polyfills for browsers are also automatically managed by Stencil. Furthermore, Stencil provides the possibility to group components into so-called collections that can be loaded together to improve performance. Due to Stencil’s ongoing framework integration support, the components can be compiled to various output targets and therefore integrated more easily into modern frameworks such as Angular, React, Vue and Ember. Today, Stencil is commonly used to power Design Systems and cross-framework components at Adidas, Amazon, Porsche and Microsoft.
- Angular Elements
As part of Google’s Custom Elements & Ivy Rendering Engine project, the Angular Team is working on the so-called Angular components. These components are packaged as Custom Elements and contain a minimal version of the Angular framework to remain self-contained. The light version of the Angular framework is injected as a service to support the component’s change-detection and data-binding functionality, which is mapped to the corresponding native HTML equivalents during the transformation. This way, Angular Elements can be used outside of the Angular context and integrated into another technology stack. As an alternative to pure Web Components this approach might provide a good middle ground for teams that have existing Angular component systems and teams that want to consume the components outside of the Angular framework.
Ready-to-use Web Components
Besides libraries that help you develop your own Web Components, there are numerous libraries offering ready-to-use Web Components that you can either use off the shelf or as a foundation for your own Web Components. You can find some of these libraries below.
- Material Web Components
This library is built by Google, also as part of the Polymer project, on top of the Material Components Web (MDC Web) project and LitElement. It contains Web Components following Google’s Material Design guidelines. These Material Web Components are still a work in progress, but can already be incorporated into a wide range of usage contexts.
- Polymer Elements
The Polymer Elements supply a set of over 100 ready-to-use Polymer components implemented using the Polymer library and partly based on Google’s Material Design as well. This includes UI elements, the so-called paper-elements, and iron-elements, which represent basic building blocks for creating an application, for instance core behaviours such as scrolling and key bindings for accessibility, among others.
- Vaadin Components
Vaadin components is an evolving set of UI Web Components commonly needed in modern mobile and desktop business web applications. They currently provide 27 components for free use and 7 more as part of the Vaadin Pro Subscription.
- Wired Elements
This library contains a set of common UI elements that appear hand-drawn and sketch-y, implemented as Web Components. The elements are drawn with a bit of randomness, so that two components of the same kind will never look exactly the same.
Web Components and Design Systems
The idea of building a design spec or library of reusable components that can be shared across the team or company became more and more popular in the past years. Such Design Systems enforcing style and branding guidelines are being embraced by an increasing number of companies. One huge advantage is that the component engineering itself can be centered to one single set of components and a team that develops, maintains and shares these components with the other teams.
Building a Design System in a specific frontend framework leads to the same problem again, that all teams have to commit to the same specific tech stack. This might not be convenient for most enterprises.
This is exactly what we are doing in the inovex elements project. A small project team of collaborating designers and web developers built a Design System containing fundamental UI components based on the Material Web Components, which are consumed by other project teams building company internal workflow tools with any kind of technology stack, for example React. As a result, all applications automatically follow the inovex corporate design and changes only have to be made in one place.
Of course there are emerging tools to support the development of Design Systems, amongst them are Components Explorer, which constitute a separate application showcasing all the components in various scenarios and illustrating possible styles, behaviours and inputs to the components. Storybook for example provides such a sandbox to build UI components in isolation, to document use cases as stories and to test rare edge cases.
For the inovex Web Component library we are using Stencil to develop the components and Storybook to showcase them and provide a rich description of the public component API.
Web Components and Micro Frontends
The term Micro Frontend, which came up at the end of 2016, stands for extending the concepts known from Micro Services to the frontend. This means instead of building monolithic frontends, developing a web app as a composition of features owned by independent teams. These isolated and independent Micro Frontends are later put together—during build or runtime or via server-side rendering—to assemble the final website.
In general there is one Micro Frontend for each page in the application, but pages can also contain parts of other Micro Frontends. Usually there is one single container application which renders common page elements such as header and footer. It also addresses concerns like authentication and navigation, brings all the Micro Frontends together onto the page and tells each Micro Frontend when and where to render itself.
This approach leads to a more cohesive and maintainable codebase, scalable organisations with autonomous teams and the ability to update parts of the frontend in a more incremental fashion.
There are several integration approaches for the realization of Micro Frontends, e.g. multiple URL-based Single Page Applications or Framework Components. But again, the technology independence of the decoupled teams and the autonomy of the separate features play a major role in this context. Therefore native browser features ought to be favored over custom APIs.
Although pure Web Components might appear rather low level compared to making use of a framework, the native concept is very convenient for the realization of Micro Frontends. Custom Elements can hide internal implementation details while providing a neutral interface for the other teams. The DOM specification of a Custom Element – tag-name, attributes and events – act as a contract or public API for other teams, which can use all the components without having to know the internal implementation. Shadow DOM on the other hand offers style isolation to prevent styles of different Micro Frontends to interfere. Communication within the frontend can happen via custom events, whereby each team selects a special prefix. For the components integration ES Modules can be used.
Self-contained framework Web Components, that bring their own web framework as minimal self-contained version, such as the previously introduced Angular Elements, constitute a further alternative to realize Micro Frontends, by the way. This approach is also technology independant, but eventually might have a bad loading time in the client if every team chooses a different framework.
The framework agnostic Web Components standard represents an alternative to framework specific solutions. Consisting of four standardized web APIs – Custom Elements, Shadow DOM, HTML Templates and ES Modules – Web components can be used to extend HTML and leverage native browser features without any technology Lock-In.
There is also a hybrid approach to develop Web Components as self-contained framework components, which include a minimal version of their own web framework, for instance the Angular Elements.
Furthermore, multiple libraries exist offering ready-to-use Web Components for you to either use off the shelf or as a base for your own Web Components, e.g. Material Web Components, Polymer Elements, Vaadin Components, Wired Elements, Elix, time elements and UI5 Web Components.
For building a Design System, component libraries based on Web Components that can be shared across teams with different technology stacks appear to be very suitable.
Moreover, Web Components turn out to be a good option for the realization of Micro Frontends as well, because they favor native browser features over custom APIs and thereby improve interoperability.
With all this in mind, go ahead and use Web Components and utilize the browser as your platform!
- The official Web Components Website webcomponents.org provides a first entry point and aggregates a brief overview and further links to the specifications, libraries and community posts.
- The W3C’s GitHub Repository contains the actual Web Components specifications, links to superior standards and Issue Trackers for the parts still in progress.
- Google Developers’ Web Fundamentals provide a comprehensive introduction to Custom Elements and Shadow DOM with exemplary code examples and best practices.
- This article about how to build Web Components with Polymer by Johannes Reuter and Patrick Hillert contains a good overview of the early history of Web Components from 1998 until 2011.
- The so-called Gold Standard Checklist for Web Components enumerates several criteria to consider in order to ensure a certain quality of Web Components. Although it wasn’t updated since 2017, most listed criteria remain applicable.
- This article by itemis contrasts different approaches for the realization of Micro Frontends – some including Web Components – and evaluates them.