Sebastian Prein
Senior Frontend Engineer
Feb 15, 2018 5 min read

Can I Use Webcomponents in Production?

Experiences from a developers point of view.

Hi there, I am Sebastian and I work as an Interaction Engineer @gridonic in Zurich, Switzerland. I used WebComponents over the last couple of months during the realization of a large customer platform. Here is how I experienced it.

From the very beginning, it was clear to all of us, that we are going to implement some kind of large ecosystem of different applications and portals. There was literally no way around a styleguide as we needed some kind of jar that could accomodate the massive amount of components we had to build. As the project went on, one specific requirement kept popping up. Some of the components needed to be so agnostic and independent, that you can easily drop-and-forget-about-them in any website or application we wanted to.

We wanted to go cutting-edge. So WebComponents it was.

But wait, aren’t we going to run into some dead end which we would regret later on?

Aren’t we going to have massive problems and drawbacks if we used this kind of technology?

Is this really ready for production?

Oh, oh… maybe this is indeed not a really good idea?
This doesn’t look promising — at all.
Maybe iframes are not such a bad idea after all?

So basically we had Chrome and Safari who got our backs pretty good. It was just the rest of them which were lagging behind — kind of. “Well never mind!” — I thought, we have polyfills to the rescue don’t we?

So as I started “web-componentizing” one of our main components, things got — let’s say— interesting.

7 Pitfalls I encountered using WebComponents

1. ES6 or ES5 or ES6?

I wrote ES6 code and transpiled it to ES5 in order to keep maximum browser compatibility. But it turned out that browsers who natively support custom elements, expects them to be written in ES6 classes. So what to do?

There is an adapter for that called custom-elements-es5-adapter.js which in fact is written in ES6. Hilarious! So I had to use the snippet below, that will only enable the adapter, if the browser really needs it.

2. ShadowRoot is not your friend in IE11

Since our component grew pretty quickly and had quite a few DOM nodes, I used to do event delegation on the shadowRoot. It turned out that click events simply do not reach the shadowRoot in IE11 for whatever reason.

Possibly a bug in the Shadow DOM polyfill? I ended up using a container element right below the shadowRoot.

3. Click event inconsistencies on host

Listening to click events on the custom element itself (host) was also a little painful as it gave us an inconsistent event object among browsers, which made it hard to create consistent code as I couldn’t properly rely on basic functions that I wanted to use.

Solution to that: The same container element I described above.

4. When darkness becomes light out of nowhere

One of the biggest pitfalls was that the Shadow DOM polyfill actually works in the Light DOM. Maybe this doesn’t surprise you at all but I didn’t pay much attention to this fact and got surprised once I tested our custom element for example in Firefox. This is something I should have been aware of from the beginning.

5. Web fonts don’t like Shadow DOM

This one is super spectacular as there is an open bug report¹ from 2014(!) which states that @font-face inside Shadow DOM styles doesn’t work². To our surprise this is still true. So what did I do? Check out the next point.

6. HTML Imports Quirks

Regarding the @font-face problem I thought: Why don’t I put a style tag with our @font-face rule in it but outside of our Shadow DOM while it’s still in our imported webcomponent html file?

Well, this is not going to happen as it is deprecated nowadays to do so.Âł The only way around it is to use the snippet to the left that should run inside the same import, which will hoist the stylesheet to the master document, in case the master document cannot be modified.

Apart from that HTML imports is kind of the black sheep among all other WebComponents specifications and things do not look good for it. You should just keep that in mind if you are going to use it.

7. CSS rules invalidation

This is rather a minor one but in case you are wondering: Don’t mix :host {} and your-element {} selectors, as browser that do not understand :host, will simply ignore the whole rule.

But except from those stumbling blocks, everything else actually went pretty smooth. The moment we inserted our component for the first time was super exciting. As we have upgraded various other systems with it, we immediately saw the visual impact of a consistent branded appearance:

It was simply brilliant.

By now we have a couple of systems running with our single webcomponent, which means we a have a single point of maintenance and a super easy and fast way to embed it into other systems as well as to deploy updates.

Even though I had some tricky phases the overall experience and outcome is more than satisfying. Considering the fact that we are approaching a state of complete support by the browser vendors of the major specifications, this is a set of technologies that here @gridonic we will not only keep in our portfolio but even expand its capabilities for future projects.

I hope you enjoyed this little insight. Feel free to drop us a line on Twitter, Instagram or Facebook.

Not that kind of digital nomad? Come around for a hot cup of coffee or tea — or water.

Take care and have a great day!