Web components: what to get right first

The advice here is unglamorous, which is probably why it gets skipped. If you only fix one thing about web components this quarter, make it the first item below.

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.

Start here

Custom elements work without committing to a framework. The cost of getting this wrong is rarely visible on the day it happens. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Then this

Encapsulation stops styles leaking between features. Getting it slightly wrong is survivable. Ignoring it entirely is not. Assume whoever inherits this will have half your context and none of your patience.

Eventually

Useful when several teams share one component set. Where this goes wrong is almost never a lack of knowledge. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

What this looks like day to day

The question is rarely whether something can be built, but what it costs to keep running afterwards. Three things worth confirming about web components before you move on:

• Someone can say what the current setup is without going to look
• Custom elements work without committing to a framework — and you know whether that is true here
• There is a way to tell whether the last change to this helped

The point is not perfection, it is knowing which of these you have consciously chosen to skip.