Web Components & Three questions

I've been talking to developers about Web Components, and several questions have popped up.

  1. Where can I go to learn about Web Components?
  2. If you could name a flaw in Web Components, what would that be? ... "Isn't it very buggy?"
  3. Arent Web Components slow?

I keep hearing these three, so let's address them here.

Getting started

The main issue is that Web Components need to have the same kind of guideline documentation that frameworks/libraries have. Frameworks are products, and Web Components are a set of Web platform features that individual vendors need to implement and manage. Documentation surrounding Web Components is usually in the form of reference documentation and specifications. Writing how-to docs for web features needs to be improved, but that could be said of the many features Web Browsers offer. The threshold to get started still needs to be lowered.

Getting started is tricky as there isn't a particular go-to resource. Well, except for this curated list of articles

Here are a few worth reading, as they offer critical and practical insights.


Individual browser vendors manage their own set of bugs. So, yes, bugs get looked at, but when or if these get solved depends on many factors, some of them commercial. Still, the most crucial part is compatibility and interoperability because Web features are dead in the water without them. The recent Interop initiatives have proven very useful. I've found Web Components to be very stable in production, and most related features are viable as a cross-browser solution. Caniuse is your friend.

Most of the issues currently are about accessibility which can still be a deal-breaker for some.

But if I had to name one issue: There needs to be more tooling around Web Components integration and delivery. Modern web is at least a good option. I do write my own Node scripts. Which is fun, but I'd rather not maintain a custom toolchain.


I've always found this one curious, as using javascript to render content always makes a page slower. Part of the reason I get the question is that the stacks they use often have their perf bottlenecks. Could Web Components solve that? Maybe, maybe not. Web Components are not slower, but they have a different performance profile. Some of the poor practices in the frameworks are tied to the build tooling and have less to do with the frameworks themselves. CSS-in-JS, for example, has not aged very well. (This is me being diplomatic.) Most of the standard optimisations also apply to Web Components. Think of Bundling, minification, and preloading.

If performance is a primary factor, then utilising the Declarative Shadow DOM might be your best bet.

	<template shadowrootmode="open">
			:host {
				margin-trim: block;
				border: var(--border-size-2) solid var(--teal-4);
				border-radius: var(--radius-3);
				padding-block: 2ex;
				padding-inline: 2ch;
			h2 { color: var(--violet-5); }
			p  { color: var(--stone-7); }
		<h2>Hello, world.</h2>
			Lorem ipsum dolor sit amet consectetur adipisicing elit...

Writing Web Components templates directly in HTML is a big win for server-side rendering (SSR) as the performance pendulum swings back to the server.

Web Components are not perfect, but they are good, and they are the future.

Posted on: April 23rd, 2023

Next Post

Web Development, the back and front of it

Web Development has become front-end development, and we lost something on the way.

Previous Post

Spacing Foundation

I've started avoiding (unintentionally) margin properties in my CSS, as `gap` seems sufficient in most cases.

CSS JOY Webring