Web components: an opinion

Squeeds Julkalender | 2021-12-11 | Tobias Ljungström
Just my two cents on the state of the Web component technology and what you should do with it.

I recently gave a talk about web components at NDC Oslo, and then shortly afterwards at our own internal tech conference here at Squeed. Now I won't go into the same level of technical detail here as I did then (you'll have to watch the talk for that, video coming later), but I can relay the general message. Who doesn't like to read some opinions on a hot topic, right?

Web components are here to stay

The first point I want to make is that of the evolving web specification. Day by day the spec evolves and improves, and the browsers follow suit by implementing the described features. Thanks to this we no longer need to use and ship older libraries like jQuery to our users. Most of what we needed from that excellent library is now adopted by the spec and thus implemented in browsers as native features. A win for everyone. And just like a library like jQuery paved the way for "document.querySelector()" client side JS frameworks have paved the way for web components. Componentization is not all these frameworks do, and so they will not become obsolete very soon, but if that is the main reason you use something like React or Svelte, web components might just be a real alternative, because I believe that it is always wiser to use a native solution if possible. Angular and Vue and all the others will probably not last and be popular forever. But the web is backwards compatible. The very first website ever written still works in modern browsers. This means that web components are here to stay.

You should use web components

Web components are production ready and there is no technical hindrance that prevents you from using them in your project. Many web sites, and even entire web applications, use web components successfully today. Even if you decide that you don't want to build your whole thing with web components, they are so easy to use that be sure to consider using one or more stand-alone web components instead of dependencies written for a specific framework. There is one point however where I have a strong opinion and that is when it comes to UI libraries - collections of components, possibly as a part of a larger design system.

Building a component library with a specific framework locks the users into that framework. It might even lock an entire organisation into such a choice. What if the current framework goes out of fashion? What if it becomes deprecated? What if someone just wants to try something new? If the UI library has already chosen the technology for you, you can either scrap the library when switching tech, rewrite the entire library with a new technology, or you don't get to switch. It becomes an inflexible and possibly very expensive situation. Furthermore, since web components are a core web technology I think it won't be too long before the expectation of developers is to know about web components, rather that whatever framework is hottest at the moment. This all brings me to the following statement:

If you are going to write a web UI library in 2022, web components is the responsible choice.

And you can quote me on that.

How you should use web components

Writing web components using the native APIs is totally fine and more than possible. They are however quite low level APIs and I don't blame anyone for finding them a bit cumbersome to work with. They give you heaps of control, but maybe you'd rather have a little less control in favor of a smoother development experience? This is where web component frameworks come in. They are usually very light and can sometimes barely be called a framework, but they make the development process a lot easier. Check out Lit or Stencil or Hybrids for example. You'll probably want to use one of these when you write web components - BUT - having an understanding of how web components work under the hood gives you a much higher understanding of how the frameworks work, and will make you a better developer in the long run. So try to write at least one component with just the native APIs before jumping into a framework, that is my advice.

The future

The future of the web includes web components. You or I may make all kinds of predictions as to how large an impact they will have, but the fact is that they are part of the specification now, and that's not going to go away.

Bet on the platform!