Should I use Web components?

Published in

Engineered @ Publicis Sapient

6 min readJan 6, 2020

--

At Publicis Sapient, we do all kinds of Web Applications. We call it Experience Technology. These custom user experiences have different needs. Sometimes, we do static content deliverables like temporary marketing campaign pages or knowledge bases that never get touched again. More often we do enterprise shopping experiences, catalog maintenance, and other e-commerce platforms.

Asking someone of my team how to build their next customer user experience, I get named: React, VUE, Svelte or at last, Angular. Normally, no one tells me yet: Let’s do it natively, let’s use Web Components.

Do I know why?

Maybe

Reasons why frameworks are so common and preferred:

They offer a community
Searching for an issue or supporting library for sure returns a Stackoverflow entry or an NPM library
There is great support by someone that has ‘already done this’
For Business: It is good to have something to sell that everyone knows

A quick poll

Doing a quick poll with our experience technologists hardens the opinion.

Showing React 58%, Angular 3%, VUE 15%, Native Web Components 7%. Other 13%

Observing the obvious

Using frameworks and libraries for everything causes problems that could be prevented. The average weight of a page is increasing. The Complexity of generated code, too. Views of common frameworks and libraries are often ridiculous, complicated and deep nested, and adding libraries and grid systems are done with a click. Importing without seeing the direct deeper effect. On top of that, designers create complex animations and placeholders and forget that we still have low-end devices to support and not an ideal-world fast internet. Accessibility and search, like find-ability, are getting worse. When useless containers are nested and semantics are getting lost.

On top of all, GDPR compliance is bad to achieve as often third parties are used in a way that makes it hard to know where your customers’ details are getting shared.

This directly leads me to the ask: Do we at all need to use a framework or library? Can’t we use Web Components?

Webcomponents.org tells a clear use case, but why doesn’t anyone consider it in the first place to use it as a base in their projects?

Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps. Custom components and widgets build on the Web Component standards, will work across modern browsers, and can be used with any JavaScript library or framework that works with HTML.
Web components are based on existing web standards. Features to support web components are currently being added to the HTML and DOM specs, letting web developers easily extend HTML with new elements with encapsulated styling and custom behavior.
— Webcomponents.org

Would there be any advantage when using them instead of a framework? Long-term for sure. Imagine a situation where Facebook stops support for React or Google for Angular. Sooner or later, libraries might get outdated. The community for sure supports it for some years, but it can stop. There is no guarantee that it works long. There are also new libraries popping out every day.

As we started writing decoupled user experiences, using micro-services and micro-frontends, we forgot to enable ourselves to create long-lasting front-end code that is maintainable. Instead of using native functionalities, write proper markup, getting accessible and search engine friendly.

We now create a dependency on a framework that is likely to become outdated soon. Any reason to do so?

Not really!

Frameworks and libraries should help us organize and write our code and deliverables, but not overtake our thinking and tooling. It is unreasonable that we deliver whole applications to clients’ browsers when the contents never change or change only every few months. We should instead build more meaningful smaller applications. We even need to render the server side, using JavaScript.

A quick excursion on what Web Components are:

Using Web components allows us to get back to standards, using browser-supported simple tooling.

So why should you consider Web components as complements to frameworks and libraries?

They are already a standard
They work cross-browser (Can I use it?)
They are simple and stand-alone
They are already used
They are future-proof

The details

Web components are the wrapper name for a set of techniques that create browser rendered interfaces. They are created through custom elements, shadow DOM, HTML templates and HTML modules. The latter is yet not widely adopted by browsers.

Custom Element

Set up a JavaScript file that contains the code for your custom element.

MyCustomElement.jsclass MyCustomElement extends HTMLElement {    
  connectedCallback() {
    this.innerHTML = `<p>Some Text</p>`;
  }
}
window.customElements.define('my-custom-element',  MyCustomElement)

You need a DOM node that can initialize it.

MyCustomElement.html<my-custom-element></my-custom-element>

Custom Element Combined

Shadow DOM

With your custom element, you can add colored text in the context of other text paragraphs. You can capsule your styles that belong only to the needed node.

Shadow.jsconst shadowRoot = document.getElementById('fetched').attachShadow({ mode: 'open' });
shadowRoot.innerHTML = `<style>
p {
  border: 1px solid red;
  padding: 5px;
}
</style>
<p id="paragraph">Paragraph using <slot></slot></p>`;

Create some HTML to connect your code with it.

ShadowRoot.html<span id="fetched">Slot</span>
<p id="paragraph">Normal Text</p>

Shadow DOM, as shown below, will be generated.

ShadowDomRendered.html<body>
  <span id="fetched">    
    <#shadow-root>
      <style>
      p {
        border: 1px solid red;
        padding: 5px;
      }
      </style>
      <p id="paragraph">Paragraph using Slot</p>
    </#shadow-root>
  </span>
  <p id="paragraph">Normal Text</p>
</body>

Shadow DOM combined

Use HTML Templates

Stay DRY. Use HTML templates. Look at the above example. If you want to render more paragraphs, you can repeat the <p> or just use a <template>. It is obvious what is wet and what is dry.

You can use them together with custom elements and shadow root, or alone.

HTMLTemplate.html<template id="template">
  <p></p>
</template><section id="paragraphs"></section>

How to render an HTML template.

RenderTemplate.jsconst paragraphs = document.getElementById('template');
const text = [
  { node: 'Text 1' },
  { node: 'Text 2' },
  { node: 'Text 3' }
];text.forEach(text => {
  const domNode = document.importNode(paragraphs.content, true);
  domNode.querySelector('p').innerHTML = text.node;
  document.getElementById('paragraphs').appendChild(domNode);
});

HTML Templates rendered

Did I miss HTML Modules?

Nope. But they are currently considered. So let’s see.

What else to consider?

Take also into account that all is maintained in a component library, handled in a DSM provided by InVision, Figma, or Design Kits like Sketch. We need to ensure that we reuse our code and Styles. Design Tokens help here. Amazon has the Styled Dictionary, but there are others. And ideally, have a direct connection to your repository. (More would be subject of a full own post).

But my client has IE11 as standard browser!

Ask them why! Seriously!

If they still insist, and maybe even have a dated soon to be replaced Edge: there are Polyfills available, they render the components as HTML for you.

Any other input?

More and more Frameworks and libraries arise that help generating your applications with Web components. They offer build-in testability, design libraries, pattern libraries and more. There are well-established ones like Polymer or Stencil. You can find more on the web component page list. So if you do not want to do it manually, use the tools provided.

What to do

There is no golden hammer that makes all your problems a nail. But you should consider re-usability, need for the current implementation, and how long will it exist. Then, it can help you make a decision.

Static rendering for interim campaign pages, knowledge bases, and so on can improve SEO, size and customer experience. Full-blown SPA with a checkout or profile management and a healthy mixture for catalog types can do their part on this. So even Web components might not be the perfect solutions when you only need to render a static page for some time.

But the base of all could be a Web component. Just do it.

Resources mentioned and used

Fun fact

Yes, you can also make Web components complicated.

This is a cross-post of my private Weblog: https://polente.de/2019/11/27/should-i-use-a-framework-or-library/