why-we-use-web-components

It’s August, 2018. I’m at the office, sitting by the window staring rain pouring down from the sky. A warm cup of tea in my hand, about to sip it, but the phone suddenly rings. I don’t recognize the number. I hesitate for a moment whether to pick it up or not. Maybe it’s again one of those telemarketers trying to sell me something?

We had the urge to create a tech-agnostic instead of tech-specific system. A system that is based on web standards and would survive the births and deaths of JavaScript frameworks.

Thinking of this particular autumn evening today, a year and a half later, I’m delighted I picked up the phone. This one phone call ended up resulting in the biggest personal project I have worked on so far.

While I used to work with bigger clients and projects when we lived in United States, this felt different. I personally sold the project and were responsible for most of the things from initial research all the way to the design system’s overall architecture.

A few months went by after our first call. I went to see the client during a couple of occasions to plan the possible collaboration. After some back and forth negotiation we ultimately started working together in the beginning of January, 2019.

And so Duet Design System was born.

Controversial opinions

As you might have guessed based on the headline, Duet Design System has something to do with Web Components. Quite a lot actually. Our whole frontend component architecture is based on Web Components. But how and why did we end up using them? Seems like a very controversial tech, at least if you solely base your opinion on what’s happening on Twitter.

Well if anything, we didn’t actually start by choosing Web Components. It was more that they chose us. Truth speaking, we weren’t even considering them until only later on in the spring once the research I was working on started suggesting us that they might be the most viable option.

One of the biggest challenges for us turned out to be the number of different tech stacks in use. My client had applications built using Angular, React, Ember, Vanilla JavaScript, basic HTML, native code. And more.

We couldn’t just choose [a framework] because the different tech stacks were picked by different teams (or even different sub-companies) for different reasons and we would have never succeeded if we would have started trying to force everyone to use a specific technology like React.

Instead, we had the urge to create a technology-agnostic instead of technology-specific system. A system that is based on web standards and would survive the births and deaths of JavaScript frameworks.

What are Web Components?

Web Components are a set of technologies that provide a standards based component model for the Web. They allow you to create reusable custom elements with their functionality encapsulated away from the rest of the code. Primary technologies used to create them include:

Best parts of Web Components

This past year has made me a big advocate for Web Components. What previously seemed like a distant black box that I tried to stay away from, has now become an important part of my toolset. If I would have to list the main reasons why Web Components work so greatly for Duet Design System, it would be these four things:

Tech-agnostic instead of tech-specific

In order to create modular interfaces, a design system needs to be technology-agnostic instead of technology-specific. Web Components offer this benefit and make it easier to reduce our design system’s complexity and improve its reusability.

Future proofing with Web Standards

Web Standards are more future proof than any given JavaScript framework. I’ve seen different frameworks come and go during my almost two decade long career on the web, but Web Standards keep thriving and evolving.

Any framework or no framework

Web Components can be used with basically any JavaScript framework or no framework at all. This means we’re able to support all our product teams from a single codebase. This makes it possible for our small design system team to be very efficient. Currently we can offer support for all of the following with just one set of components:

Full Encapsulation

Shadow DOM allows components to have their own DOM tree that can’t be accidentally accessed from the main document. For us this means that “everything just works” when the components are implemented onto different environments and platforms. Styles cannot penetrate a component from the outside, and styles inside a component won’t bleed out.

Debunking Myths

I guess you really can’t talk about Web Components without also talking about their negative sides. They’re built on evolving standards which have their flaws and limitations. I’ve seen a few myths go around though which I’d like to clear just a bit for anyone wondering:

Shadow DOM doesn’t work with forms

This is true to some extent and one of the drawbacks of Shadow DOM. It makes sense though if you think about it. Shadow DOM isn’t a part of the normal DOM tree/document. Whether this is an issue for you or not depends on what you’re building.

There’re a few approaches on how to get around this, but the easiest is to not use Shadow DOM for components that host form inputs. The other option would be to create an invisible input and append that with JavaScript to the parent document.

Web components can’t be server side rendered

Not true. We’ve built support for server side rendering into our Web Components. While it might be hard to do if you would have to build a solution from scratch, there are tools like Stencil.js that solve this for you.

Duet’s Web Components package includes a hydrate app that is a bundle of the same components, but compiled so that they can be hydrated on a Node.js server and generate static HTML and CSS.

Using web components means duplicate CSS

It can if you don’t make your components modular enough. But if your frontend architecture is designed around reusability and modularity then this isn’t really an issue. Yes, you might have to set margin and padding once to zero for each Shadow DOM, but let’s not exaggerate the impact of this. We use one Sass mixin for this in Duet.

Web components aren’t accessible

Not true at all. Of course you can construct them in a way which isn’t accessible. But so you can do by building things with [insert a JavaScript framework] as well. We provide support for WCAG 2.1 Spec and have tested our Web Components to work with all common screen reader and OS combinations like:

Web components don’t work with React

This is both true and false. Web Components themselves work fine, but by default React passes all data to Custom Elements in the form of attributes, meaning you can’t pass objects or arrays without workarounds. Additionally, because React has its own synthetic event system, it cannot listen for DOM events coming from Custom Elements without the use of refs.

Both of these issues can be fixed, but for some they might be showstoppers. For our team the benefits of Web Components far surpassed these and we decided to work our way around these issues by automatically wrapping our Web Components with React based wrappers.

Web Components aren’t production ready

This last myth I probably hear the most often. People seem to assume that because Web Components are built on evolving standards they can’t be used for anything else except experiments. Well guess what, the whole World Wide Web is a set of standards that are constantly transitioning and evolving.

If you need to see some real life examples, take a look of Firefox’s user interface that is now built with Web Components. Or Apple who uses Web Components in their new Apple Music service.

The future is bright

This is an incredibly exciting time to be a web developer. New standards[1] like the Web Components have made it so much easier to build systems that can support a range of platforms and frameworks via a single code base. To be completely honest; five years ago I would have probably laughed if someone would have claimed that all of this would be easy.

Enthusiastic from our positive experiences, the next step is to expand towards native apps and create browser based tools around Duet’s Web Components that allow us to move further from static design tools. ❦

Web Components out in the wild

[1] If we can really consider something introduced in 2011 to be new anymore.

Get in touch

I’m an independent design systems architect specialized in helping organizations to build design systems. Get in touch.

Share

Leave a Reply

Your email address will not be published. Required fields are marked *