Three myths about web components

The gap between knowing this and actually doing it is where most teams lose ground. A few things about web components that get repeated more often than they get checked.

Most development decisions are really maintenance decisions wearing a different hat. If it only works because one person remembers to do something, it does not work yet.

“It only matters for big sites”

Custom elements work without committing to a framework. The cost of getting this wrong is rarely visible on the day it happens. Assume whoever inherits this will have half your context and none of your patience.

“We can deal with it after launch”

Sometimes true, usually expensive. None of that requires a large budget, only a decision and someone to own it.

“Our platform handles it”

Useful when several teams share one component set. In practice this is a scheduling problem more than a technical one. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

The short version

Code gets read far more often than it gets written, and usually by someone with less context than the author had. 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

If you want a second opinion on how yours is set up, ask.