Skip to content
Search

Web Components Community 🔷

AK DevCraft
AK DevCraft

Posted on • Updated on • Originally published at dev.to

My firsthand experience with web component - learnings and limitations

#webcomponents #javascript #discuss

Though the concept of Web Component was first introduced more than a decade ago by Alex Russell; 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.

Even I got introduced to the web component last year while working on a new project. Since then I’m still learning, trying to explore out best practices where native web component way is available, and hacking when can’t find 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 got a global product or 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 means 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 on the older version 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 on similar lines 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 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 shadow DOM.

3. Session Recording

There are different software products available that records the user interaction with web pages so that further technical assistance could 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 web component. This could happen as web component will load asynchronously and session recording may not wait for web component to completely load.

4. Challenge in loading 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

Conclusion

So, should we not use a web component? There is no straightforward answer to it, nothing is perfect and everything comes with some grey area. But we always have to weigh the pros and cons, and ask the question, does 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:

Top comments (6)

Collapse
dannyengelman profile image
Danny Engelman •

| A shadow DOM is inaccessible from outer DOM

Strange,

  • Inheritable styles
  • CSS properties
  • ::part

all style my Web Components with shadowDOM

I probably received a special version

Collapse
akdevcraft profile image
AK DevCraft Author •

Definitely something I have to look into

Collapse
auroratide profile image
Timothy Foster •

Yep! It's not that the shadow dom is completely "inaccessible", but that the ways to penetrate its barrier are intentionally limited. Even with Javascript you can access an "open" component's shadow dom.

These entry points shape the public interface of a component and are useful for maximizing reuse and customization.

Thread Thread
akdevcraft profile image
AK DevCraft Author • • Edited on

I'm going to ask a stupid question and I guess I should have mentioned it, I was talking about Shadow DOM in closed mode, does Shadow DOM in closed mode allows accessing Shadow DOM elements from outer DOM? as my understanding is in closed mode outer DOM styling won't override/impact the Shadow DOM styling, and that's a big benefit for me in my project

const header = document.createElement('header');
const shadowRoot = header.attachShadow({mode: 'closed'});
Enter fullscreen mode Exit fullscreen mode
Thread Thread
auroratide profile image
Timothy Foster • • Edited on

The CSS encapsulation you get is the same in both "open" and "closed" modes. That is, regardless of the mode, normal light dom styling will not penetrate the shadow boundary, unless it's one of the things Danny listed above.

The only thing "closed" practically does is change what elem.shadowRoot returns: in "open" mode, shadowRoot gives you access to the element's shadow dom and its children. In "closed" mode, it just returns null.

<style>
  body { --p-color: blue; }
  p { color: red !important; }
</style>
<script>
  const header = document.createElement('header');
  const shadowRoot = header.attachShadow({mode: 'open'});

  shadowRoot.innerHTML = '<style>p { color: var(--p-color); }</style><p>Hello!</p>';

  document.body.appendChild(header);
</script>
Enter fullscreen mode Exit fullscreen mode

In this code example, the result will be "Hello" in blue. Even though the shadow root is open, the paragraph is still stylistically encapsulated, which is why it isn't red !important. It's blue, however, because CSS variables penetrate the shadow boundary.

In closed mode, it will also be blue.

Thread Thread
akdevcraft profile image
AK DevCraft Author •

Thank you! there is always learning, and why's web component intrigues me. I appreciate you took time to explain so well.

Read next

dannyengelman profile image

Platting my Web Components path

Danny Engelman -

jaredcwhite profile image

Blending Web Components Into Standard HTML Forms

Jared White -

andrico1234 profile image

The choices you'll make when creating a web component UI library

Andrico -

horuskol profile image

Making Web Components reactive

Stuart Jones -