Web Components Standards for Modern Development
Web components standards provide native browser APIs for building reusable, encapsulated UI elements without framework dependencies. Therefore, components built with these standards work across React, Vue, Angular, or vanilla JavaScript projects. As a result, this guide covers custom elements, Shadow DOM, templates, and slot-based composition patterns, along with the production realities — form participation, accessibility, server-side rendering, and the framework quirks that catch teams off guard.
The appeal is durability. Frameworks rise and fall, but a custom element you ship today still works in browsers a decade from now because it rides on the platform itself. Consequently, design systems and large organizations increasingly publish their shared widgets as web components and let each product team consume them from whatever stack they prefer.
Custom Elements and Lifecycle
Custom elements allow you to define new HTML tags with associated JavaScript behavior. Moreover, the browser manages their lifecycle through well-defined callback methods. Specifically, connectedCallback fires when the element is added to the DOM, while disconnectedCallback handles cleanup when removed.
The naming convention requires a hyphen in the tag name to avoid conflicts with future HTML elements. Furthermore, extending HTMLElement gives your component access to all standard DOM APIs. Consequently, custom elements integrate seamlessly with existing HTML without special transpilation or build steps.
One detail beginners miss is timing. The connectedCallback can fire before the element’s child markup has been parsed, so reading this.children there is unreliable for elements written directly in HTML. In addition, the same element can be connected and disconnected multiple times if it moves around the DOM, which means connectedCallback must be idempotent — set up listeners once, and tear them down in disconnectedCallback to avoid leaks:
class ToggleButton extends HTMLElement {
#onClick = () => this.toggleAttribute('pressed');
connectedCallback() {
// Guard so repeated connections don't double-bind
if (this.#bound) return;
this.#bound = true;
this.addEventListener('click', this.#onClick);
this.setAttribute('role', 'button');
this.tabIndex = 0;
}
disconnectedCallback() {
this.removeEventListener('click', this.#onClick);
this.#bound = false;
}
#bound = false;
}
customElements.define('toggle-button', ToggleButton);
Custom element lifecycle in modern browser environments
Web Components Standards Shadow DOM Encapsulation
Shadow DOM creates an isolated DOM subtree attached to your component. Additionally, styles defined inside the shadow root do not leak out to the parent document. In contrast to CSS modules or BEM naming conventions, Shadow DOM provides true style isolation enforced by the browser itself.
class DataCard extends HTMLElement {
constructor() {
super();
this.attachShadow({ mode: 'open' });
}
connectedCallback() {
const title = this.getAttribute('card-title') || 'Default Title';
this.shadowRoot.innerHTML = `
<style>
:host {
display: block;
border: 1px solid #e2e8f0;
border-radius: 8px;
overflow: hidden;
font-family: system-ui, sans-serif;
}
:host([variant="featured"]) {
border-color: #3b82f6;
box-shadow: 0 4px 12px rgba(59, 130, 246, 0.15);
}
.header {
padding: 16px;
background: #f8fafc;
border-bottom: 1px solid #e2e8f0;
}
.header h3 { margin: 0; font-size: 1.125rem; }
.body { padding: 16px; }
::slotted(p) { margin: 0 0 8px; }
.footer { padding: 12px 16px; background: #f1f5f9; }
</style>
<div class="header">
<h3>${title}</h3>
</div>
<div class="body">
<slot></slot>
</div>
<div class="footer">
<slot name="actions"></slot>
</div>
`;
}
static get observedAttributes() {
return ['card-title', 'variant'];
}
attributeChangedCallback(name, oldVal, newVal) {
if (oldVal !== newVal) this.connectedCallback();
}
}
customElements.define('data-card', DataCard);
This component uses Shadow DOM for style isolation and slots for content projection. Therefore, consumers compose the card with arbitrary content while the component controls its visual structure. Note that styling crosses the boundary in only two sanctioned ways: ::slotted() for projected light-DOM nodes, and CSS custom properties, which pierce the shadow root by design. A robust component exposes a handful of --card-padding-style variables so theming stays possible without breaking encapsulation.
One performance caveat is worth calling out. Rebuilding shadowRoot.innerHTML on every attribute change, as the example does for brevity, discards and recreates the entire subtree — fine for a card, wasteful for a component that updates frequently. In production, parse the template once in the constructor and update only the specific text nodes or attributes that changed. Additionally, prefer adoptable stylesheets via document.adoptedStyleSheets and a shared CSSStyleSheet instance, because the browser can then share one parsed sheet across thousands of instances instead of re-parsing inline styles for each one.
Templates, Slots, and Form Participation
The template element holds markup that is not rendered until cloned and inserted into the DOM. Moreover, templates combined with slots enable powerful composition patterns similar to React’s children prop. For example, named slots allow precise placement of consumer content into specific regions of the component layout.
Template cloning is more performant than innerHTML for repeated instantiation. Furthermore, the browser parses the template once and creates lightweight document fragments for each clone operation. As a result, rendering lists of web components performs comparably to virtual DOM frameworks.
A frequently overlooked capability is form participation. A custom input built as a shadow-DOM element is invisible to a surrounding <form> unless you opt into the form-associated API. With formAssociated and the ElementInternals object, your component can set its own value, validity, and labels so it submits and validates like a native field:
class RatingInput extends HTMLElement {
static formAssociated = true;
#internals = this.attachInternals();
set value(v) {
this.#internals.setFormValue(v);
if (!v) {
this.#internals.setValidity({ valueMissing: true }, 'Pick a rating');
} else {
this.#internals.setValidity({});
}
}
}
customElements.define('rating-input', RatingInput);
Template and slot composition for reusable web components
Cross-Framework Integration
Web components work natively in any JavaScript environment. However, some frameworks require property binding adapters for complex data passing. Additionally, React’s synthetic event system historically needed explicit event listener registration for custom events dispatched from web components, although React 19 finally added first-class support for passing properties and listening to custom events directly in JSX.
Vue and Angular handle web components with minimal configuration. Meanwhile, libraries like Lit provide a thin layer over native APIs that improves the developer experience without sacrificing framework interoperability. Consequently, organizations with multiple frontend stacks benefit most from shared web component libraries.
The remaining sharp edge is server-side rendering. Because Shadow DOM is constructed in JavaScript, a custom element renders empty on the server and only fills in after hydration, which hurts first paint and SEO. The emerging answer is Declarative Shadow DOM — a <template shadowrootmode="open"> element the browser attaches at parse time — which lets you stream shadow content in the initial HTML. The trade-off is added markup complexity, so reserve it for components that genuinely need to be visible before scripts run.
Web components working across different JavaScript frameworks
When NOT to Reach for Web Components
Native components are not always the right call. For a single application built entirely in one framework, your framework’s own components offer better ergonomics, richer tooling, and tighter type safety than the imperative custom-element API. Moreover, complex reactive state, computed values, and fine-grained rendering are areas where the platform still lags behind React or Svelte, which is precisely why most teams pair web components with a helper like Lit rather than writing raw HTMLElement subclasses by hand. Accessibility also demands extra diligence: focus management and ARIA relationships do not cross shadow boundaries automatically, so a naive component can quietly become unusable with a screen reader. In short, choose them for durable, cross-framework design systems — not as a default replacement for your application framework.
Related Reading:
Further Resources:
In conclusion, web components standards deliver true framework-agnostic reusability backed by native browser support. Therefore, adopt custom elements with Shadow DOM for shared component libraries that work across any project — mind the lifecycle, expose CSS custom properties for theming, opt into form participation when needed, and reach for Declarative Shadow DOM where server rendering matters.