Web Components in Production: Learnings, Limitations, and Real-World Challenges

Introduction

Web Component promise reusability and encapsulation, but in real-world projects, they come with unexpected challenges.

The concept of Web Component was first introduced more than a decade ago by Alex Russell; however, browsers took time to provide support for web components, and initial implementation didn’t come until 2016 from Chrome, 2018 from Firefox, and 2020 from Edge.

While working on a production system, I ran into several issues that aren’t obvious from the documentation. Since then, I’m learning, trying to explore the best practices where the native web component way is available, and hacking when I can’t find a native implementation.

Here are some pain areas when you work with the web component.

1. Inadequate Browser Support

Even though the web component is now supported on all major browsers on their latest version, that doesn’t really help when you have a global product or a global customer base. And definitely, there will be customers in various age ranges and going to use a wide variety of browsers and versions.

What does it mean when I say no support? It means that the UI element doesn’t render on screen. You won’t see anything on its placement, e.g., if you have a footer coming from a web component, you won’t see the footer at all.

Any workaround? Polyfill is promising and could extend support to older versions of browsers.

Major browser support version without Polyfill

Browser	Version Support
Chrome	68 and above
Firefox	62 and above
Safari	12 and above

2. Shadow DOM

Sometimes strength goes against you; something similar happens with the web component. Shadow DOM in closed mode provides the powerful property of encapsulation (limits the access to Shadow DOM and its child elements); however, if you’re developing a component to replace an existing legacy component, then you’re most likely going to break the automation test. A shadow DOM in closed mode is inaccessible (unless you expose an interface to access it) from the light DOM, but again, you can use a testing library that provides support for Shadow DOM, like Cypress, to write an automation test, as it provides an interface to access the shadow DOM.

3. Session Recording

There are different software products available that record the user interaction with web pages so that further technical assistance can be provided. However, with the web component, there is a high chance that session recording software may not be able to capture the web component's HTML elements, or in other words, the UI part of the web component. This could happen as the web component will load asynchronously, and session recording may not wait for the web component to completely load.

4. Challenge in loading the external font

I have already written a comprehensive post about it, so I’m not going to copy and paste it here (I’m a bit lazy😀). Here is the link Load external font with web component

Final Thoughts

So, should we not use a web component? There is no straightforward answer to it; nothing is perfect, and everything in software engineering is a trade-off. But we always have to weigh the pros and cons, and ask the question, does a web component solve that problem, considering its limitations?

If you have reached here, then I did a satisfactory effort to keep you reading. Please be kind to leave any comments or ask for any corrections. Happy Learning!

Other Blogs:

• Integrate Web Component/MFE with plain static HTML
• Load an external font with a web component
• How to set up pre-hook for an NPM project
• GitHub Repository Readme Template

Comments

[Danny Engelman]

| A shadow DOM is inaccessible from outer DOM

So you haven't learned yet about:

• Inheritable styles
• CSS properties
• ::part

[AK DevCraft]

I guess I should have mentioned it, does Shadow DOM in closed mode still allows accessing its elements from outer DOM?

const header = document.createElement('header');
const shadowRoot = header.attachShadow({mode: 'closed'});

[Danny Engelman]

it is "closed", not "close"

And all it does is prevent access to .shadowRoot, and that is all it does.

Nothing stops you (the WC Author) from exposing your component to the outside world.

[AK DevCraft]

This is really awesome, I didn't find an example this like. My requirement was to expose certain HTML element inside the web component, that now I can easily expose as a simple function. Going back to your example, I can add a function like below

getButtonEle(){
              return this.root.children[1];
          }

Thank you!

[AK DevCraft]

Nope, but going check it out. Thank you!