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.