A practical and future-proof solution: Web Components

Web components are custom HTML elements. They can be used like normal tags, but developers give them their own behavior and appearance. A web component consists of three parts:

1. Custom Element
2. Shadow DOM (hidden DOM tree with its own HTML structure and CSS styles)
3. HTML template

In a live coding session, Arco showed the tech teams how the interaction works. In his examples – a button, a time-specific greeting, and tab navigation – he pointed out the varying degrees of complexity. However, these elements are all defined individually and, through style encapsulation via a Shadow DOM, are given their own behavior and/or appearance, unaffected by other CSS on the page. As a result, the elements look the same and remain stable, even with a lot of CSS or conflicting CSS. Developers build them into the HTML via script.

Why do web components sometimes score higher than frameworks?

In his presentation, Arco emphasized one major advantage: by adhering to web standards – such as those of the W3C –web components are technologically very durable. Anyone developing components today can therefore expect compatibility for many years to come. However, web components have even more advantages over frameworks such as React or Vue.

The advantages at a glance

1. No runtime, smaller bundle size
   Web Components run natively in the browser without additional JS overhead

2. Direct DOM interaction
   No virtual DOM – instead, full control over the real DOM

3. More freedom, fewer specifications
   Rigid patterns are eliminated. Complexity and architecture are defined during development. (Beware of incorrect patterns!)

4. HTML-native composition model
   Server renders HTML, client activates selective interaction via custom elements

5. Framework-agnostic
   Web Components can be seamlessly integrated into React/Vue apps without configuration, ideal for cross-framework reuse

A key argument is that web components do not require their own runtime. This keeps bundles smaller and reduces the barrier to entry. Instead of bootstrapping a complete app infrastructure, individual interactive building blocks can be integrated into existing pages as custom elements. This is ideal when most of the rendering is done on the server side and only selective interaction is required. In addition, there is style encapsulation via the Shadow DOM. The components look the same everywhere, regardless of what CSS already exists on the page. This facilitates consistency across different applications and teams.

Practical examples from denkwerk

Arco and his colleagues use web components for customer projects. For example, they worked in an interdisciplinary team with experience and visual design to develop a design system. The design system uses the “Shoelace” web components library as its basis. The tech team used it to build a UI framework and adapt it to the newly designed digital branding. The result was a set of core components such as buttons, form controls, and navigation elements. These were made usable in plain HTML projects as well as in various frameworks (here: React, Vue, and Svelte).

In another major project the team worked with a CMS, i.e., classic server-side rendering. To improve the UX using simple means, the project team also used web components here—for example, in tab navigation, in the header, or in the mobile menu—as lean custom elements that handle interaction while the content continues to be rendered entirely on the server side.

Where do web components reach their limits? And where are they worthwhile?

Despite all the advantages, Arco summed up in his talk:

“Web components are not a solution for everything; they have upsides and downsides. There are always a number of different solutions, and you have to evaluate individually whether web components are suitable for a project.”

Arco Mul, Lead Software Developer at denkwerk

Developers therefore need to be flexible and critically examine their solutions. This also became clear in the subsequent discussion on the use of web components.

Topics such as

• Server-side rendering

• Form handling and

• Accessibility

are significantly more demanding with web components than in established UI frameworks. On the other hand, UI frameworks provide abstract patterns. Although there are workarounds – such as server-side rendering with Lit or libraries such as Shoelace, which already handle forms correctly – they require experience and must be integrated correctly. Integration into complex framework setups can also cause additional effort, for example with SSR or highly dynamic apps. Here, React, Vue, and others remain the better choice, especially when creating a complete single-page application with extensive state management.

Web components are particularly attractive when the following conditions are met:

• minimal but targeted interaction on pages otherwise rendered on the server side

• strict focus on performance

• need for cross-framework-compatible design systems

For companies with multiple technology stacks and heterogeneous teams, they enable a common UI foundation without forcing framework lock-in. At the same time, they act as a “reality check” in an overly fragmented front-end world: instead of loading an entire framework for small features, web components allow you to work in a deliberately minimalist way – where they fit and in combination with frameworks.