4 min read

Questions/Concerns I have about Web Components

I’m not sure how to feel about Web Components. This article will serve as a dumping ground for my questions and concerns about Web Components.
Questions/Concerns I have about Web Components
Photo by Green Chameleon / Unsplash

I’m not sure how to feel about Web Components. This article will serve as a dumping ground for my questions and concerns about Web Components. It was spurred on by Dave Rupert himself. Now Dave does not know me. We met once at ArtifactConf. But I have been following his infectious personality for years in his many podcast adventures. So when I get a tweet like this, I feel I have to do it! And DAMN IT DAVE, I hate writing blog posts. So here it goes — get the soapbox and start the music!


Dear Dave,

May this letter finds you well. I had a few questions about web components, and I was hoping you could help me. Right now I don’t feel the need or excitement to learn this new(er) technology. And my technology partners have questions, that I can’t answer. I just don’t know if these feelings I have are normal. Please help!

Are They Accessible?

https://images.unsplash.com/photo-1574887427561-d3d5d58c9273?ixlib=rb-1.2.1&q=85&fm=jpg&crop=entropy&cs=srgb

The accessibility of the web is an area that is of increasing importance. As the web moves forward with new technologies, such as Web Components, it is important to consider accessibility within these technologies. Since a web component is essential in creating a new custom element, how do assistive devices perceive these new elements?

At the most basic level, if web components were used the same way we abuse React or Vue abstractions, we may have a component that just themes and wraps a single <a href></a> tag. What do the assistive devices see if I was using <my-awesome-link href=“”></my-awesome-link> instead?

Even if there are paradigms to make a web component accessible, do the trade-offs become a harder decision? For example, if I make <my-awesome-link> does the code to make this accessible cost more than it’s work? Am I really just saving web components for larger component abstractions like an embedded podcast player?

It seems the trade-offs would modify when/how we reach for a component architecture. Instead of “componentize all the thing”, there would be a harder threshold to justify. For me, that sounds like the lack of adoption outside of special use cases.

JS All The Things?

I know WebKit killed the HTML import and effectively pushed web components into a JS paradigm. If I am not mistaken, the CSS, HTML, and now logic are all in JavaScript. And this is not unique across the modern web. React and Vue has pushed this for years. But it is an unsettling trend as we force more “things” into JavaScript.

I am not even concerned about the bundle size, as we move closer to native imports with a proper module pattern. What concerns me is the parse time on the JS imports. About 50% of the primary website I “own” for work has visitors from Puerto Rico or US states with poor network infrastructure. Users access from budget devices with little RAM and outdated underpowered CPUs. And most use Chrome, which isn’t device-friendly in the modern era.

https://images.unsplash.com/photo-1560209617-059c0bd661ba?ixlib=rb-1.2.1&q=85&fm=jpg&crop=entropy&cs=srgb

With Svelte we were able to re-platform off React and decrease our JS over the wire considerably. This gave us an average improvement of over 12 seconds offload for the worst areas. And our React version was a heavily optimized and well-thought-out architecture with limited bells and whistles. These devices and network speeds just drive the baseline down so low. We forget about these marginalized folks, as we use our shiny new iPhones, M1 MacBooks, and high-end Android devices. But the divide is real.

So what is the argument to place CSS in JS, and HTML in JS, when we have such impacted users? How do web components move the web forward, verse divide it further? Convince me it does not make us less inclusive today. I know things can change tomorrow, but web components are not exactly as “fresh” as they were a few years ago.

I am Sick of Tools

Every time we change the paradigm for how we build for the web, we introduce tools. They save us. Robots do more work, prevent us from making mistakes and alert us to common problems. They help us deliver the right information to the users

Well, we also have a tendency to over-index on tooling as we face a land grab with developers trying to carve a piece of the new technology. And while many are amazing. I don’t think I have put more than a few static sites in production without having to set up babel or webpack these last few years.

We are finally at a point where these tools are falling away for various reasons. Do web components push us back into “tool land”. Am I spending a week on the new project getting the repository set up just so I can ship?

Basically - how truly native are web components? What are the best practices? And how do we not take a step backward by adding complexity and additional dependencies on delivering?

Hard to Debug

I hear they are hard to debug due to the shadow dom. While browsers have gotten better tooling to represent the shadow dom, does this still hold true? Does this require additional tooling? Asking for a friend.

The Dark Path / Towards the Light

If you convince me, how do I start? Polymer, Lit Element, some non-Google framework? How do I build an accessible and inclusive web component? What convinced you to go to the dark side?

Yours Truly,

Sincerely Skeptical

PS - Nice Shed.