The Web Component Gap
Lea Verou’s recent critique of Web Components strikes a nerve, and not just for developers who avoid JavaScript. Even those who write JS professionally find the barrier to entry daunting. Browsing webcomponents.org reveals a landscape where using a custom element often demands a ritual of package installation, import gymnastics, and build configuration—all with dependencies presented as unavoidable. Many steps go undocumented, likely because they are deemed “obvious.”
There is a counterargument I’ve heard before: Web Components were never meant to be consumed directly. When I previously wrote about Web Component libraries, a reader corrected me, saying the intent was to provide primitives that libraries build upon, so they could ship less code. Libraries were always part of the plan.
That plan, however, has a history. HTML imports were killed years ago—long a pet peeve of Dave’s—leaving an all-JavaScript-or-bust approach in their wake. The result feels closer to bust than boon.
What Web Components Still Do Well
Despite the friction, I remain optimistic. Web Components can do things that are genuinely unique to them, largely thanks to the Shadow DOM. Years ago, Twitter experimented with turning embedded Tweets into Web Components instead of iframes, because it was faster across the board. That never shipped, but it was a solid idea then and remains one now.
The Styling Wall
The styling story is a major sticking point. I would reach for Web Components more often if styling them weren’t so awkward. The friction is real: when Scott asked about it recently, 75% of respondents wished they could reach into the Shadow DOM and style it with plain CSS. I understand the need for encapsulation—that is the Shadow DOM’s core purpose—but requiring an explicit, deliberate penetration mechanism should offer sufficient protection without making the common case painful.
