The failed promise of Web Components – Lea Verou

A spot-on summary of where we’ve ended up with web components.

Web Components had so much potential to empower HTML to do more, and make web development more accessible to non-programmers and easier for programmers.

But then…

Somewhere along the way, the space got flooded by JS frameworks aficionados, who revel in complex APIs, overengineered build processes and dependency graphs that look like the roots of a banyan tree.

Alas, that’s true. Lea wonders how this can be fixed:

I’m not sure if this is a design issue, or a documentation issue.

I worry that is a cultural issue.

Using a custom element from the directory often needs to be preceded by a ritual of npm flugelhorn, import clownshoes, build quux, all completely unapologetically because “here is my truckload of dependencies, yeah, what”.

Tagged with

Responses

2 Likes

# Liked by Aaron Parecki on Thursday, September 24th, 2020 at 6:32pm

# Liked by Zachary Dunn on Friday, September 25th, 2020 at 1:28pm

Related links

A Web Component UI library for people who love HTML | Go Make Things

I’m obviously biased, but I like the sound of what Chris is doing to create a library of HTML web components.

Tagged with

mirisuzanne/track-list: Enhance a list of audio tracks with playlist controls

This is very nice HTML web component by Miriam, progressively enhancing an ordered list of audio elements.

Tagged with

Lived experience

I hold this truth to be self-evident: the larger the abstraction layer a web developer uses on top of web standards, the shorter the shelf life of their codebase becomes, and the more they will feel the churn.

Tagged with

You can use Web Components without the shadow DOM

So what are the advantages of the Custom Elements API if you’re not going to use the Shadow DOM alongside it?

  1. Obvious Markup
  2. Instantiation is More Consistent
  3. They’re Progressive Enhancement Friendly

Tagged with

How Microsoft Edge Is Replacing React With Web Components - The New Stack

“And so what we did is we started looking at, internally, all of the places where we’re using web technology — so all of our internal web UIs — and realized that they were just really unacceptably slow.”

Why were they slow? The answer: React.

“We realized that our performance, especially on low-end machines, was really terrible — and that was because we had adopted this React framework, and we had used React in probably one of the worst ways possible.”

Tagged with

Related posts

Progressively enhancing maps

How I switched to high-resolution maps on The Session without degrading performance.

Trust

I’m trying to understand why developers would trust third-party code more than a native browser feature.

Making the Patterns Day website

The joy of getting hands-on with HTML and CSS.

Speaking at Web Day Out

Have you got the perfect talk for this event? Let me know!

Announcing Web Day Out

A one-day event all about what you can in web browsers today: Brighton, March 12th, 2026. Tickets are just £225+VAT!