Best framework for Web Components
Follow our selection journey and find out how to decide for the best framework based on criteria such as: interoperability, bundle size, or developer experience.
What are the web components?
According to Mozilla:
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.
You can create the web components, using only HTML and some vanilla Javascript, in case you need them to be more dynamic. But, of course, every JS framework builds on top of this foundation and provides this option as well.
Why we started to play with different technologies?
As our web components are used on many places across multiple domains and tech stacks, we’ve been constantly challenged to reduce their size and loading speed to minimum. This was particularly difficult with our first framework of choice — Angular.
Don’t get me wrong. We love Angular and we rely on it heavily in other projects. But, as it showed up, it isn’t suited very well for the creating of the web components.
Main issues in our case were size of the Zone.js library (which at that time could not be separated from the framework) and underlying issues that manifested themselves when multiple instances of same component have been created on the same site.
This led us to the research and luckily, we found the webcomponents.dev website with its extensive comparison
As you can see on the picture, Angular is not even on the list due to the issues with Zone.js that started in version 13, but even until then, its been the largest one in terms of the bundle size.
Our own performance comparison
This comparison sparked our curiosity, but we didn’t want to rely solely on it and do the big bang migration of our stack in production. That’s why we’ve chosen one of our own web components and did a performance comparison ourselves. We wanted to see the results for the real-life component and not some dummy application, that might lack the complexity or dependencies.
That’s why we’ve chosen our loan calculator widget:
We’ve leveraged a split between business units and for some time, we have been able to simultaneously run the version of the widget created in three frameworks of our choice:
- Angular
- VueJS
- Preact
We’ve also briefly experimented with the Svelte, but we weren’t able to find the proper alternative for some dependencies, that our project relies on.
Our criteria for the “winner” selection was to find the sweet spot between the bundle size and the developer experience.
Bundle size was easy. As we’ve implemented the calculator in every framework, results were as follows:
Preact was the clear winner. Along with this experiment, we’ve also tried to prove the correlation between the bundle size (hence loading speed) and the conversion rate of the sites with the calculator. Surprisingly — with such a small widget, even the 300kB optimization brought no results.
As for the developer experience — we have a team of mainly Angular developers, some of them having the background in the Drupal. While we’ve expected the Vue to be the closest thing to it, Preact proved to be so simple and straightforward to learn, that after getting familiar with 2–3 mechanisms, everyone was able to take the project and create the feature or do any maintenance.
Final remarks
These findings are not the universal truth. This was our case and our result. As always, choose the tool according to your use case (long/short-term project, developer experience, performance demand, …). And if you would like to read more stories such as this one — follow our publication, as we have many initiatives cooking in our kitchen, with results ready to be published.
