Jan 21, 2020
There’s No Need To Hate Web Components
And you don’t need to drop your framework either
Four years ago, I landed a freelance gig at an international Dutch bank. Originally I was hired to help with migrating applications from AngularJS to Angular 2, but things turned out differently all of a sudden.
One day, I bumped into one of the managers who urged me to “have a look at Polymer”, since a team in Australia had created some nice stuff with it. Polymer was now the way to go forward and literally within a few weeks, we were in the middle of migrating to Polymer.
Things went fast and things went wrong as well. The first stable 1.0 release of Polymer was only about a year old and there was still a lot of pioneering to do.
We struggled with tests, legacy browser support and dependency management. But now, four years later, Web Components are finally here and they’re ready.
Web Components Are Now Supported Everywhere
On January 15, Microsoft released its Chromium-based Edge browser and with that, all major browsers finally got native support for Web Components.
The original specification was introduced back in 2011, so it was already proclaimed dead a few times before by pessimistic developers.
The announcement by the Polymer team, following the release of the Chromium-based Edge was again met with quite some sceptic comments:
An effort 9 years in the making, but we’ve finally made it.
— Lit (@buildWithLit) January 15, 2020
WebComponents are supported natively in every major browser pic.twitter.com/6yPoTXno27
So why all this hate for Web Components?
It’s Been A While
It’s taken quite some time, too long maybe, for Web Components to be supported by all major browsers. In the meantime, frontend frameworks have taken over the world and lots of developers seem to be reluctant to “make the switch” to Web Components.
React is still king, Vue.JS is gaining traction and the adoption of Web Components is still relatively low. But over the last year and a half, this seems to be changing slowly.
There’s framework fatigue, with developers wondering if frameworks are worth the trouble, looking at the native platform for an alternative.
I believe Web Components are a solution, but Web Components being an alternative to frameworks is one of many misconceptions surrounding them.
Let’s have a closer look.
You can keep using your framework
There’s no need to “switch” and drop your frontend framework. That may sound strange coming from someone who claimed that Web Components will replace frontend frameworks, but this was never the goal of Web Components.
Yes, I still believe that Web Components will evolve to make these frameworks as we know them obsolete, but they were never intended to be a replacement.
A key feature of Web Components is that they are framework agnostic, meaning they can be integrated into any framework. This is a huge shift from the proprietary components created with Angular, React and Vue for example, which are not interchangeable.
Web Components finally enable us to write a component once and use it everywhere. The three major frameworks, React, Angular and Vue already provide support to integrate Web Components.
“Nobody uses Web Components”
The adoption of Web Components is still relatively low, but they’re already used in production by YouTube, Apple Music and ING Bank (of which I’ve been a part), and Github and Twitter are also using them for smaller parts of their apps.
It’s no surprise that Web Components probably won’t be an overnight success in this era of framework dominance and the fact that they only became fully supported by all browsers recently.
But currently, interest is growing fast and the amount of articles being published on Web Components and projects using them is growing rapidly. Some great examples are Svelte, Webcomponents.dev and open-wc.
So while the adoption and browser support of Web Components has taken long, it’s happening without a doubt.
“I need to support IE11”
I’ve been through the pain of having to support IE11 while trying to use modern JavaScript features.
But I never let that get in the way of delivering the best experience possible to users of modern browsers. It just makes no sense to degrade their experience, just because we need to cater to users of older browsers as well.
It makes more sense to give all users the best experience possible, but not necessarily the exact same experience. That might mean extra work, but this is not specific to Web Components, so it shouldn’t be a reason to not use them either.
Depending on how many of your users still use IE11 you can decide how many resources you should spend on this. Usually, this will be a small percentage and so resources should be spent accordingly.
If this small percentage gets at least an acceptable, albeit degraded experience, then that should be fine.
For Web Components specifically, their is a group of polyfills available which can provide a good enough experience on IE11.
Just make sure your users on modern browsers don’t suffer because you need to support a small percentage of users of IE11. That just doesn’t make sense.
“There’s no data binding, it won’t scale”
By default, attributes of Web Components can only take primitive values like string, number and boolean. Changes of the values of these attributes can be watched and reacted to through the attributeChangedCallback method.
Attributes cannot take complex values like objects and arrays, so in practice, data binding can only be done through attributeChangedCallback with primitive values.
But that doesn’t mean that data binding of complex values is not possible with Web Components, it just requires some code.
I implemented a simple proof-of-concept of this myself. It’s similar to lit-element, created by the Polymer team, which also provides a bass class for Custom Elements, containing various convenience methods to make working with Web Components easier.
Keep in mind that frameworks don’t “magically” make data binding with complex values possible either. They usually provide a serialization mechanism to accomplish this, which isn’t free either in terms of performance.
The standard way of working with Web Components is that complex values should be passed in through properties. Usually, you would define getters and setters for these properties to react to changes. You can also define methods on Web Components that can be called from the outside and that way, complex values can also be passed in.
“There are no stateless components, it won’t scale”
Web Components are class-based, which is necessary since they need to extend HTMLElement, which is the bass class for all HTML elements. By nature, Web Components work by extending HTML itself.
Personally, I would have been happy if it was possible to create a Web Component with an object or function, but for the reason mentioned above, that is unfortunately not the case.
But that doesn’t necessarily mean that Web Components won’t scale when an application gets very large.
There seems to be this misconception that without using a frontend framework and stateless functional components, building a scalable app is not possible anymore.
Stateless functional components are great, but they do bring quite some additional complexity. In case of React, the API went from React.createClass to ES6 classes to functional components, which brought Higher Order Components which are now being replaced with React hooks.
We should realize that these are all workarounds that were created to solve the problems that stateless functional components caused.
They just might be more trouble than it’s worth.
“Theming Web Components is hard”
Web Components can use Shadow DOM which bring truly scoped CSS. This means that a component can be styled with CSS from the inside that only applies to the component itself.
Of course we still want consumers of Web Components to be able to style them, which can be done through CSS Custom Properties. This does mean that each of these properties needs to be explicitly exposed.
In Chrome and Firefox, CSS Shadow Parts is already supported to make theming easier and constructable stylesheets are supported since Chrome 73. It’s not yet clear when support will land in other browsers though.
Theming Web Components still has room for improvement, but the alternative for frameworks, for example React styled components, requires yet another library, is complex and moves all CSS to JavaScript.
“There’s no server-side rendering”
Server-side rendering is hard and when using Shadow DOM or any other browser only API, I guess you have no other choice than using a full blown headless browser to do the rendering for you.
If your app strongly depends on server-side rendering, Web Components are probably not a good choice right now. But then again, your best bet is probably to go with static HTML altogether and not a single-page app.
Web Components are a robust solution
There are a lot of strong benefits to using Web Components for a component-based frontend architecture.
They extend HTML itself and leverage the HTML parser of the browser which ensures optimal performance.
You can continue to use your favorite framework, since Web Components can be integrated into all current frontend frameworks and are therefore truly reusable anywhere.
Web Components are standards based, require no external dependencies and are highly unlikely to ever be deprecated. They are now supported by all major browsers and will remain to be supported indefinitely.
The API of Web Components is stable and is guaranteed to remain stable since it’s bound by standards.
These are the benefits of Web Components: standards based, future-proof, stable and truly reusable.
Embrace them or hate them, the choice is yours.