Web Components 2019

Web Components: Recap and Latest Trends [State of the Web]

20 ​​min

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.

Although UI components have been around for some time, a purely components-based web development approach only became mainstream after React.js was released in 2013. A couple of years later the Angular team also shifted towards encapsulated components, completely rewrote their Angular.js framework, and launched the componentized Angular 2 in 2016. Furthermore the popular JavaScript framework Vue.js, officially released in 2014, is based on layered components as well.

JavaScript frameworks gravitating towards components

All these JavaScript frameworks offering helpful features to build component-based frontends have one significant drawback in common: the technology Lock-In. Once committed to a specific tech stack, the switch to another technology or even upgrades within the same framework can cause a lot of effort. This especially applies in the web development context as web technologies evolve very rapidly and new frameworks pop up frequently and outdate existing ones. What made sense a few years ago may end up being the wrong solution after all.

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.

Instead of relying on a specific JavaScript framework, pure Web Components leverage the technology natively provided by the browser. This makes a big difference since these native components can be distributed as simple HTML tags and used by any web developer regardless of any framework or library built on top of it.

The Web Components standard consists of the four following web specifications.

The Web Components standard containing four 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

    The HTML template element is part of the HTML standard and gives you the possibility to declare HTML fragments that can be cloned and inserted into the document by means of JavaScript during runtime. Templates present an ideal placeholder for declaring the structure of a Custom Element.

  • ES Modules

    ES Modules are rooted in the ECMAScript standard and also referred to as JS Modules. With their help JavaScript documents can be reused by means of modular inclusion. Besides the possibility to import entire JS documents, single functions, objects and primitives exported by an external JS module can be included individually. Therefore ES Modules give you the opportunity to reuse components in a modular fashion.

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.

Current browser support of Web Components

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.

  • Polymer

    The Polymer library is probably the most famous one. It is Polymer’s original open-source library for building web applications using Web Components. The library is part of Google’s Polymer Project, which aggregates open-source libraries and tools with the ambition to help developers to build a better web. The Polymer library was announced in 2013 and enhanced by Google and further contributors on GitHub since then. Polymer probably had its popularity peak when the Polymer Summits took place in 2015, 2016 and 2017 and when Polymer was represented at the Google I/O in 2016, 2017 and 2018. The Polymer library is used in production by a number of websites, for instance YouTube and Google Earth among others. While trying to be interoperable with other JavaScript libraries, some difficulties might still arise in a programmer’s real life. Pascal Fecht described fundamental problems with the interplay of an earlier version of Polymer and Angular in a former blog article and also proposed solutions for these problems in a subsequent blog post. Meanwhile the Polymer library is not the library of choice anymore. Instead, Polymer recommends to use its litElement and lit-html for newer projects.

  • lit-html & litElement

    lit-html was officially introduced at Google I/O in 2018 and claims to be an efficient, expressive, and extensible HTML templating library for JavaScript. Plain JavaScript string literals allowing embedded expressions, so-called template literals, are used to create dynamic templates. In addition, lit-html only ever updates the changed parts of a template, unlike Virtual DOM libraries that have to re-render the entire view. This makes lit-html very efficient and fast. In general the library can be used standalone as well as combined with another framework or component model, not only Web Components. LitElement represents a simple base class for creating fast and lightweight Web Components. It uses the lit-html templating library and adds some APIs to declare reactive properties and attributes. According to the Polymer roadmap, lit-html and LitElement together with the PWA starter kit, represent the future direction of the Polymer project.

  • Stencil

    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.

Even more libraries and frameworks based on Web Components have emerged over time, for example SvelteJS, Hybrids, Sigil, Slim.js and SkateJS.

Libraries based on Web Components

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.

There are even more Web Component libraries, for instance Elix, time elements and UI5 Web Components.

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.

Web Components can be a great solution in this case, too. Companies that use different JavaScript frameworks across different projects, but still would like to achieve consistency in the look and feel of all their web applications, can implement a Design System based on Web Components. Such a Web Component library can be consumed across any technology stack their teams choose to use. At the same time it is more stable and less dependent on eventual changes in the residual frontend ecosystem.

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.

The interactive Storybook interface showcasing the inovex elements
The interactive Storybook interface showcasing the inovex elements

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 trend towards component-driven frontend development leads to a better development process and richer web applications. Most popular client-side JavaScript frameworks, such as React, Angular and Vue, already use a component-based approach. But all frameworks face the drawback of being dependent on a specific technology stack. In the frontend world this has a significant impact, since web technologies evolve at high speed.

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.

Web Components can be build either using plain CSS, HTML and JS or supported by one of the many libraries trying to make building Web Components easier, for example Polymer, lit-html & litElement or Stencil. While some developers may argue that there remains a feature tradeoff when abandoning traditional JavaScript frameworks, with such Web Component tools developers definitely don’t have to forgo many features.

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.

Overall it can be said that even if the interplay of Web Components with other JavaScript frameworks might still be challenging in some edge cases, a lot of progress regarding Web Components has been made. Native browser support greatly improved in recent years and with polyfills filling in the gaps a complete coverage can be guaranteed for all modern browsers. Numerous tools and libraries based on Web Components or supporting their development and maintenance have emerged and known web applications are implemented using the Web Components standard.

With all this in mind, go ahead and use Web Components and utilize the browser as your platform!

Further Resources

  • 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.

Read on

Find out more about our web services or consider joining us as a web dev yourself!

Hat dir der Beitrag gefallen?

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Ähnliche Artikel