Do Web Components require a build step?

No. Custom Elements, Shadow DOM, and HTML Templates are native browser APIs usable directly with vanilla JavaScript. A build step (or a library like Lit) is optional and mainly used to improve developer ergonomics, TypeScript support, and reduce boilerplate.

Can I use React components inside a Web Component, or vice versa?

Yes, both directions are possible, though embedding a Web Component inside a React tree has historically had rough edges — particularly around passing complex props and listening to custom events — that have improved with recent React versions adding better native custom element support.

What is Shadow DOM actually isolating?

Shadow DOM isolates a component's internal DOM structure and CSS from the page's global stylesheet and from JavaScript selectors like `document.querySelector` run outside the shadow tree, preventing styles from leaking in either direction and preventing external scripts from accidentally reaching into the component's internals.

Why would I use Lit instead of raw Web Components APIs?

Writing custom elements directly with the base APIs requires a fair amount of boilerplate for reactive rendering, property/attribute syncing, and templating. Lit provides a small, reactive base class and tagged-template-literal HTML syntax that significantly reduces that boilerplate while still compiling down to standard Web Components.

Are Web Components good for building an entire application?

They're more commonly used for individual, reusable components or design systems than for structuring an entire application's routing, state management, and page composition, where framework-level tooling (routers, state libraries) typically still adds significant value.

Web

Web Components API

IntermediateProtocol3.7K learners

The Web Components API is a set of native browser standards — Custom Elements, Shadow DOM, and HTML Templates — that let developers define reusable, encapsulated HTML elements with their own styling and behavior, usable in any framework or…

#WebComponentsAPI #Web#Protocol#Intermediate#CSSCascadeLayers #CSSNesting #Subgrid #IslandsArchitecture #WebDevelopment#Glossary#SkillVeris

Definition

Overview

Web Components consist of three complementary W3C specifications. Custom Elements lets developers define a new HTML tag (e.g., `<my-widget>`) backed by a JavaScript class that hooks into lifecycle callbacks (`connectedCallback`, `disconnectedCallback`, `attributeChangedCallback`) to control the element's behavior when it's inserted, removed, or modified in the DOM. Shadow DOM provides encapsulation — a component's internal markup and styles live in a separate 'shadow tree' attached to a host element, isolated from the surrounding page's CSS and JavaScript, preventing style leakage in either direction. HTML Templates (`<template>`) let markup be defined inertly (not rendered or executed until explicitly cloned into the document), useful for stamping out repeated structure efficiently. Together, these standards let a component be authored once and used anywhere — in a React app, a Vue app, a plain HTML page, or a legacy jQuery site — because the browser itself, not a framework's runtime, understands and renders the custom element. This framework-agnosticism is Web Components' central value proposition, contrasting with framework-specific component models (React components, Vue SFCs) that only work within their own ecosystem and typically require a compiler or runtime to interpret. In practice, Web Components are commonly used for design systems and component libraries meant to be consumed across multiple frameworks or teams (e.g., a company shipping a shared button/date-picker library usable regardless of which frontend framework a given product team uses), and for embeddable third-party widgets (chat widgets, payment forms) that need strong style and script isolation from the host page. Libraries like Lit (from Google, successor to Polymer) provide a thinner, more ergonomic authoring layer on top of the raw Web Components APIs, since writing custom elements directly with the base browser APIs can be verbose. Native support for all three specs is broad across modern browsers, though ergonomics around server-side rendering and framework interop (particularly with React, historically) have been an ongoing area of friction and improvement.

Specification

Custom Elements: define new HTML tags backed by JavaScript classes with lifecycle hooks
Shadow DOM: encapsulates a component's markup and styles from the rest of the page
HTML Templates: define inert, reusable markup fragments cloned on demand
Framework-agnostic — usable in React, Vue, Angular, or plain HTML with no build step
Native browser support, no runtime library strictly required
Strong style isolation, preventing CSS leakage in either direction
Commonly paired with a thin authoring layer like Lit for better developer ergonomics
Ideal for shipping design systems or widgets across multiple frameworks/teams

Use Cases

Design systems shared across teams using different frontend frameworks

Embeddable third-party widgets (chat, payments, ads) needing style isolation

Legacy site modernization without rewriting the whole app in a JS framework

Framework-agnostic UI libraries distributed to a broad range of consumers

Micro-frontend architectures where independent teams ship isolated components

Long-lived component libraries meant to outlive any single framework's popularity cycle

Alternatives

React components · MetaVue single-file components · Vue.js core teamLit · GoogleStencil · Ionic

History

Web Components are a set of native browser standards — Custom Elements, Shadow DOM, and HTML Templates — for building reusable, encapsulated UI elements that work in any framework or none. The concept was introduced by Alex Russell at the Fronteers Conference in 2011, growing out of Google engineers' earlier discussions about DOM encapsulation. Google published a first-generation "v0" set of specifications as W3C Working Drafts in 2013 and shipped them in Chrome, but other browsers declined to follow, citing complexity. After cross-vendor negotiation — including a pivotal W3C meeting in 2015 — a simpler, slot-based "v1" design was agreed; the Custom Elements v1 specification landed in 2016 and gained support across the major browsers over the following years, making Web Components a broadly interoperable platform feature.

Sources

web.dev — "Shadow DOM v1: Self-Contained Web Components" · as of 2026-07-17
MDN Web Docs — Web Components · as of 2026-07-17

Frequently Asked Questions

From the Blog

Programming

React Hooks Explained: useState, useEffect, and Beyond

React Hooks replaced class components and changed how React developers think about state and side effects. This guide explains useState, useEffect, useContext, useRef, and custom hooks clearly, with practical examples for each.