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?
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.
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.
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.
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
Any framework or no framework
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.
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.
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
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 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
- Duet Design System
- Web Components specifications
- Custom Elements Everywhere
- Apple just shipped over 45 Web Components in Apple Music
- Firefox’s whole UI is now built with Web Components
- SalesForce’s Design System uses Web Components
- Mixpanel Design System
- GE’s Predix Design System
- Meetup.com’s Swarm Design System
- Fuse Design System
- SAP Web Components System
 If we can really consider something introduced in 2011 to be new anymore.
I’m an independent design systems architect specialized in helping organizations to build design systems. Get in touch.