Build framework agnostic Web Components

Laurence Do
4 min readFeb 13, 2021

Being framework agnostic is a big deal, especially in this age of extreme framework fragmentation. Many large organizations have widely distributed apps and engineering teams, using different web frameworks. I’ve been on projects that used Angular, React and Knockout. What if they can all share the same building blocks?

This article will go over Web Components and StencilJS. How do they work, what problems do they solve and when should we use them?

Photo by Bonneval Sebastien on Unsplash

Check out this amazing page with a button that pops up a tooltip on hover. Can you tell which web framework it’s using?

<do-not-push /> is…

That’s right! Custom HTML elements, aka Web Components, are part of the HTML standard.

Why this is useful

Web Components are:

  • Extremely fast and light weight — pure native HTML/CSS/JS
  • Framework agnostic — you can use them in Angular, React, Vue, {NEXT_HOT_FRAMEWORK} apps, jQuery or just plain JavaScript
  • Completely self-contained

Web components are strongly encapsulated, highly reusable simple components. They can complement, but are not a replacement for app frameworks like React or Angular. You would not build a complex app with state management as a web component.

How does it work?

A Web Component is implemented in a JavaScript class, which is then added to the customElements registry.

The markup, behavior and styling of the component are all defined in the constructor of the class:

What makes the Web Component completely encapsulated is that we’re creating its content in the Shadow DOM. Yes, that’s a real thing (line #8)

The Shadow DOM is the DOM inside the DOM. Each shadow root is a completely isolated DOM tree. Its contents are invisible to the parent DOM and it’s styles don’t leak out. For the most part, parent styles don’t leak in. This eliminates ID and class name conflicts, and unpredictable inherited CSS. The Shadow DOM is not new. In fact, it’s how complex native HTML elements like <video /> are implemented.

But…

Can you actually use this to build non-trivial features? Isn’t building web UI with document.createElement() a bit… archaic?

Source: xkcd.com

While big frameworks like React and Angular can come with a lot of baggage, they also provide tooling and structure that help us develop complex UI quickly and painlessly.

Enter Stencil JS

Stencil JS allows us to harness the speed and reusability of Web Components, with the ease of development frameworks provide. We define components in TypeScript and JSX, and Stencil compiles them into pure Web Components.

Stencil is a very small API, and relies mostly on existing HTML standards. All the action happens at compile time. At runtime, there’s no need to include extra resources or load any framework. We’re just using HTML Web Components.

Stencil also includes polyfills for older browsers that do not support Web Components.

When is this useful?

In my opinion, Web Components make sense at the two extremes of complexity — when we’re building a really simple site, or in large distributed engineering environments with multiple web frameworks in play.

For simple sites, Web Components are ideal when we want fast, lightweight components without the overhead of a big framework, but still want the ease of development provided by JSX and TypeScript. There are also lots of free Web Components collections you can use straight away.

In the distributed scenario where multiple frameworks like React, Angular, and Vue are being used, Web Components can be a way for them all to share the same basic UI building blocks.

A little history

Web Components are not a new concept. At the same time when React and Angular were sprouting, a Google framework called Polymer which was based on Web Components was also trying to take root. It was soon smothered by the former two.

Now that we’re in a world of extreme framework fragmentation, with big, heavy runtime frameworks like React and Angular dominating the field, the pendulum is beginning to swing back.

Simplicity, speed and interoperability sound like good ideas again.

--

--