It's not about Web Components vs. React
Tags: webcomponents, react, javascript, html
Published: 2019-04-16 19:10:08

You often hear engineers comparing Web Components with React. Here's my take on it.

### Web Components are spec. Your web framework isn't.

The fact we don't need a JavaScript framework to use Web Components is a huge differentiator. The parts of the Web Components spec custom elements v1, templates, slots, and ShadowDOM all work in the browser. This means no dependency wrangling to start coding Web Components!

![](https://thepracticaldev.s3.amazonaws.com/i/cdmrq1jzjxci8ce1vpv7.png)

You don't need a ton of JavaScript just to render UI. Web Components are beneficial for instances where loading heavy dependencies prohibits user interaction, like in the case of mobile. It's more than that though. Turns out [static site generation for web components takes a minimal amount of tooling](https://github.com/readymade-ui/readymade/blob/master/build-gh-pages.js). HTML Modules will make the ergonomics of handling template partials even better. This year the Chrome team announced [the HTML Modules spec](https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/ewfRSdqcOd8/w_Fr6rJ3DQAJ) is on the way! While you may require a JavaScript framework for building complex web applications, static sites are optimally built with just spec. That's a huge deal considering how much of the web is static content. Sorry React and Gatsby.

### Web Components are inclusive.

The JavaScript ecosystem is so fragmented. Web Components are an opportunity for everyone to speak the same language. Proponents of React are quick to point out there is "no single 'web component community', but the truth is the community is all of us. JavaScript frameworks are exclusive. You have to be part of the club. That's not true with custom elements v1. Beginners can start coding them without the uphill battle that is learning a JavaScript library.

### Web Components solve a different problem. 

React addresses the lack of state in UI development. Custom elements are stateless. You need to bring a state machine to custom elements. There will always be room for JavaScript frameworks. Web Components provide an opportunity to streamline this component paradigm that's been kicking around here the past few years so everyone can use the same UI components. Web Components are essentially solving the problem of ergonomics when extending the base elements we use everyday. [It even says so in the React documentation.](https://reactjs.org/docs/web-components.html) React and Web Components solve different problems.

### Web Components are interoperable. Odds are your Javascript framework isn't.

Using custom elements in frameworks is not only possible, but should be considered a best practice going into 2020. Javascript frameworks should just be able to cope with custom elements just like they have to deal with DOM. There are many quirks to getting web components to work with JavaScript frameworks. React has some problems, however the React team has said [they will consider tight integration with the spec](https://dev.to/ben/why-the-react-community-is-missing-the-point-about-web-components-1ic3/comments). Angular doesn't support part of the spec for customized built-in elements. Angular has provided support for autonomous custom elements, even going to far to compile down to them using Angular Elements. Vue is fairly interoperable with custom elements, however someone who codes with Vue please chime in here if you've encountered issues. There are workarounds to solve problems that arise from integrating Web Components, but JavaScript frameworks have some work to do to ensure the complete custom elements v1 spec just works.

### Web Components are a11y. 

Customized built-in elements allow you to extend native elements like button, input, and select and implement your own functionality. By extending elements that have accessibility traits you gain those features for free. Normally you have to duplicate accessibility features when building UI components with JavaScript frameworks.

### There is a problem with education and web engineering. 

In code academies that have become popular over the last decade we forget to elaborate on spec and jump right into JavaScript frameworks. Even an introductory level course can include exposure to React. This is advantageous for the JavaScript frameworks that just want us to "use the platform", but it leaves a void where junior level engineers lack the knowledge of the platforms we all use: HTML, CSS, and JavaScript. Web Components solve this problem by providing a spec that everyone can learn and use. 


## Can't we all just get along?

Learning the HTML spec can be easy, even for beginners. Getting every browser and library to agree and support spec is hard. HTML is a living document and is constantly changing over time. [Apple has refused](https://github.com/w3c/webcomponents/issues/509#issuecomment-230700060) to implement the customized built-in elements spec in Safari. All the most popular evergreen browsers have implemented custom elements v1 since Microsoft moved to Chromium in Edge. We all just need to work together a little better and Web Components can provide a sustainable paradigm for implementing UI components heading into the 2020s.

![](https://media.giphy.com/media/3o7qE1EaTWLQGDSabK/giphy.gif)

This doesn't mean you can't start using Web Components today. [Polyfills exist](https://www.webcomponents.org/polyfills/) for browsers that don't support the spec. 

We should all be working together to ensure web components make their way into development workflows. From the very start of education in front end web development to the most sophisticated web application web components have the potential to streamline UI component development, provide accessibility features out of the box, and even reduce the amount of code it takes to build UI. It’s time we unleash that potential instead of squabbling over which JS framework is better at providing a component paradigm. JavaScript frameworks will continue to be good at what they do best: state management, providing architectural patterns and convenient tooling. Web Components are here to stay. We can all work together to make the web a better place.