Web component - the best pathway to your next design system

What is a web component?

If you're looking for a comprehensive answer, you can find it here. My understanding is that it's a way for developers to build their own HTML tags (with methods for scoping the code and interactions with the rest of the DOM).

Why is this awesome?

This concept of reusing a thing is not new, in programming, we have the DRY (Don't Repeat Yourself) principle, which encourages abstraction to reduce redundancy. When you're writing the same code over and over again, a good practice is to extract that piece of code into a function, then when you need to update that logic for whatever reason, you'd just need to change one place.

Same principle can (should) be applied to UI/UX design. Your users expect the same experience within the same site/application. There can definitely be variations due to different use cases, but the components should follow the same principle and applied to the implementation. This way, when there's an update to the design, again, you only change one place in your system and everything gets updated.

In pre-web-component time, this is generally done in two ways:

1. Use a CSS framework (Bootstrap, Materialize etc)

• PROs

  • Easy to add to your project
  • Provide a lot of well-documented classes out of the box

• CONs

  • Affects performance
  • All classes are in the global scope
  • Hard to customise (!important EVERYWHERE)
  • If the framework gets updated and introduce breaking changes, it's hard to not do a site rebuild

2. Use the component libraries based on the JavaScript frameworks. (Vuetify, Material-UI, React-bootstrap, etc)

• PROs

  • Integrates well with your framework of choice.
  • Capable of providing more functionality (e.g. DataTables, Tabs, etc)

• CONs

  • Locked into the underlying JS framework/library

Using the JavaScript frameworks introduces another issue: they don't talk to each other.

If you have a big enough organisation, your marketing team might be developing a React site and your product team might be heavily integrated with Vue or Angular. Because your teams can't share a single source of components in their apps, it means either each team need to build their own component libraries according to the design guidelines, or you leave your users to wonder if they're using the same product. And if the design changes, the teams will each make their own updates to reflect the artworks.

Web components to the rescue!

Since web components are supported by browsers, it doesn't matter if your teams prefer different frameworks or no framework at all, they can still have a set of shared components with the same API to integrate into their apps. This also means when the design changes, the only implementation that needs to be changed is in the component library, the rest of the places just need to update to the latest version. Let's pro-con again on the web components approach:

• PROs

  • Easy to add to your project
  • Integrates well with your framework of choice or no framework at all.
  • Capable of providing more functionality (e.g. DataTables, Tabs, etc)
  • Capable of isolating styles and functionality to only the scope of that component
  • Highly customisable

• CONs

  • Browser support (mostly IE)
  • Developer experience
  • Reactivity

Let's talk about the CONs for a moment.

• Browser support this mostly apply to the good'ol trouble maker that is IE. Looking at various sources, most of the web component features are supported by major browsers. There are polyfills that can be applied to make components backwards compatible, but there is a bit of extra weight with that.

• Developer experience front end developers nowadays are so used to the development flow that is changing a bit of code and seeing it immediately get reflected in the browser window. Having a local dev server with the hot-reload feature enabled is essential to the modern front end development process. And having a build process will help to trim a lot of fat from the final product.

• Reactivity data binding is a wonderful thing that happened with Angular, React and Vue and most of the rest of the modern JS tools, if you ask a React/Vue developer to go back and do document.querySelector() it'll be like asking a designer to throw away their MacBook Pros and get a laptop that has Windows Vista pre-installed.

Luckily, there are tools that help mediate those CONs which makes building web components with those tools a good choice to have a maintainable component library for an organisation. I'll talk about one of them in the follow-up post.

Stay tuned.