Love them or hate them, web components ("custom elements") are making a huge dent in the world of front-end development. As of today, close to 18% of page views in Chrome are registering web components. That's an insane amount of usage!
The benefits of a framework-agnostic component model are becoming obvious to web developers, particularly those who have built the same components over and over again to accommodate various framework flavors. That kind of rework is a time sink that inevitably leads to visual and functional inconsistencies. Maintaining multiple versions of the same component isn't a winning strategy for developers, designers, or end users.
Web components solve this problem not by replacing frameworks, but by complementing them with a standardized component model. Create your lower-level building blocks as custom elements, then plug them into a framework that handles higher-level operations. When it's time to upgrade or switch frameworks, you can do it more easily because you don't have to rip out the foundation and rebuild everything from scratch. Interoperability is why web component-based design systems are so appealing to large organizations.
My prediction is that front-end frameworks will move away from proprietary component models and embrace custom elements as first-class citizens. Both Vue and Svelte provide mechanisms for authoring them — although they still use and support their own component models as well.
"But I don't plan on switching frameworks!"
Unlike diamonds, frameworks aren't forever.* They come and go and, as their popularity fades, so does support, contributions, and community interest. Contrast this to web standards that browsers commit to supporting without breaking changes.
We've been building and rebuilding buttons for years because the component model has been baked into our frameworks. We don't need to do that anymore. If longevity is a goal, custom elements are where it's at.
*Whether you consider React a framework or a library is irrelevant. It has its own component model, VDOM, and synthetic event system. If it walks like a framework and talks like a framework…
Top comments (2)
I am more and more of the opinion the terms Web Components and Frameworks should not be used in one article.
Web Components are just an API and some HTML additions.
Just like Set and Map are additions to the JavaScript language,
I have never seen an article where someone complains Map isn't the same as Redux.
I'm not comparing web components to frameworks. I'm suggesting that the underlying component model of frameworks will, in time, shift to utilize the APIs that comprise web components so they can focus on higher-level goals.
We don't use jQuery anymore because many of its features were "adopted" into the browser (e.g. querySelector). Standards take time. Now that we have a standard component model, frameworks that implement their own will start to be seen as redundant. They'll eventually shift gears into focusing on state management, routing, etc.
What's exciting about this future is we'll likely see a lot of new flavors for authoring components, but the end result will be standard custom elements that maintain interoperability.