Web Components and Design Systems: Two Peas in a Pod
Introduction
Many companies these days are struggling with scaling web development teams, while maintaining a consistent user experience across teams and over time. In this post I will discuss how web components can be a possible solution to solve this problem.
tl;dr: Web components are great for implementing design systems. If you use web components in conjunction with frameworks you have both power and flexibility.
What Are Web Components?
A lot has been written about web components in the last couple of years. However, given the huge amount of content and progress throughout the years it might be worth summarizing the key parts of it all. To start off, MDN gives a pretty good definition of web components:
Web Components is a suite of different technologies allowing you to create reusable custom elements — with their functionality encapsulated away from the rest of your code — and utilize them in your web apps.
Web components consist of three main technologies:
- Custom elements: A way to define new elements so that they can be used anywhere in a web app (e.g.
<my-button>Click me</my-button>); - Shadow DOM: An encapsulated part of the DOM to prevent collision of a custom element’s script and styling;
- HTML templates: New
<template>and<slot>elements to create markup for usage in a custom element.
Conceptually, an example of this is the HTML5 video element. It has its own custom styling, properties, methods, events, and internal logic to make it all work, but as a developer you don’t care about the underlying implementation and just want to use <video src="my-video.mp4"></video>.
With web components it’s possible to create new elements in a similar fashion, such as an icon element, a fancy button, a pagination element, or whatever meets your imagination. As long as the element is written according to the specification it can be used by anyone in any browser (even in older browsers that don’t support web components by using polyfills).
Why Create Web Components?
One of the key reasons to create web components is reusability. It takes a lot of time, money, and effort to create a component library so it’s not something that you want to rebuild every other year. As Smashing Magazine puts it:
Developers conduct AB tests, accessibility audits, unit tests and cross-browser checks. Once you’ve solved a problem, you don’t want to repeat that effort. By building a reusable component library (rather than building everything from scratch), we can continuously utilize past efforts and avoid revisiting already solved design and development challenges.
Due to a lack of built-in browser support, creating such a component library has historically been done in sub-optimal ways such as global CSS with BEM, CSS frameworks like Bootstrap, CSS modules, or framework specific solutions. With web components we have the possibility to create elements that are natively supported by browsers so there is no need to depend on a framework that might fall out of fashion in a few years. Even though browsers evolve and change over time as well, native support is much longer and more stable compared to frameworks. Many elements that were part of the HTML 2.0 specification from 1995 are still very relevant today (e.g.<a>,<ul>, <p>). Compare this to framework lifespans, where no one will want to touch the 8-year old AngularJS these days.
That is not to say that frameworks don’t have a place in the current or future technology stack. Quite the contrary actually, many frameworks are much more powerful and mature for specific tasks than web components. The real benefit comes when you start using them together. Frameworks are great for dealing with things such as complex logic, state management, data services, and routing. Web components are great for high reusability and creating elements that benefit from being framework-agnostic, such as UI components. Another benefit of separating framework components from web components is that both can have their own lifecycle and maintenance strategies. As a bonus, both approaches benefit from the same distribution mechanism by leveraging the power of ES modules and NPM.
Of course, it will differ per use case where you draw the line between what web components should do and what a framework should do. For some projects it might be good enough to only create components that abstract and encapsulate the styling of certain elements and sometimes you might want to create more complex web components with an internal state, public methods, and event handling. In the end, it’s important to keep the capabilities of your developers and the lifespan of your components in mind, while trying to avoid situations such as:
Design Systems and Web Components
From a purely technical perspective, a reusable (UI) component library sounds nice, but this concept actually goes much further and can be interconnected with the world of design systems. The following definition of a design system might sound familiar:
A Design System is a centralized library of components that can be shared across teams and projects to simplify design and development while ensuring consistent brand experiences, at scale.
Source: https://blog.ionicframework.com/5-reasons-web-components-are-perfect-for-design-systems/
Design systems are about much more than just components, it also includes design principles, colors, typography, flows, and more. Some excellent examples are Salesforce’s Lightning Design System, HubSpot Canvas, and Google’s Material Design.
Some design systems are purely specification-based (such as Google’s MD), while others are implemented with real code. A popular way these days to present a live-working design system or component library is with Storybook. With Storybook you have a single place where you can describe your design system and demo working components. This makes for a lovely developer experience while UX designers can verify whether the components are implemented correctly or not.
Though a design system can be empowered by web components and Storybook, bear in mind that it’s not a trivial task to actually get your design system to be adopted successfully in a company. Smashing Book 6 includes an insightful chapter about how to make design systems work in the real world.
How To Approach Web Components Development
There are many ways to go about creating web components. You can go for a bare-bones vanilla implementation or use one of the many abstraction layer libraries. One thing to keep in mind is that if you want your components to be used and keep their relevance, it’s essential that you provide a good developer experience for your component consumers. Non-functional requirements such as an easy-to-use API, clear technical documentation, performance, accessibility, and the likes need to be taken care of in order for your components to become successful. Depending on your preferences each approach will have its pros and cons, but probably you will want to use a library to help with your development process.
One thing to keep in mind is that not all JavaScript frameworks are currently working seamlessly with any custom element. A great resource to check what is currently working and what isn’t is https://custom-elements-everywhere.com. Another thing to consider is browser support. Though most major browsers support the current specification, some polyfills may still be needed depending on your browser requirements. Especially polyfilling the Shadom DOM can be a bit tricky, particularly in combination with the hot-and-happening CSS custom properties.
Conclusion
Web components and design systems are like peanut butter and jam, bacon and eggs, cheese and wine, peas and carrots. Basically, they go quite well together. Design systems are a great way to describe a companies’ styling, building blocks, guidelines, and design processes at a manageable scale. Web components are great for implementing design systems while solving some of the problems that have been plaguing the web for many years such as global CSS mess, framework churn and lock-in, and a lack of proper component encapsulation. Add Storybook on top of that to showcase it all and you have a very powerful solution.
The maturity of the web components specification and browser implementation is currently at a sweet-spot and due to the framework-agnostic nature of web components, you can start using them today in your existing web applications and continue to use them in the frameworks and years to come.
At Blue Harvest we are currently working on a reference on how to implement a design system with web components. We’re using StencilJS to help ease the development and maintenance of web components. If you’re looking for help to implement your design system, don’t hesitate to contact us at info@blueharvest.io or check out our website https://blueharvest.io/ for more information about Blue Harvest.
