A short guide to web components

We end up explaining this on discovery calls often enough that it deserved writing down. Everything we would tell a client about web components in the time it takes to drink a coffee.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

What it costs to ignore

Custom elements work without committing to a framework. The cost of getting this wrong is rarely visible on the day it happens. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

Where to start

Encapsulation stops styles leaking between features. Getting it slightly wrong is survivable. Ignoring it entirely is not. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

Where it usually goes wrong

Useful when several teams share one component set. In practice this is a scheduling problem more than a technical one. Write the reasoning down alongside the decision, because the reasoning is what changes first.

What this looks like day to day

Most development decisions are really maintenance decisions wearing a different hat. Three things worth confirming about web components before you move on:

• Someone can say what the current setup is without going to look
• Useful when several teams share one component set — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Most of the value here comes from doing the first two things, not all of them.